<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>
<!-- Template generated by Exclaimer Mail Disclaimers on 09:44:24 Friday, 11 December 2020 -->
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">P.ImprintUniqueID {
MARGIN: 0cm 0cm 0pt
}
LI.ImprintUniqueID {
MARGIN: 0cm 0cm 0pt
}
DIV.ImprintUniqueID {
MARGIN: 0cm 0cm 0pt
}
TABLE.ImprintUniqueIDTable {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</style>
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<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;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Arial-BoldMT;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
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;}
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.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Times New Roman",serif;
color:black;
font-weight:normal;
font-style:normal;}
.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;}
--></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="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:black">Hi All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Sorry for any redundancy, but I see there are at least 2 different threads now on PICs and RVCs and those are complicated by a maelstrom of “redline” emails so it is not at all clear who is following which strings
(and even if we are able to sort out all the strings!). So, for clarity, I thought I should repost my comments on the other PICs/RVCs string here, directly above Kathy’s original comments.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Best,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Paul<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">______________<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Hi All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Well, clearly these are brand new ideas from Kathy that have never been discussed by the working group or put out for public comment. We have no time to consider the merits (if any) of such sweeping changes to
the entire ICANN ecosystem with exactly one substantive call left. Additionally, the sweeping changes are unnecessary as even a casual review of the Bylaws indicate no issues. Below is an informal position developed through kicking this around on a recent
IPC call (it can’t be considered a formal position, since the sweeping, last minute ideas were introduced with no time left in the PDP timeline to respond to them formally). We hope this is helpful.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Best,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Paul<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">_______________________________<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></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="color:#002060"> </span><span style="color:#1F497D">“</span><span style="font-family:"ArialMT",sans-serif">(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",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;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="color:#1F497D">.</span><span style="font-family:"ArialMT",sans-serif"> (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",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif;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",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">(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",sans-serif">(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",sans-serif">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",sans-serif">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",sans-serif">(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",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">ICANN’s authority or powers pursuant to these Bylaws (“</span><b><span style="font-family:"Arial-BoldMT",sans-serif">Bylaws</span></b><span style="font-family:"ArialMT",sans-serif">”)
or<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">ICANN’s Articles of Incorporation (“</span><b><span style="font-family:"Arial-BoldMT",sans-serif">Articles of Incorporation</span></b><span style="font-family:"ArialMT",sans-serif">”):<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">(A)<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">(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",sans-serif">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",sans-serif">registrars in force on [1 October 2016]</span><span style="font-size:8.0pt;font-family:"ArialMT",sans-serif">1</span><span style="font-family:"ArialMT",sans-serif">,
including, in<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">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",sans-serif">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",sans-serif">agreement and registrar accreditation agreement;<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">(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",sans-serif">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",sans-serif">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",sans-serif">registry agreement or registrar accreditation<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">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",sans-serif">(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",sans-serif">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",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif;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",sans-serif"><o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="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",sans-serif">Specifically, ICANN:</span><span style="font-family:"ArialMT",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">(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",sans-serif">of the Domain Name System (“</span><b><span style="font-family:"Arial-BoldMT",sans-serif">DNS</span></b><span style="font-family:"ArialMT",sans-serif">”) and coordinates
the<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">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",sans-serif">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",sans-serif">domains (“</span><b><span style="font-family:"Arial-BoldMT",sans-serif">gTLDs</span></b><span style="font-family:"ArialMT",sans-serif">”). 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",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">gTLD registrars and registries,</span></b><span style="font-family:"ArialMT",sans-serif"> policies in the areas described in<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"ArialMT",sans-serif">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",sans-serif">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",sans-serif">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",sans-serif">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="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="0" style="width:547.5pt;border-collapse:collapse">
<tbody>
<tr>
<td width="57" valign="top" style="width:3.75pt;padding:0in 0in 0in 0in">
<p class="MsoNormal"><strong><span style="font-size:22.0pt;font-family:"Arial",sans-serif">Taft</span></strong><o:p></o:p></p>
</td>
<td width="38" valign="top" style="width:22.5pt;padding:0in 15.0pt 0in 0in">
<p class="MsoNormal"><strong><span style="font-size:22.0pt;font-family:"Arial",sans-serif;color:#A22831"> /</span></strong><o:p></o:p></p>
</td>
<td width="635" style="width:454.5pt;padding:0in 0in 0in 0in">
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="100%" style="width:100.0%;border-collapse:collapse">
<tbody>
<tr style="height:33.0pt">
<td style="padding:0in 0in 0in 0in;height:33.0pt">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#A22831">Paul D. McGrady</span></b><span style="color:#A22831">,</span>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#97999B">Partner</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#97999B">Intellectual Property/Trademark/Domains/Privacy/Social Media</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#97999B">Direct: 312.836.4094</span> <span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#97999B">|</span>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#97999B">Office Ext: 34094</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#97999B">Taft Office: Chicago</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<div></div>
</div>
<br>
<p style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; COLOR: #816d5c"><font color="#97999b">This message may contain information that is attorney-client privileged, attorney work product or otherwise confidential. If you are not an intended recipient, use and disclosure
of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments.</font></p>
<div class="WordSection1">
<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;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org>
<b>On Behalf Of </b>Kathy Kleiman<br>
<b>Sent:</b> Tuesday, December 8, 2020 8:38 AM<br>
<b>To:</b> gnso-newgtld-wg@icann.org<br>
<b>Subject:</b> [Gnso-newgtld-wg] Voluntary PICs/RVCs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Hi All,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On a larger note, some of us have been working on principles for Voluntary PICs/RVCs in keeping with the 2016 Bylaws,
responsive to concerns raised by the ICANN Board, and following our informative conversation with Becky and Avri, our Board liaisons.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">We re-propose the three “Guardrails for Voluntary PICs” and add a fourth one for our valuable, formative Human Rights
Core Value. <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Four Guardrails for Voluntary Public Interest Commitments/RVCs entered into by ICANN and New gTLD Registries </span></b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">1. Voluntary PICs/RVCs can only address issues with domain names themselves, including eligibility criteria consistent
with point 2 below—not the contents of websites or apps that use domain names;</span></b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">2. Commitments need to be consistent with the human rights core value established in the ICANN Bylaws;
</span></b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">3. PICs/RVCs should not give registries unbounded discretion to suspend domain names; and
</span></b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">4. PICs/RVCs should not be used to create new policies that didn’t come through ICANN processes.</span></b><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Please note that the Guardrails below are designed to include all GAC-negotiated settlements (original purpose of
voluntary PICs), and we would be happy to insert a statement if that needs to be set out even more clearly. <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Best, Kathy<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<br>
<font face="Arial" color="Gray" size="1"><br>
</font>
</body>
</html>