[IOT] IOT - Agenda for 1 December call 19:00 UTC

Chris Disspain chris at disspain.uk
Tue Dec 1 14:09:32 UTC 2020


 <>Hello All, <> 

Following the discussion on repose I thought it might be helpful if I put something in writing to help explain the position I am taking. I have not produced a paper but the below does contain some examples that I hope will be of use.

I think the examples provided by Malcolm are instructive because they get to the very core of why I am so uncomfortable with a situation where there is no repose. The argument put forward seems to be built on the premise that all decisions be they policy, implementation of policy or day to day administration should be, for all time, open to ‘question’ using ICANN’s internal accountability mechanisms provided only that the ‘claimant’ can show that they have been harmed and have acted within 120 days of becoming aware of the harm. 

Respectfully, I do not accept that that is what is intended in the bylaws and I do not believe that this is what was intended by the recommendations of the CCWG. I believe that repose is an essential element to provide certainty to the ICANN community and to enable good governance. 

I appreciate that the bylaws do not say that there should be repose but they also do not say that there should not be. And such timing matters are within the scope of IoT which is considering timing in respect to matters such as consolidation.   

I acknowledge that the new bylaws do significantly extend the IRP and I am not suggesting that an IRP panel cannot be asked to rule on the question of acting outside the limited mission. BUT I am arguing that to allow ICANN’s internal accountability mechanisms to be used at any time in the future by parties who may not even have existed at the time the decision was made would fundamentally undermine and disenfranchise the ICANN community and it’s role and is not what the accountability mechanisms are intended to be for. 

As Malcolm has pointed out in his examples, in both cases other remedies are available but he believes that the claimant should have the choice to bring a claim of ultra vires by IRP. Those remedies always include court action and will very often include the use of ICANN’s internal accountability mechanisms to rule on questions specific to the claimant.

Let’s examine a real example. The GNSO makes a series of policy recommendations in respect to WHOIS in the new GDPR world. Although the GDPR law only applies to individuals, the GNSO recommends that GDPR compliant WHOIS policy applies to all registrants. The IPC and BC are against this but the policy gains GNSO consensus and the assent of the Board. Should the IPC or its members or associates or IP associations be able to bring a reconsideration request and then an IRP claiming that applying the GDPR law to a wider class of registrants is nothing to do with stability, security and resilience and is thus outside of ICANN’s limited mission? Yes, of course they should be able to. And should it be possible to bring such a claim only after seeing how the policy is implemented in a year? Yes of course it should. 

BUT, should it be possible 5 years from now for a newly formed streaming market disruptor, whose business model is handicapped by the lack of corporate registrant information, to bring a claim of ultra vires using ICANN’s internal accountability mechanisms? I don’t believe it should. An IRP panel can only make a finding that something is or is not outside of mission and the consequent steps are then up to the Board. In such circumstance it is difficult to see how the board can do anything but untie the policy with all of the corresponding chaos that could cause. I believe that an action of such import and leading to such possibly catastrophic effect should only be possible in a court. A court is an external independent venue where personnel are not appointed by an ICANN mechanism and not subject to re-appointment or changes in structure following bylaw reviews. A court has clear rules of procedure and evidentiary standards, and mechanisms for challenge if those are not followed. Crucially, a court has flexibility of remedy. A court can make a finding that something was outside of mission but award damages instead of ordering an untying of the policy. It could even make a finding of technical breach of bylaws and award token damages. An IRP panel can do none of those things.

Does requiring a court action rather than an IRP create a higher barrier? Yes it does and it should. 

To allow such claims through an IRP not only undermine the ICANN community and its policy development mechanisms, it throws open the doors to gaming the system at an epic level. New entrants to any market that is dependent on or effected by the DNS would be able to bring claims at any time. It would even be possible to specifically manufacture circumstances that created a claim. On this score it is important to note that significant damage can be done merely by the bringing of a claim even if, in the end, it is without merit or unsuccessful. 

Finally, I mentioned good governance earlier. The ICANN Board and the businesses that operate within the ICANN policy world need a level of certainty and from a Board perspective good governance requires it. The Board is able to budget for and time decisions based on a clear understanding that the ICANN community has the right to use accountability mechanisms within certain time frames. To allow ‘strangers’ to come along at any time in the future and use those mechanisms introduces a level of uncertainty that makes corporate governance and operating within one’s fiduciary duty or responsibility impossible.

I look forward to continuing the discussions on our call later today.



Cheers,

Chris Disspain
chris at disspain.uk <mailto:chris at disspain.uk>

+44 7880 642456



> On 30 Nov 2020, at 15:23, Bernard Turcotte <turcotte.bernard at gmail.com <mailto:turcotte.bernard at gmail.com>> wrote:
> 
> All,
> 
>  
> 
> Please find the agenda for this meeting below:
> 
>  
> 
> 1.Review agenda and updates to SOIs
> 2. Action items from the last meeting:
> 
> • Staff – Prepare a scorecard to track progress vs major items.
> 
> • SE and others – Propose counterexamples of issues with respect to Repose by email.
> 
> 3. Update on consolidation sub-group meeting.
> 
> 4. Continue discussions on the time for filing issue.
> 
> 5. AOB
> 
> 6. Next Meeting December 15, 17:00UTC
> 
>  
> 
> Bernard Turcotte
> 
> ICANN Support to the IOT
> 
>  
> 
> for
> 
>  
> 
> Susan Payne
> 
> Chair IOT
> 
> 
> _______________________________________________
> IOT mailing list
> IOT at icann.org <mailto:IOT at icann.org>
> https://mm.icann.org/mailman/listinfo/iot
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/iot/attachments/20201201/2c2d7a23/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.tiff
Type: image/tiff
Size: 12586 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/iot/attachments/20201201/2c2d7a23/PastedGraphic-2-0001.tiff>


More information about the IOT mailing list