<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
@font-face
{font-family:ArialMT;}
@font-face
{font-family:Arial-BoldMT;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
color:#1F497D;}
.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:571695467;
mso-list-template-ids:1016652682;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:1474561038;
mso-list-template-ids:1799800254;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
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="#0563C1" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Dear Jeff, Cheryl, WG Team Members and Staff,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Please see below my response to the Consensus Call on the Final Report, submitted with many thanks to Leadership and ICANN Staff for their tenacity in this effort:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In general, I support the Recommendations, Affirmations, and Implementation Guidance contained in the Final Report and am registering that support in relation to the topics not specifically addressed below.
Having said that, I believe the Working Group should have spent more time addressing the Recommendations of the CCT-RT. In particular, in relation to 9.15 of the Final Report, I believe the Working Group should have made a formal Recommendation to GNSO Council
to undertake an EPDP in relation to DNS Abuse. Failure to make that recommendation simply delayed policy work that is clearly necessary.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In some cases, I summarize specific areas of support in anticipation of expressions of non-support from other WG members. For certain recommendations which I do
<u>not</u> support, the Recommendation or Implementation Guidance is referred to by topic and number.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D">Topic 2: Predictability Framework</span></b><span style="color:#1F497D">. Given that the SPIRT cannot make policy and is subject in all proceedings to GNSO Council mechanisms for handling issues, I strongly
support the proposed Predictability Framework. I believe that open participation following the same rules as IRT representation on the SPIRT is critical. Public comment confirmed that the community supports a “Standing IRT”. Although Leadership took the
view that GNSO Council might vary the structure of the SPIRT to limit its numbers, full participation by the wider community is critical to the success of this new Framework and invitations should be issued to all members of the Sub Pro Working Group and the
Sub Pro IRT as codified in Annex E to the Final Report, Item 1.c. under the heading “SPIRT Chartering, SPIRT Recruitment”. As stated in Topic 2 d. of the Final Report, “The Working Group therefore agreed that the SPIRT is needed to utilize the Predictability
Framework and accordingly has provided <b>detailed guidance in Annex E regarding the establishment of the structure.</b>” (Emphasis mine.)
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D">Topic 9: Registry Voluntary Commitments/Public Interest Commitments.</span></b><span style="color:#1F497D"> I strongly support the system of PICS and RVCs adopted in the Final Report. I subscribe to the
IPC informal position submitted to the Sub Pro list on this topic (and pasted below) which underlines why such PICs and RVCs are
<u>not</u> outside ICANN’s powers under the ByLaws. I support enforcement of mandatory PICs within ICANN and enforcement of RVCs by an independent third party Dispute Resolution Provider. In this manner, ICANN can avoid even the appearance of content regulation.
An important part of the Recommendations is that RVCs are always subject to public comment. I would not support a system of RVCs which are not subject to public comment. All PICs and RVCs should be included in the applicable Registry Agreement.<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#1F497D">IPC Informal Position on PICs/RVCs as submitted to the Sub Pro list pursuant to Leadership’s request for input:<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal" style="text-autospace:none"><b><span style="font-family:"Arial",sans-serif;color:#002060">“1. ICANN can enter into and enforce PICS in service of its Mission.</span></b><span style="font-family:"Arial",sans-serif;color:#002060"> 1.1 (d)
B (iv)</span><span style="font-family:"Times New Roman",serif;color:#002060"> </span>
<span style="font-family:"Times New Roman",serif;color:#1F497D">“</span><span style="font-family:ArialMT">(iv) ICANN shall have the ability to negotiate, enter into and enforce agreements, including public interest commitments, with any party in service of
its Mission.”</span><span style="font-size:11.0pt;font-family:ArialMT"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><b><span style="font-family:"Arial",sans-serif;color:#002060">2. ICANN is not “imposing” rules and restrictions on parties by acceptance of PICs and RVCs.</span></b><span style="font-family:"Arial",sans-serif;color:#002060">
RVCs don’t constitute “regulation” of any type, much less content regulation. (refer to history of Accountability Workstream 1 ). The ByLaws provision re “imposing” rules and restrictions in 1.1 (c) states as follows:
</span><span style="font-family:"Times New Roman",serif;color:#1F497D">.</span><span style="font-family:ArialMT"> (c) ICANN shall not regulate (i.e., impose rules and restrictions on) services that use the Internet’s unique identifiers or the content that such
services carry or provide, outside the express scope of Section 1.1(a). For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority.
<span style="color:#002060">This language makes it clear that ICANN does not intend to act as a government regulator. It does not prohibit adoption and enforcement of PICs.
<o:p></o:p></span></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT;color:#002060">The ByLaws clearly state that all previously-adopted PICs are in force and may be renewed going forward. See 1.1 (d) which states as follows:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(d) For the avoidance of doubt and notwithstanding the foregoing:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(i) the foregoing prohibitions are not intended to limit ICANN’s authority or<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">ability to adopt or implement policies or procedures that take into<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">account the use of domain names as natural-language identifiers;<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(ii) Notwithstanding any provision of the Bylaws to the contrary, the terms<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">and conditions of the documents listed in subsections (A) through (C)<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">below, and ICANN’s performance of its obligations or duties<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">thereunder, may not be challenged by any party in any proceeding<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">against, or process involving, ICANN (including a request for<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">reconsideration or an independent review process pursuant to Article<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">4) on the basis that such terms and conditions conflict with, or are in<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">violation of, ICANN’s Mission or otherwise exceed the scope of<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">ICANN’s authority or powers pursuant to these Bylaws (“</span><b><span style="font-family:Arial-BoldMT">Bylaws</span></b><span style="font-family:ArialMT">”) or<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">ICANN’s Articles of Incorporation (“</span><b><span style="font-family:Arial-BoldMT">Articles of Incorporation</span></b><span style="font-family:ArialMT">”):<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(A)<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(1) all registry agreements and registrar accreditation<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">agreements between ICANN and registry operators or<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">registrars in force on [1 October 2016]</span><span style="font-size:8.0pt;font-family:ArialMT">1</span><span style="font-family:ArialMT">, including, in<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">each case, any terms or conditions therein that are<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">not contained in the underlying form of registry<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">agreement and registrar accreditation agreement;<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(2) any registry agreement or registrar accreditation<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">agreement not encompassed by (1) above to the<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">extent its terms do not vary materially from the form of<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">registry agreement or registrar accreditation<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">agreement that existed on [1 October 2016];<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(B)any renewals of agreements described in subsection (A) pursuant<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">to their terms and conditions for renewal;<span style="color:#002060"><o:p></o:p></span></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT;color:#002060">The fact that even voluntary PICS may be renewed going forward confirms without a doubt that they are not outside of ICANN’s power under the new ByLaws. Thus,
adoption and enforcement of voluntary PICs (RVCs) is not ultra vires. <b>Unfortunately the recently proposed “guardrails” around the adoption of voluntary PICs and Registry Voluntary commitments would in fact make ICANN a regulator of content, making ICANN
the judge of a Registry’s Human Rights compliance and making ICANN (rather than the Registry) the arbiter of whether a particular RVC addresses content. In other words, the guardrails proposed increase the danger that ICANN would be acting as a content regulator.
</b></span><b><span style="font-family:ArialMT"><o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-family:"Arial",sans-serif;color:#002060">3.</span></b><span style="font-family:"Arial",sans-serif;color:#002060">
<b>No revision to the ByLaws is necessary for ICANN to accept and approve the PICs and RVC policy developed by the WG.</b> The ICANN ByLaws clearly state in the Mission section that the PDP process acts as a “guiding light” in the development of policy that
relates to ICANN’s Mission. Current ByLaws Section 1.1. (a) states:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">Specifically, ICANN:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">(i) Coordinates the allocation and assignment of names in the root zone<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">of the Domain Name System (“</span><b><span style="font-family:Arial-BoldMT">DNS</span></b><span style="font-family:ArialMT">”) and coordinates the<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">development and implementation of policies concerning the<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">registration of second-level domain names in generic top-level<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">domains (“</span><b><span style="font-family:Arial-BoldMT">gTLDs</span></b><span style="font-family:ArialMT">”). In this role, ICANN’s scope is to coordinate the<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">development and implementation of policies:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in;text-autospace:none"><b><span style="font-family:Symbol">•
</span></b><b><span style="font-family:ArialMT">For which uniform or coordinated resolution is reasonably<o:p></o:p></span></b></p>
<p class="MsoNormal" style="text-autospace:none"><b><span style="font-family:ArialMT">necessary to facilitate the openness, interoperability, resilience,<o:p></o:p></span></b></p>
<p class="MsoNormal" style="text-autospace:none"><b><span style="font-family:ArialMT">security and/or stability of the DNS including, with respect to<o:p></o:p></span></b></p>
<p class="MsoNormal" style="text-autospace:none"><b><span style="font-family:ArialMT">gTLD registrars and registries,</span></b><span style="font-family:ArialMT"> policies in the areas described in<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:ArialMT">Annex G-1 and Annex G-2; and<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in;text-autospace:none"><b><span style="font-family:Symbol">•
</span></b><b><span style="font-family:ArialMT">That are developed through a bottom-up consensus-based<o:p></o:p></span></b></p>
<p class="MsoNormal" style="text-autospace:none"><b><span style="font-family:ArialMT">multistakeholder process and designed to ensure the stable and<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-family:ArialMT">secure operation of the Internet’s unique names systems.</span></b><b><span style="font-family:"Arial",sans-serif;color:#002060"><o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-family:"Arial",sans-serif;color:#002060">During its deliberations, the Sub Pro Working Group majority implicitly determined that the recommended system of PICs and RVCs is reasonably necessary to facilitate the openness,
resilience, and stability of the DNS.</span></b><span style="font-family:"Arial",sans-serif;color:#002060"> The policies developed are perfectly aligned with the scope of the Mission and do NOT constitute governmental content “regulation”. In fact, PICs
and RVCs are not about content at all. They are about resolving potential disputes that might otherwise lead to litigation and/or a chilling effect of preventing the launch of a TLD. This means that the system of PICs and RVCs will serve ICANN’s Mission to
preserve and support security, stability, and resiliency. Furthermore, all voluntary PICs and RVCs will be open for public comment and super transparent. ICANN has the power and even a duty to enforce PICs that shore up security, resiliency, and stability
as determined via PDP recommendations unless such recommendations are voted down by a 2/3 majority of the Board. In addition, if RVCs are not entered into and enforced within the ICANN system, transparency is defeated because back room deals can still be
made as a matter of private contract law. PICs and RVCs keep these commitments out in the open.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#002060">4<b>. If ICANN is concerned about the burden of enforcement, it can refer RVCs to an independent panel that ICANN does not pay and cannot override, just like UDRP</b>. The RVC-DRP
can be created in a way to allow ICANN to step back from any ICANN.org determination re RVC compliance.”
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D">Topic 12 – Applicant Guidebook.</span></b><span style="color:#1F497D"> Recommendation 12.9 - Rather than the two months period specified for AGB versions other than English, the Applicant Guidebook should
be available in all 6 UN languages at the same time, i.e. four(4) months prior to the commencement of the opening of the window for applications.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D">Topic 23 - Closed Generics</span></b><span style="color:#1F497D">. I agree that the WG members did not reach Consensus on this topic. I disagree with WG members who maintain that the “status quo” is no
prohibition on Closed Generics. After the 2012 implementation, applicants for Closed Generics were permitted to convert to open registries or to withdraw applications with refunds pursuant to Board Resolution. I support the proposal made by Greg Shatan in
the December 10, 2020 WG call (at 1 hour 7 minutes into the call) to allow applications for Closed Generics but to “suspend” such applications subject to further policy work in the appropriate forum, e.g. EPDP. In this regard, it would be helpful for the
ICANN Board to specify whether it intends to accept standing GAC Advice to the effect that a “Closed Generic” should serve a public interest goal. Such guidance would assist the GNSO Council in constructing a Charter for an EPDP. Here it is important to
note that a finding that a particular Closed TLD “serves a public interest goal” does not need to be equal to a finding that a particular Closed TLD is “in the Global Public Interest”. The two standards are distinguishable and elements to establish the status
of serving a public interest goal are ascertainable. Specific questions for evaluation of this status are suggested beginning on page 104 of the December 22 version of the Final Report.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">It should also be noted that if this Closed Generic topic is not resolved by adoption of policy prior to the opening of the next application window, it is certain there will be applications for Closed Generics
by applicants who will be relying on the new policy contained in Implementation Guidance 3.4 that prohibits subsequent applications for the same string if any prior application for that string remains unresolved. This means that a future application for a
Closed Generic could effectively block a subsequent round application for an Open Generic TLD for the same string. Such a result would violate the Principle of Applicant Freedom of Expression which has been affirmed by the Working Group as discussed in Topic
10.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D">Topic 29 – Name Collisions. </span>
</b><span style="color:#1F497D">I strongly support Recommendation 29.1 stating that ICANN “must” have ready a mechanism to evaluate the risk of name collisions. The portion of the recommendation that specifies the timing as “in the evaluation process as well
as during the transition to the delegation phase” is ill-advised as the mechanism should be developed before the application window opens. Such a “gating mechanism” will assist applicants in knowing whether or not to go to the trouble and expense of preparing
full blown application. I DO NOT SUPPORT Affirmation 29.2 which affirms continued use of the current Name Collision Occurrence Management framework in relation to a new round of gTLDs “unless and until the ICANN Board adopts a new mitigation framework”.
The harm from name collisions is not limited to “human-life threatening conditions”. Pursuant to SSAC Advice, the Board should properly assess name collision risk before adding TLDs to the root. Accordingly, the Board should await the outcome of the NCAP
work and SSAC Advice on questions posed by the Board on this topic and should adopt a new Name Collision Occurrence Management Framework before accepting applications for the next round of new gTLDs. This will avoid unnecessary expense and work for applicants
and for ICANN staff which could proliferate AFTER the application window opens if the appropriate name collision work is not done prior to that time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D">Topic 34 – Community Applications.</span></b><span style="color:#1F497D"> I strongly support the recommendations and implementation guidelines adopted by the Working Group on this Topic. Special thanks to
the ALAC, in particular to ALAC rep Justine Chew, and to Jamie Baxter for their contributions to these improvements.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:#1F497D">Topic 35 – Auctions: Mechanisms of Last Resort/Private Resolution of Contention Sets.</span></b><span style="color:#1F497D"> Regarding Recommendation 35.4, in connection with the Implementation phase, applications
designated as Specification 13 Brand applications should not be subject to the “Last Resort Sealed Bid” process unless the brand applicant retains all rights to file a Legal Rights Objection and to negotiate for Registry Voluntary Commitments in relation to
the winning bidder. This is due to the fact that after String Similarity Evaluation, no other information regarding the applications may be shared prior to submitting the sealed bid. For trademark holders/brand owners, the intended use and actual use of
the TLD is very important, as are possible restrictions via RVCs to limit the potential injury to brands which may be posed by the ownership and operation of the TLD by a third party other than the brand owner. Forcing brand applicants to file Objections
and submit sealed bids without full information regarding the application that matches the brand encourages litigation (with its corresponding expense for all parties and delays in delegation).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Respectfully submitted,<o:p></o:p></span></p>
<p class="MsoNormal"><i><span style="color:#1F497D">Anne Aikman-Scalese<o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="color:#1F497D">8 January, 2021<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt">From:</span></b><span style="font-size:11.0pt"> Gnso-newgtld-wg <</span><a href="mailto:gnso-newgtld-wg-bounces@icann.org"><span style="font-size:11.0pt">gnso-newgtld-wg-bounces@icann.org</span></a><span style="font-size:11.0pt">>
<b>On Behalf Of </b>Emily Barabas<br>
<b>Sent:</b> Tuesday, December 22, 2020 9:30 AM<br>
<b>To:</b> </span><a href="mailto:gnso-newgtld-wg@icann.org"><span style="font-size:11.0pt">gnso-newgtld-wg@icann.org</span></a><span style="font-size:11.0pt"><br>
<b>Subject:</b> [Gnso-newgtld-wg] New gTLD Subsequent Procedures PDP WG Consensus Call - Closes Friday, 08 January 2021 at 23:59 UTC<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><strong><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black">[EXTERNAL]</span></strong><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black"><o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-family:"Times New Roman",serif">
<hr size="2" width="100%" align="center">
</span></div>
</div>
<p class="MsoNormal"><span style="color:black">Dear WG members,</span><o:p></o:p></p>
<p class="MsoNormal" style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;caret-color: rgb(0, 0, 0);word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;caret-color: rgb(0, 0, 0);word-spacing:0px">
<span style="color:black">On behalf of the WG Co-Chairs, and as discussed during the WG meeting on Thursday, 17 December, this email is to notify you of the<span class="apple-converted-space"> </span><b>opening of the online<span class="apple-converted-space"> </span><u>Consensus
Call</u><span class="apple-converted-space"> </span>on the </b></span><b>WG <span style="color:black">
Outputs </span></b><span style="color:black">(i.e., Affirmation, Affirmation with Modification, Recommendation, Implementation Guidance, and No Agreement) of the New gTLD Subsequent Procedures GNSO Policy Development Process (PDP). Pursuant to the content freeze
on 18 December, please see the attached PDF of the Outputs and contextual language,<span class="apple-converted-space"> </span>which has received a handful of non-substantive updates</span> (for a redline version that shows the minor edits made since 18 December,
please see the <a href="https://community.icann.org/display/NGSPP/h.+Final+Report+Drafting">
wiki</a>)<span style="color:black">.<span class="apple-converted-space"> </span>WG members who wish to familiarize themselves with the steps involved and the various levels of consensus applicable to GNSO PDP recommendations can refer to the recording of the<span class="apple-converted-space"> </span></span><a href="https://community.icann.org/display/NGSPP/2020-12-17+New+gTLD+Subsequent+Procedures+PDP"><span style="color:#0070C0">17
December meeting</span></a><span class="apple-converted-space"><span style="color:black"> </span></span><span style="color:black">where the Consensus Call process was described.</span><o:p></o:p></p>
<p class="MsoNormal" style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;caret-color: rgb(0, 0, 0);word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;caret-color: rgb(0, 0, 0);word-spacing:0px">
<span style="color:black">This Consensus Call opens<span class="apple-converted-space"> </span><b><u>today, Tuesday, 22 December 2020</u></b></span><b><u> and closes<span style="color:black"> on Friday, 08 January 2021</span> at 23:59 UTC</u></b><span style="color:black">.
Per the<span class="apple-converted-space"> </span></span><a href="https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/annex-1-gnso-wg-guidelines-24oct19-en.pdf__;!!PtGJab4!rNJ7mR-y3NiOaoAVdoJAaixwM1dqZ9IzY_6ZGh-d2rURZLU7eQqaDXkxDxY267kIUfu4bau_tQ$">GNSO
Working Group Guidelines [gnso.icann.org]</a><span style="color:black">,<span class="apple-converted-space"> </span><b>WG members are requested to indicate<span class="apple-converted-space"> </span><u>via<span class="apple-converted-space"> </span>reply to
this<span class="apple-converted-space"> </span>list</u><span class="apple-converted-space"> </span>whether they support, or do not support, the Outputs.</b> If a WG member does not respond this will be taken as support.</span><s><o:p></o:p></s></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span style="color:black">The Outputs are largely being presented in a single package and should be considered as an integrated set of Outputs, which are the result of many years of WG discussions and input received. This includes not only the work of the WG,
but also the comments we received to Constituency Comments 1 & 2, the work of Work Tracks 1-5, comments to the Initial Report and the two Supplemental Initial Reports, and the comments to the Draft Final Report. Therefore, there will likely be Outputs that
you believe are imperfect, so the Co-Chairs encourage you to consider the Outputs in the aggregate.<span class="apple-converted-space"> </span><b>Even if given that context, you still believe there are Outputs that you do NOT support, please specifically identify
the <u>Specific Recommendations and/or Implementation Guidance within the Outputs</u> that you do cannot support and why.</b><span class="apple-converted-space"> </span></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">For the purposes of this Consensus Call, the Outputs are being organized accordingly:<o:p></o:p></span></p>
<ul style="margin-top:0in;caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo3"><b>Topic 9: Registry Voluntary Commitments / Public Interest Commitments;</b><span style="font-size:11.0pt"><o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo3"><b>Topic 23: Closed Generics;</b><span style="font-size:11.0pt"><o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo3"><b>Topic 34: Community Applications/CPE;</b><span style="font-size:11.0pt"><o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo3"><b>Topic 35: Auctions: Mechanisms of Last Resort / Private Resolution of Contention Sets; and</b><span style="font-size:11.0pt"><o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo3"><b>All other Outputs in the report.</b><span style="font-size:11.0pt">
<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">As noted on the 17 December 2020 </span>
WG <span style="color:black">call, the Consensus Call is being issues to Individual Working Group members (and not to the Constituencies, Stakeholder Groups, Supporting Organizations, and/or the Advisory Committees in which such individuals participate). Therefore,
WG members will be assumed to be responding to the consensus call on their own behalf unless they
<u>explicitly state in their response</u> that they are responding on behalf of their group/organization. Following the close of the Consensus Call, the WG Co-Chairs will meet on Monday, 11 January 2021 to review the responses from the WG members and determine
the Consensus Designations for the Outputs. The WG Co-Chairs will post the results of their determination to the WG email distribution list</span>
<span style="color:black">on <b>January 11, 2021</b><span class="apple-converted-space">. </span></span><s><o:p></o:p></s></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">On 12 January 2021 at 20:00 UTC, the Working Group will have its next and hopefully final call to discuss any questions or comments to the Consensus Designations. Calendar invites have been sent out to Working
Group members. Although the meeting is scheduled for 120 minutes, WG leadership will stay on the call until all questions have been addressed. Working Group members will then have until 13 January 2021 at 23:59 UTC to object to the Consensus Call designations.
The final Consensus Call designations shall then be included in the Final Report.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Finally, to the extent they are needed, WG members may begin working on minority statements now and through the Consensus Call period, with the ultimate due date of<b> 18 January 2021</b>.</span><o:p></o:p></p>
<p class="MsoNormal" style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;caret-color: rgb(0, 0, 0);word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;caret-color: rgb(0, 0, 0);word-spacing:0px">
<span style="color:black">Kind regards,</span><o:p></o:p></p>
<p class="MsoNormal" style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;caret-color: rgb(0, 0, 0);word-spacing:0px">
Steve, Julie and Emily on behalf of the SubPro Leadership Team<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message
or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying
to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
<br>
</font>
</body>
</html>