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

Mike Silber silber.mike at gmail.com
Mon Dec 14 13:57:54 UTC 2020


Thank you for your thoughtful message David

I am very conscious of the potential for a “recursive procedural mess”.

My concern (and the reason for suggesting that the Board is the initial arbiter) is how we bring the request for waiver before the panel? 

My thinking is that it goes to the board and can thus be reviewed by a panel. However, I readily admit that this is time consuming and potentially recursive.

If you (or someone else) can suggest how we bring a waiver request before a panel, I will very happily defer to a more streamlined process.

Regards

Mike


> On 14 Dec 2020, at 13:52, McAuley, David via IOT <iot at icann.org> wrote:
> 
> Dear IOT colleagues,
>  
> Since we last met, I have given more thought to Kurt’s very helpful suggestion for a compromise on the repose portion of the time-for-filing rule. He essentially suggested that there be a repose rule but that the ICANN Board could waive it to avoid an injustice in its application. Kurt’s email is below. 
>  
> During the call my reaction was that this suggestion – with some guardrails (as Kurt suggested) - held promise. However, I balked at Mike’s comment that maybe the panel could also waive the repose rule – although he later retracted the idea.
>  
> On further reflection I think Mike’s original idea about the panel ruling on waiver is preferable – i.e. if we adopt this repose-with-waiver approach then the waiver should be up to the panel, but not, in my view, to the Board. And the waiver would need a clear limitation on its application. 
>  
> My concern with leaving the waiver to the Board is that in every (presumably rare) instance of the repose application the claimant will argue substantial injustice to the Board. And the Board’s decision, if against waiver, could itself lead to a new IRP in a bit of a recursive procedural mess. Moreover, would ICANN Org have an opportunity to argue to the Board against waiver? Would the Empowered Community or other intervenor be able to argue to the Board one way or the other? The Board is not equipped to adjudicate a litigation-like situation.
>  
> It seems better to leave a limited standard for waiver up to the panel. The standard that seems appropriate to me would be that waiver would be appropriate only in cases where absent waiver a substantial injustice would ensue because the claimant can show that ICANN deliberately withheld information that would have enabled claimant to make a timely complaint.  
>  
> Best regards,
> David
>  
> David McAuley
> Sr International Policy & Business Development Manager
> Verisign Inc.
> 703-948-4154
>  
> From: IOT <iot-bounces at icann.org <mailto:iot-bounces at icann.org>> On Behalf Of Kurt Pritz
> Sent: Tuesday, December 01, 2020 1:32 PM
> To: iot at icann.org <mailto:iot at icann.org>
> Subject: [EXTERNAL] Re: [IOT] IOT - Agenda for 1 December call 19:00 UTC
>  
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> Hi Everyone: 
>  
> I find Chris’ letter well thought out and articulated, and support its conclusions. 
>  
> Having said that, I offer a compromise. I do this because my reading of Chris’ letter balances the potential harms resulting from “no repose” against the benefits as described by Malcolm — and determined that those risks are predominant. Again, I agree. However, the score of that balancing is not a 100 vs zero. To me it is 95-5 or something like that, where there is a low percentage probability that the implementation of a repose would bar a just and needed review process. To Malcolm, I am sure that the balancing appears different. 
>  
> To avoid the negative result of that (to me) small probability, we could: (1) establish a repose, and (2) provide that the ICANN Board could waive the repose in order to avoid an “injustice” or something similar. This might work with the presumptions that: (1) the circumstances clearly demonstrate the potential injustice or that IRP is the preferred forum for both parties, and (2) the Board will operate in good faith to come to the appropriate conclusion. I think the former can be determined in a straight-forward manner, and if the latter is not true, we are all sunk. 
>  
> I think that requests for “extra-repose” IRPs would be rare and the solution would provide a backstop in the event a certain set of circumstances did come to pass. I recommend this with the assumption that the Board review process could be streamlined and include a clear set of elements for making a determination. 
>  
> I hope you find this helpful. 
>  
> Best regards,
>  
> Kurt
>  
>  
>  
> 
> 
> On Dec 1, 2020, at 6:09 AM, Chris Disspain <chris at disspain.uk <mailto:chris at disspain.uk>> 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
> 
> <PastedGraphic-2.tiff> 
> 
> 
> 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 <https://secure-web.cisco.com/1vjAn0fUs5tMxBFHCMHjLQahqbET7njE7hnz11xa2G4N8XlmtK53VubDd0i3q345NHu0icKd35Ia8amxchjzPco5VWID-fa41LJpVQDp9qnweg9j5xEU_Pp8Be0rFnwuzWw-NyUH4xA2PsKt7k6t1DB8zxlqOUCPSb_0uwFlOKOkiWVg6gQdniPi4lSYuLTv_HsP0YGsIqNerSEtnwfCmDuB7mkUF-Kt6wUY0aU_hljKT6GHt-WkL7PGDN3fHYgJ32_x2B3lUOmgZ8oqkxQOQvQ/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fiot>
> 
> _______________________________________________
> 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 <https://secure-web.cisco.com/1cfS2R6eXoEYOpyDrsirl8gudgOfV4_Z0T_NxaC7pILDTyOiy8mYEY7LtOI7cAeT7F0YSv5sLoY8FF6un6YKXFP81kn8SUhKxcCbiyUk7yLad8X_99GvSDH43mOfKW7LNbkqFCWwXslHMtYKl6TnmfFk6rVQj3XdXgXj0NPPthXkt6TtwQwNN63JwrmA5WnVsyBAjmwv-Halekf5L-4bBQaPant9IHG-iiZ8mDqTFkxxSSxJ2qZXVGfyGkNlP04VAvCG1bJTA9QxJtAjbQ3SVKg/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://secure-web.cisco.com/1Oy_gHG-X0KdVQbCjnqVnmtK6bZvbni7_3BOYHd7rHVFB14p3lcX-HaEjOqncavPAqmgAlP3sky2lBQBmCcfw5x9WIod-WBSZZk5pN-MskbUle80hPfqQyUrN11sxdtZ6h2kr81GVGifkbujBi7BwR5hDwK63ef5yxl3CVUiU5uViw8EQP4_r4HzmaRy11oFhP9Y1dn1DLWApIOvp-6tGPLM4d6k9yq5f9FyKNvneQS3oYnenJXje98eWKsN14aEQ7nM9qubptw-OOBsz76cf2Q/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). 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 <mailto:IOT at icann.org>
> https://mm.icann.org/mailman/listinfo/iot <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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://secure-web.cisco.com/1vjAn0fUs5tMxBFHCMHjLQahqbET7njE7hnz11xa2G4N8XlmtK53VubDd0i3q345NHu0icKd35Ia8amxchjzPco5VWID-fa41LJpVQDp9qnweg9j5xEU_Pp8Be0rFnwuzWw-NyUH4xA2PsKt7k6t1DB8zxlqOUCPSb_0uwFlOKOkiWVg6gQdniPi4lSYuLTv_HsP0YGsIqNerSEtnwfCmDuB7mkUF-Kt6wUY0aU_hljKT6GHt-WkL7PGDN3fHYgJ32_x2B3lUOmgZ8oqkxQOQvQ/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fiot <https://secure-web.cisco.com/1vjAn0fUs5tMxBFHCMHjLQahqbET7njE7hnz11xa2G4N8XlmtK53VubDd0i3q345NHu0icKd35Ia8amxchjzPco5VWID-fa41LJpVQDp9qnweg9j5xEU_Pp8Be0rFnwuzWw-NyUH4xA2PsKt7k6t1DB8zxlqOUCPSb_0uwFlOKOkiWVg6gQdniPi4lSYuLTv_HsP0YGsIqNerSEtnwfCmDuB7mkUF-Kt6wUY0aU_hljKT6GHt-WkL7PGDN3fHYgJ32_x2B3lUOmgZ8oqkxQOQvQ/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fiot>
> 
> _______________________________________________
> 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://secure-web.cisco.com/1cfS2R6eXoEYOpyDrsirl8gudgOfV4_Z0T_NxaC7pILDTyOiy8mYEY7LtOI7cAeT7F0YSv5sLoY8FF6un6YKXFP81kn8SUhKxcCbiyUk7yLad8X_99GvSDH43mOfKW7LNbkqFCWwXslHMtYKl6TnmfFk6rVQj3XdXgXj0NPPthXkt6TtwQwNN63JwrmA5WnVsyBAjmwv-Halekf5L-4bBQaPant9IHG-iiZ8mDqTFkxxSSxJ2qZXVGfyGkNlP04VAvCG1bJTA9QxJtAjbQ3SVKg/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy <https://secure-web.cisco.com/1cfS2R6eXoEYOpyDrsirl8gudgOfV4_Z0T_NxaC7pILDTyOiy8mYEY7LtOI7cAeT7F0YSv5sLoY8FF6un6YKXFP81kn8SUhKxcCbiyUk7yLad8X_99GvSDH43mOfKW7LNbkqFCWwXslHMtYKl6TnmfFk6rVQj3XdXgXj0NPPthXkt6TtwQwNN63JwrmA5WnVsyBAjmwv-Halekf5L-4bBQaPant9IHG-iiZ8mDqTFkxxSSxJ2qZXVGfyGkNlP04VAvCG1bJTA9QxJtAjbQ3SVKg/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://secure-web.cisco.com/1Oy_gHG-X0KdVQbCjnqVnmtK6bZvbni7_3BOYHd7rHVFB14p3lcX-HaEjOqncavPAqmgAlP3sky2lBQBmCcfw5x9WIod-WBSZZk5pN-MskbUle80hPfqQyUrN11sxdtZ6h2kr81GVGifkbujBi7BwR5hDwK63ef5yxl3CVUiU5uViw8EQP4_r4HzmaRy11oFhP9Y1dn1DLWApIOvp-6tGPLM4d6k9yq5f9FyKNvneQS3oYnenJXje98eWKsN14aEQ7nM9qubptw-OOBsz76cf2Q/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos <https://secure-web.cisco.com/1Oy_gHG-X0KdVQbCjnqVnmtK6bZvbni7_3BOYHd7rHVFB14p3lcX-HaEjOqncavPAqmgAlP3sky2lBQBmCcfw5x9WIod-WBSZZk5pN-MskbUle80hPfqQyUrN11sxdtZ6h2kr81GVGifkbujBi7BwR5hDwK63ef5yxl3CVUiU5uViw8EQP4_r4HzmaRy11oFhP9Y1dn1DLWApIOvp-6tGPLM4d6k9yq5f9FyKNvneQS3oYnenJXje98eWKsN14aEQ7nM9qubptw-OOBsz76cf2Q/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). 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 <mailto:IOT at icann.org>
> https://mm.icann.org/mailman/listinfo/iot <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/20201214/437b76c9/attachment-0001.html>


More information about the IOT mailing list