<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2560159;
mso-list-template-ids:-770913586;}
@list l1
{mso-list-id:50085353;
mso-list-template-ids:-884316476;}
@list l2
{mso-list-id:843595045;
mso-list-template-ids:-932037036;}
@list l3
{mso-list-id:882717099;
mso-list-template-ids:932629560;}
@list l4
{mso-list-id:888111008;
mso-list-template-ids:-975816554;}
@list l5
{mso-list-id:1060908730;
mso-list-type:hybrid;
mso-list-template-ids:1868584256 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l5:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l5:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l5:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l6
{mso-list-id:1209104547;
mso-list-template-ids:-1628437630;}
@list l7
{mso-list-id:1276064155;
mso-list-template-ids:2051730306;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Alan,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you for your thoughts. A couple of comments:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo8">We use terms like we believe/think, etc. because we are not the ultimate arbiters of the what the ICANN Bylaws allow or don’t allow. So, any statement that comes from us on this topic,
while perhaps instructive, is not binding on anyone.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo8">With respect to being a house of cards, you are in many way correct. We have built a number of our recommendations off of what happened during the 2012 round and what we would like
to see happen in future rounds. If anything in the new Bylaws fundamentally changes our assumptions, then in some respects, we will have to come back and redo certain things.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo8">Your first recommendation (of having ICANN choose who the dispute providers can be) may be problematic according to the discussions that we had with Avri and Becky. During that conversation
they made it clear that the provider could not be under the control of ICANN. Whether that means just payment (as in your first recommendation) or choosing a list of providers they would find acceptable is an open question that we cannot solve.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0in" start="4" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo8">The main point about the email on PICs/RVCs is that we (the Working Group) still believe that all of our recommendations / implementation guidance that we have worked the past 4-5
years on are still valid. We believe they all can be implemented for future rounds under the existing bylaws and thus, there are no true fundamental changes that we need to make based on the Board feedback.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0in" start="5" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo8">The IRT, working with ICANN Org, will recommend whether that would need to result in changes to the Bylaws, but at this point, we are not in a position to recommend what needs to be
done from that standpoint.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoNormal">I hope that helps.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<table class="MsoTableGrid" border="1" cellspacing="0" cellpadding="0" style="border-collapse:collapse;border:none">
<tbody>
<tr>
<td width="192" valign="bottom" style="width:144.3pt;border:none;border-top:solid #06175F 3.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="text-align:justify"><span style="font-family:"Arial",sans-serif;color:black;border:none windowtext 1.0pt;padding:0in"><img width="178" height="81" style="width:1.8489in;height:.8437in" id="Picture_x0020_2" src="cid:image001.png@01D6D1FD.456BC4B0"></span><o:p></o:p></p>
</td>
<td width="173" valign="bottom" style="width:129.95pt;border:none;border-top:solid #06175F 3.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class="MsoNormal" style="text-align:justify"><span style="font-family:"Arial",sans-serif;color:#06175F">Jeffrey J. Neuman</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-family:"Arial",sans-serif;color:black">Founder & CEO</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-family:"Arial",sans-serif;color:#06175F">JJN Solutions, LLC</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-family:"Arial",sans-serif;color:black">p: +1.202.549.5079</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-family:"Arial",sans-serif;color:black">E:
</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><a href="mailto:jeff@jjnsolutions.com"><span style="font-size:11.0pt;font-family:"Arial",sans-serif;color:#1155CC">jeff@jjnsolutions.com</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="font-family:"Arial",sans-serif;color:black">http://jjnsolutions.com</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Alan Greenberg <alan.greenberg@mcgill.ca> <br>
<b>Sent:</b> Saturday, December 12, 2020 1:09 AM<br>
<b>To:</b> Jeff Neuman <jeff@jjnsolutions.com>; gnso-newgtld-wg@icann.org<br>
<b>Subject:</b> Re: [Gnso-newgtld-wg] Thoughts on PICs / RVCs (LONG NOTE)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jeff, <br>
<br>
Sorry for the delay in replying to this message.<br>
<br>
I am not at all sure I agree with some of you "principles", but the specific details are not relevant to this message.<br>
<br>
However, the fact that I don't fully agree, and that you have used the expression "I/we believe/think" six times in this messages clearly implies some level of uncertainty regarding whether what you believe (or hope?) is how all of this will play out. Moreover,
in at least one part of the scenario, you state as a fact something that may not turn out to be the case (see 1st remedy).<br>
<br>
There are two remedies that can address these issues:<br>
<br>
1. There needs to be an enforceable contractual provision that in the case of PIC/RVC disputes, the Registry must contract with an ICANN identified dispute resolution provider (or one of a pre-selected group of providers). And obviously pay for the process.
If the Ry can choose the provider, or simply refuse to do it, the whole thing becomes a sham. I also note that there may be costs associated with setting up the dispute resolution process and ICANN would have to bear that.<br>
<br>
2. As noted above, there are a LOT of assumptions, beliefs and hopes in all of this. If any of these prove false, the house of cards collapses and we may be left in the laughable position of ICANN signing contracts which they know will not be enforceable. In
the real world, there will always be cases where some contractual terms end up being unenforceable, but it makes no sense at all to have that knowledge before signing and proceed. We must include a recommendation that, should it turn out that the PIC/RVCs
are not fully enforceable, the ICANN Board must take appropriate action to remedy the situation and ensure enforceability, even if that action requires Bylaw amendment.<br>
<br>
Alan<br>
<br>
<br>
<br>
At 2020-12-09 03:22 PM, Jeff Neuman wrote:<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">All,<br>
<br>
I know there have been a lot of e-mails on this subject in the last week or so. I wanted to give you some perspectives that we discussed at the leadership level to see if we can find some common themes and then we can see if any language in our report needs
to change (which I am not convinced there will need to be substantial changes). This is my (Jeff Neuman) summary to move the discussion along.<br>
<br>
So, here is where I think we are on principles:<br>
<br>
<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<u>Existing PICs used as PICs in New Registry</u> Agreements: We believe that the existing PICs – worded substantially the same as they were in 2012 – are ok under ICANN’s Bylaws as they are sspecifically “grandfathered†in.
<o:p></o:p></li></ol>
<p class="MsoNormal"><br>
<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4 level1 lfo2">
<u>Domain Name Eligibility Rules</u>: We all seem to be on the same page that eligibility rules for the registration/renewal (but not necessarily usage) can be included in PICs/RVCs under ICANN Bylaws.
<o:p></o:p></li></ol>
<p class="MsoNormal"><br>
<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l6 level1 lfo3">
<u>Voluntary Registry Commitments</u>: <o:p></o:p></li></ol>
<p class="MsoNormal"><br>
<o:p></o:p></p>
<ol start="1" type="1">
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l7 level2 lfo4">
<u>Commitments made by Registries without ICANN Enforcement</u> <o:p></o:p></li></ol>
</ol>
<p class="MsoNormal"><br>
i. Registries and Registrars have reserved their rights to take down domain names for phishing, pharming, malware, and other forms of domain name abuse. With respect to Registries, some have built
these directly in as PICs while others have just built this into their Registry-Registrar Agreements (and some do both). These types of PICs / RVCs do not seem to present any issue under the ICANN Bylaws (in our view).
<br>
<br>
<br>
<br>
ii. We also believe that it is fairly common for registries to have policies that allow them to take down any domains used in connection with illegal activity, child exploitation, fraud, the sale of
illegal pharmaceuticals, etc. <br>
<br>
<br>
<br>
iii. Because these do not require ICANN enforcement, we see no reason how or why this would present an ICANN Bylaw issues. Conversely, we see no reason why we (through a PDP) would have any ability
to restrict the ability of a registry to impose these types of commitments on their registrants (through registrars or directly). So while we appreciate Kathy’s concern about a Registry’s ability to take down domain names, we do not believe that we are
in a position to either require registries to take down names based on content or to prohibit them from doing so either. Both could be considered forms of regulation (imposing rules on what a registry has to do or what it may not do).<br>
<br>
<br>
<br>
iv. <u>Real Example Today</u>. .gay. The Registry Operator for .gay (Top Level Design) want to have a safe space for the LGBTQ community. That community, as most of you know, has historically been
the subject of hate speech, violence, bullying, etc. Having a safe space for the gay community according to the registry is its differentiator and is absolutely necessary. It has an incredibly strict Rights Protections Policy (<a href="https://www.ohhey.gay/gay-cares">
https://www.ohhey.gay/gay-cares</a>) that prevents Registrants from (i) inciting or promoting violence against others, (ii) Bullying, engaging in cyber bullying or inciting others to bully, (iii) Harassing, or encouraging others to harass or harm others, (iv)
Stalking, (v) Abusive intent to cause fear or threaten violence, (vi) Hate Speech, (vii) Or activity intended to organize, coordinate, or otherwise enable one of the above. It also reserves the right to take down any sites that do any of the above at its
sole discretion. <br>
<br>
<o:p></o:p></p>
<ol start="1" type="1">
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo5">
<u>Commitments made by Registries that may require ICANN Enforcement in some capacity</u>
<o:p></o:p></li></ol>
</ol>
<p class="MsoNormal"><br>
<br>
<br>
Some Registries will want to make voluntary commitments in response to public comments, Government early warnings, objections, GAC Advice, etc. We do not see an issue with having these commitments reflected in Registry Agreements even if they fall outside of
ICANN’s core mission IF in the case where the commitment does not fall within ICANN’s mission, neither ICANN itself nor any third party under ICANN’s control is involved in the decision as to whether the commitment itself has been violated. Where an
independent third party finds a violation of the commitment, ICANN should be able to rely on that third party decision and enforce a pre-arranged contractual remedy, which could include sanctions and/or termination of the Registry Agreement.<br>
<br>
<br>
<br>
<u>Examples / Use Cases:<br>
</u><br>
<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo6">
If an Applicant applies for the TLD “.dictionarywordthatisalsobrandx†and Brand X objects to the application. Applicant agrees with Brand X that it will not use the TLD in an infringing manner to Brand X. In exchange for that Agreement, Brand X agrees
to drop its Objection IF the Applicant agrees to put this commitment into its Registry Agreement in the form of an RVC.
<o:p></o:p></li></ol>
<ol start="1" type="1">
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level2 lfo6">
As a PDP Working Group we have often said that it is our preference for disputes, objections, etc. to be worked out between the parties where this is possible. This is in line with our desire to see future expansion of the TLD space and encourage innovation
and competition. <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level2 lfo6">
As a result, this type of private resolution should be encouraged. <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level2 lfo6">
The question, however, is whether ICANN could enforce this commitment. <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level2 lfo6">
After our discussions with the ICANN Board liaisons and the comments we received by the community, the real concern was that ICANN did not believe it could be put in a decision to make these types of decisions (namely in this case whether Applicant’s use
of the TLD violates its commitment to Brand X). <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level2 lfo6">
If the Applicant and Brand X agree that any disputes involving their “settlement†are resolved by an independent third party (not ICANN) and the costs are borne by the parties (as opposed to ICANN), this should not present a problem.
<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level2 lfo6">
If ICANN implements the decision by the independent third party (which the Applicant agreed in its Registry Agreement to allow ICANN to do), this too should not present a Bylaws issue.
<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level2 lfo6">
The key point here is that ICANN itself is not imposing the restrictions on the Applicant and therefore should not be violating its own Bylaws.
<o:p></o:p></li></ol>
</ol>
<p class="MsoNormal"><br>
<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo7">
What if an Applicant applies for .ideaexchange? The Applicant wants to run the TLD as a place where registrants can put their open source ideas on the Internet and allow others to use their ideas in connection with whatever they want. Comments are filed by
businesses, governments, intellectual property owners and others concerned that this will be a space where users will exchange intellectual property that they do not own. Lets also assume that the Independent Objector files an objection as well. Assume Applicant
never intended that and agrees that it will have a policy whereby Registrants agree that they will not use the TLD to distribute any intellectual property that is not owned by them. And the Applicant also reserves the right to take down any names that use
the TLD in violation of this policy. To resolve the comments filed by governments, businesses, etc., the Applicant voluntarily agrees to have an RVC that states this policy and the takedown processes. Each of the commenters and the Independent Objector agree
that this would settle the matter and if documented in the Registry Agreement, they would drop their challenges.
<o:p></o:p></li></ol>
<ol start="1" type="1">
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level2 lfo7">
We believe that having these comments resolved in an amicable manner should be encouraged.
<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level2 lfo7">
Because this new policy has to be documented somewhere, the only real place it can be documented is as an RVC in the Registry Agreement.
<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level2 lfo7">
ICANN should not be the arbiter of whether there is a violation of this policy. This would certainly arguably be beyond its mission.
<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level2 lfo7">
However, if the arbiter of any disputes is an independent third party, not paid by ICANN, etc., then this would seemingly be ok even if it is agreed by the Applicant to follow the third party decision and to allow ICANN to impose the appropriate remedy.
<o:p></o:p></li></ol>
</ol>
<p class="MsoNormal"><br>
<br>
<br>
<b>Bottom Line: I believe that so long as ICANN is not the ultimate decision maker in whether a policy that may arguably be outside of its mission, there should be no issues with having new PICs and/or Registry Voluntary Commitments. If this indeed is the
case, then we would just need to add a recommendation that (a) independent third parties must be used to resolved any potential violations of the PICs / RVCs, and (b) Applicants would need to agree in a Registry Agreement to be bound by the decision of the
third party and to allow ICANN to impose sanctions / penalties. <br>
</b><br>
<br>
<br>
<img border="0" width="178" height="81" style="width:1.8541in;height:.8437in" id="Picture_x0020_1" src="cid:image002.jpg@01D6D1FD.456BC4B0" alt="[]"><br>
<br>
Jeffrey J. Neuman<br>
<br>
Founder & CEO<br>
<br>
JJN Solutions, LLC<br>
<br>
p: +1.202.549.5079<br>
<br>
E: <a href="mailto:jeff@jjnsolutions.com">jeff@jjnsolutions.com</a><br>
<br>
<a href="http://jjnsolutions.com/">http://jjnsolutions.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Gnso-newgtld-wg mailing list<br>
<a href="mailto:Gnso-newgtld-wg@icann.org">Gnso-newgtld-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg">https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg</a><br>
_______________________________________________<br>
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 (<a href="https://www.icann.org/privacy/policy"> https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a href="https://www.icann.org/privacy/tos"> https://www.icann.org/privacy/tos</a>). 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.<o:p></o:p></p>
</blockquote>
</div>
</body>
</html>