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

Tue Dec 1 15:43:11 UTC 2020

Chris

A good summary of the position.

And I agree with it.

Nigel

PS: I will be an apology for this evening's call as I'm travelling.

On 12/1/20 2:09 PM, Chris Disspain wrote:
> 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.
> 
> 
> _______________________________________________
> IOT mailing list
> 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.
> 