<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>George:</p>
<p><br>
</p>
<p>Thank you for this comment. The WG will of course discuss all elements of the multi-part Option 4 that you have put forward for consideration.</p>
<p><br>
</p>
<p>However, in regard to your statement about "<span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;">not </span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;">taking
away the legal rights of registrants (or successors in</span><br style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;">
<span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;">interest, i.e. transfers) of currently registered domain names",
this co-chair wishes to go on record as rejecting any implication that anything produced to date by this WG would "take away" the legal rights of domain registrants.</span></p>
<p><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;"><br>
</span></p>
<p><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;">The proposal submitted by IGOs, for a separate DRP in which
registrants would have no right of de novo judicial appeal, would have stripped registrants of those rights and has consequently been rejected, on both legal and implementation/effectiveness grounds, by a consensus of WG members.</span></p>
<p><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 13.3333px;"><br>
</span></p>
<p><span style="font-size: 13.3333px;">Our Initial Report preserved the legal right of DN registrants to seek judicial appeal in a court of mutual jurisdiction, and our Final Report appears likely to do the same. The remaining issue that we are discussing is
what should happen when a registrant files such appeal and an IGO successfully asserts an immunity defense to the satisfaction of the presiding judge. In this regard, the Option 2 under discussion is more favorable to DN registrants that current practice
in that it would shift the appeal to an arbitration forum under the terms of the national law on which the appeal was brought. It has been the unanimous view of all attorneys we have consulted that if this scenario arose today the UDRP decision would be reinstated upon
dismissal of the judicial action and the domain would be transferred or extinguished, leaving the registrant with no meaningful appeal.</span></p>
<p><span style="font-size: 13.3333px;"><br>
</span></p>
<p><span style="font-size: 13.3333px;">The balancing factor for IGOs is that, just as we have determined that ICANN would not grant them blanket immunity in advance of a UDRP/URS filing, we leave the determination of the immunity defense to the presiding judge.
As Prof. Swaine's memo opined, it would not be unreasonable to require IGOs to renounce the immunity defense to gain the benefits of a lower cost and more rapid DRP than filing a lawsuit. We have not gone that far with a view to as best as possible balancing
the legitimate rights and interests of both domain registrants and IGOs while striving to produce a Final Report and Recommendations that can gain approval by the GNSO Council.</span></p>
<p><span style="font-size: 13.3333px;"><br>
</span></p>
<p><span style="font-size: 13.3333px;">Regards, Philip </span></p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> gnso-igo-ingo-crp-bounces@icann.org <gnso-igo-ingo-crp-bounces@icann.org> on behalf of George Kirikos <icann@leap.com><br>
<b>Sent:</b> Tuesday, June 27, 2017 8:10 AM<br>
<b>To:</b> gnso-igo-ingo-crp@icann.org<br>
<b>Subject:</b> [Gnso-igo-ingo-crp] Attempt at Achieving Full Consensus -- Option #4</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi folks,<br>
<br>
After today's call, I was doing some brainstorming, and wish to<br>
present a skeleton proposal for a new Option #4, as a possible viable<br>
alternative to Options #1, #2 and #3.<br>
<br>
First, my strong inclination remains with Option #1, with Option #3<br>
(the limited waiver adjustment to the UDRP language, as opposed to a<br>
full waiver as is currently the case, as mentioned by Paul Keating)<br>
being my second choice.<br>
<br>
However, here's my idea for Option #4:<br>
<br>
(a) For all domains with a creation date prior to the adoption of our<br>
final report (say January 1, 2018, for the sake of argument), we go<br>
with Option #1 (i.e. this reflects the grandfathering we've discussed<br>
previously for existing domain names already created, thereby not<br>
taking away the legal rights of registrants (or successors in<br>
interest, i.e. transfers) of currently registered domain names.<br>
<br>
(b) For all domains with a creation date past January 1, 2018, we go<br>
with Option #2 (not the current document that was sent to the mailing<br>
list today, but a much more polished and thoroughly reviewed version,<br>
with stronger due process protections for registrants, including a 2nd<br>
level of appeals if necessary and also with the full "open court<br>
principle" in effect for all documents/evidence, for all those cases<br>
(not just decisions, but also all filings, cross-examinations, etc. in<br>
the case) with copies to be maintained on a public website by ICANN<br>
(as they do now for their "Litigation" section of their website.<br>
<br>
(c) All UDRP/URS providers must flag *all* of their disputes involving<br>
IGOs as complainants, sending the information to ICANN which will<br>
maintain a public record of them (like they used to do for UDRPs, but<br>
stopped doing). Not only does ICANN have to track any arbitrations<br>
invoked in point (b) above, but ICANN must also track any/all court<br>
disputes invoked and subject to point (a) (i.e. the grandfathered<br>
domain names), and obtain (at ICANN's expense) all the relevant public<br>
court documents/filings/evidence.<br>
<br>
(d) And here's the key insight, that follows from (a), (b) and (c) --<br>
at the earliest date of (i) five years or (ii) after 10 (or some other<br>
number) disputes involving IGOs via Option #2 (i.e. counting just<br>
non-grandfathered domains, where the arbitration system might offer<br>
less due process than the courts), ICANN shall convene a "review"<br>
working group to analyze all of the cases involving IGOs (both<br>
grandfathered and non-grandfathered), for the limited purpose of<br>
reviewing whether or not the arbitration system has adequately served<br>
those domain name registrants (i.e. offered the equivalent level of<br>
justice as the court system).<br>
<br>
Should that review find that the level of due process was equivalent<br>
to the courts (i.e. no outrageous decisions/outcomes/process failures,<br>
etc. that offends the sensibilities of community, etc.), then Option<br>
#2 could continue (for newly created domains only; grandfathered<br>
domains would always stay grandfather via Option #1). In the event<br>
that arbitration turns out to be an abysmal failure, i.e. subject to<br>
forum shopping issues, etc., then newly created domains would revert<br>
back to Option #1 (vitiation), just like the grandfathered domain<br>
names. That working group shall also seek the input of all parties to<br>
the disputes, to get their input on the success of the procedure.<br>
<br>
So, in other words, we "try out" Option #2, just for newly created<br>
domains, while preserving full legal rights under Option #1 for<br>
grandfathered domains. Then we impose the obligation upon ICANN, the<br>
UDRP/URS providers, and the arbitration providers (via the mandated<br>
open court principle) to provide a future "review working group" the<br>
ability to go back and double check that there were no negative<br>
consequences in the decision to "try out" Option #2 as an experiment.<br>
(I was going to use the term "unforeseen consequences", but I think we<br>
*can* foresee some of those potential consequences already!)<br>
<br>
Lastly, we build in a clause that should ICANN fail to complete such a<br>
review within 7 years total (measured from the adoption of our final<br>
report, i.e. January 1, 2018 for the sake of argument plus 7 years<br>
would be January 1, 2025), then Option #2 is eliminated, and we go<br>
back to Option #1. Call this a "self-termination" clause, to ensure<br>
that a future review itself isn't gamed. i.e. the default is that we<br>
go back to Option #1 for everyone, except if a full review determines<br>
we can continue with Option #2 for newly created domains.<br>
<br>
The entire justification of this PDP was due to the new gTLD process.<br>
So, this recommendation would say "fine, experiment on newly created<br>
domains, both new gTLDs and legacy TLDs to boot; review and assess,<br>
and either continue it if no negaitve consequences, or kill it and<br>
revert to Option #1 if there are problems".<br>
<br>
This solves a lot of the issues where ICANN makes bad policies, and<br>
then never reviews them (i.e. UDRP being reviewed after 20 years!).<br>
Here, we're *building in* the mandatory review as part of our<br>
consensus decision-making, if folks agree to go this route.<br>
Furthermore, we're empowering that future review working group, *and*<br>
ensuring they have all the data that's needed to do a proper review.<br>
As we've seen from other working groups, most ICANN policies never<br>
contemplated being reviewed, and thus never mandated ongoing data<br>
collection. Here, we'd be requiring that data collection from the<br>
start.<br>
<br>
This proposal is still in skeleton form, but I'm posting it now, while<br>
the ICANN meeting is ongoing in Joburg, in the hopes we can get some<br>
feedback potentially from anyone there, as it might help break an<br>
impasse (although, I still believe Option #1 is the best, by a great<br>
margin, for reasons previously discussed in depth).<br>
<br>
Of course, anyone in this PDP with thoughts can post to the mailing<br>
list as well, or we can also discuss during a future regular PDP call.<br>
<br>
Sincerely,<br>
<br>
George Kirikos<br>
416-588-0269<br>
<a href="http://www.leap.com/" id="LPlnk524750" previewremoved="true">http://www.leap.com/</a>
<div id="LPBorder_GT_14985695761100.543789013352838" style="margin-bottom: 20px; overflow: auto; width: 100%; text-indent: 0px;">
<table id="LPContainer_14985695760970.6034983673616652" role="presentation" cellspacing="0" style="width: 90%; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: 1px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200);">
<tbody>
<tr valign="top" style="border-spacing: 0px;">
<td id="TextCell_14985695761010.10870609774859119" colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;">
<div id="LPRemovePreviewContainer_14985695761010.916454352881837"></div>
<div id="LPExpandDescriptionContainer_14985695761010.3064201475248507"></div>
<div id="LPTitle_14985695761010.3525701939420145" style="top: 0px; color: rgb(0, 120, 215); font-weight: normal; font-size: 21px; font-family: wf_segoe-ui_light, "Segoe UI Light", "Segoe WP Light", "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; line-height: 21px;">
<a id="LPUrlAnchor_14985695761020.41369004525728803" href="http://www.leap.com/" target="_blank" style="text-decoration: none;">Leap of Faith Financial Services Inc.</a></div>
<div id="LPMetadata_14985695761030.505737639874273" style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: normal; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; font-size: 14px; line-height: 14px;">
www.leap.com</div>
<div id="LPDescription_14985695761030.3352049302361808" style="display: block; color: rgb(102, 102, 102); font-weight: normal; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;">
Leap of Faith Financial Services Inc. is a privately held company based in Toronto, Canada.</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
_______________________________________________<br>
Gnso-igo-ingo-crp mailing list<br>
Gnso-igo-ingo-crp@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-igo-ingo-crp" id="LPlnk378110" previewremoved="true">https://mm.icann.org/mailman/listinfo/gnso-igo-ingo-crp</a><br>
</div>
</span></font></div>
</div>
</body>
</html>