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

McAuley, David dmcauley at Verisign.com
Mon Dec 14 11:52:12 UTC 2020


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> On Behalf Of Kurt Pritz
Sent: Tuesday, December 01, 2020 1:32 PM
To: 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

_______________________________________________
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/b21b3f55/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://mm.icann.org/pipermail/iot/attachments/20201214/b21b3f55/ATT00001-0001.txt>


More information about the IOT mailing list