<html 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)">
<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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Dear WG Colleagues,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">As the EPDP Phase 2A Team finalizes its draft recommendations for public comment, we thought it might be helpful as ICANN org liaisons to the team to explain ICANN org’s thinking surrounding how the org would implement
any best practices or guidelines recommended by the EPDP Team, provided these are accepted by the GNSO Council and adopted by the ICANN Board. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">ICANN org’s specific implementation process for any best practices or guidance developed by the EPDP team will, at least in part, depend on the specifics of the best practices or guidance. For example, if the EPDP
recommendations result in a need for the implementation of a new RDDS flag or field, this may require technical implementation work and, as such, might be routed to the EPDP Phase I IRT. On the other hand, if the best practices or guidance are merely a list
of practices that the contracted parties may, at their own discretion, opt to follow, ICANN org could likely simply announce these new best practices or guidance to the contracted parties and post these to the ICANN org website. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">ICANN Contractual Compliance enforces requirements placed on contracted parties via the RA, RAA, and ICANN Consensus Policies, in furtherance of ICANN’s mission, as recognized in the ICANN Bylaws. Guidance and
best practices would exist outside these agreements and are not contractual requirements; thus, ICANN Contractual Compliance would not have contractual authority to take enforcement action against a contracted party related to its implementation of best practices
or guidance, even if those best practices or guidance is developed through the EPDP Process.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">If the EPDP Team has specific recommendations concerning how its best practices or guidance should be implemented, ICANN org invites the EPDP Team to share its views concerning the approach to implementation of
any best practices or guidance it recommends, keeping in mind the points raised above concerning the role of ICANN Contractual Compliance.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">Distribution of a legal notice or advisory would not appear to be needed in this situation, under the assumption that the best practices or guidance would not result in any new requirements for the contracted parties
to follow. A legal notice to contracted parties would be needed if the Team’s recommendations would modify an existing Consensus Policy requirement or result in a new application of an existing policy requirement</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">If the EPDP Team’s recommendations for best practices would require development of new technical capabilities (for example, to add a new flag or field for RDDS output), or would seek to modify existing RDDS output
requirements (e.g., an update to the CL&D Policy), ICANN org recommends that the EPDP Team consider and document this in its Final Report, including Implementation Guidance where necessary.<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">We look forward to answering any questions the WG might have on any of this and continuing this discussion as the work moves along. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">Regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Brian and Amy</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>