With regards to the statement: "We understand that there are additional details regarding these options that are not fully discussed in the document, and on which further consensus will be sought if a specific option has consensus support." I think, to a large degree, that's putting the cart before the horse. Trying to achieve "consensus" on something that isn't fully fleshed out makes that "consensus" meaningless, since the devil is in the details. If those details are then unacceptable, those who later oppose it will be accused of attempting to revisit, reargue or "relitigate" an "already decided" matter. Without any precision, how does one know exactly what position one is supposedly forming a consensus around? All too often, the details really do matter. e.g. consider a blog post this week by Tucows/OpenSRS, one of ICANN's largest registrars: https://opensrs.com/blog/2017/09/icann-community-failing-customers/ which slams ICANN policy-making for just that, namely creating policies that have scenarios that haven't been fully accounted for, and which can lead to major problems for registrants. That blog post should be required reading for members of all PDPs, as it illustrates just how important it is to get the details right. Also, with regards to the PDF attachment, there seems to be a few errors in it. (a) at the end of the first paragraph of page 1, it claims that there was an "incomplete reading of the applicable rules" for Option 4. I think that was Option 5, not Option 4. Indeed, on the 2nd page, "Option B" is the equivalent of the old "Option 4". (b) the critique in the 4th paragraph of the first page of "Option A" (formerly Option 1) is flawed, because Option 1 is actually highly respectful of "the rule of law". Option 1 is saying that the UDRP should not be putting itself above the rule of law, by allowing a panel to come to a decision that a registrant would not have the ability to challenge via the courts. IGOs can certainly mitigate their claimed "risks", as the 4th bullet point of the 2nd paragraph discusses. "Vitiation" doesn't mean "that's the end of the story" -- all it means is that the IGO would have to use a *proper legal process*, as opposed to the UDRP, to get the outcome it desires. It's false to claim, in the 4th paragraph, that IGOs would be left with "no further available remedy". Option A corrects the previously unforeseen scenario in the UDRP policymaking, i.e. just like other mistakes in ICANN policymaking (as highlighted by the OpenSRS blog post this week). (c) in the first paragraph of the 2nd page, the analysis is also flawed in its critique of "Option B" as "complex". I've repeatedly stated that it should be governed by the CREATION DATE of the domain name. It was stated as such in the very original email describing it: http://mm.icann.org/pipermail/gnso-igo-ingo-crp/2017-June/000769.html in point (a) of that email: "(a) For all domains with a creation date prior to the adoption of our final report (say January 1, 2018, for the sake of argument), we go with Option #1 (i.e. this reflects the grandfathering we've discussed previously for existing domain names already created, thereby not taking away the legal rights of registrants (or successors in interest, i.e. transfers) of currently registered domain names." and expressly accounted for "successors in interest", i.e. changes of ownership. Instead, "Option B" changes the language I proposed that expressly stated "creation date", to the use of the language "registered before", thereby *causing the complexity" that it is now being criticized, since "registered" is vague and open to interpretation. I left no room for that kind of misinterpretation, when I said "Creation Date." "Creation Date" is simple, and is also consistent with ICANN precedent, given other ICANN policies (e.g. reserved 2-letter domains) also grandfather based on CREATION DATE, regardless of change of control. Indeed, another recent ICANN policy: https://www.icann.org/public-comments/igo-ingo-protection-2017-05-17-en with regards to "Proposed Implementation of GNSO Consensus Policy Recommendations for the Protection of IGO & INGO Identifiers in All gTLDs" similarly grandfathered all existing domains, by creation date. Indeed, ICANN policies for TLDs (top level, as opposed to 2nd level) themselves often differ based on when they were created (e.g. price controls, applicability of TMCH, URS, etc.). Also, there's the criticism that "They also observe that it would leave registrants of grandfathered domains without any arbitral appeal option in the event that an IGO successfully invoked judicial process immunity." That's clearly a FALSE argument, because in that scenario, "Option A" would apply, namely that the UDRP decision would be vitiated. There'd be no need for the registrant to further appeal, as they'd still own the domain! I sometimes wonder whether I'm the only one checking these PDFs, but that was a very bad misreading of the actual Option B (i.e. former "Option 4"), since I explicitly accounted for that scenario when I initially proposed it. Sincerely, George Kirikos 416-588-0269 http://www.leap.com/ On Tue, Sep 26, 2017 at 10:26 PM, Mary Wong <mary.wong@icann.org> wrote:

Sent by ICANN staff on behalf of the Working Group co-chairs

Dear Working Group members,

As we near completion of our work on this PDP, we as the co-chairs of our Working Group wish to make the following suggestions for a path forward. Noting that we are now four (4) meetings out from ICANN60 in Abu Dhabi, our plan is to present the draft final text of all our proposed consensus recommendations to the community there for discussion and feedback, prior to filing our Final Report in November. To that end:

(1) we particularly request that members who have not been able to participate actively or recently, now take a moment to respond to the staff’s messages regarding your continuing participation in this Working Group; and

(2) we propose discussing the three options in the attached document on the Working Group call this Thursday, concerning the scenario where a losing respondent challenges the initial UDRP/URS determination in court, with a view toward seeing whether it will be possible to get group consensus on one of them. We understand that there are additional details regarding these options that are not fully discussed in the document, and on which further consensus will be sought if a specific option has consensus support.

We hope that all Working Group members will make every effort to join this final stage of deliberations. Following the community discussion at ICANN60, we will again confirm the level of consensus among our members on each of the proposed final recommendations and report, and send the Final Report to the GNSO Council for its review and, hopefully, approval.

Best regards,

Philip and Petter

_______________________________________________ Gnso-igo-ingo-crp mailing list Gnso-igo-ingo-crp@icann.org https://mm.icann.org/mailman/listinfo/gnso-igo-ingo-crp