[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