<div dir="ltr"><div dir="ltr"><div>Hi NCSG,</div><div><br></div><div>We have an item on the GNSO council agenda relating to SubPro Recommendation 36.4 implementation. Please read below for the details of the concerns from the council liaisons to the IRT.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Remain blessed,<br></div>Tomslin</div></div></div></div></div></div></div></div></div></div></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Susan Payne via council</b> <span dir="auto"><<a href="mailto:council@icann.org" target="_blank">council@icann.org</a>></span><br>Date: Fri, 9 May 2025 at 02:59<br>Subject: [council] Council Agenda Item 7: Implementation of SubPro Rec 36.4<br>To: <a href="mailto:council@icann.org" target="_blank">council@icann.org</a> <<a href="mailto:council@icann.org" target="_blank">council@icann.org</a>><br>Cc: Tomslin Samme-Nlar via council <<a href="mailto:council@icann.org" target="_blank">council@icann.org</a>><br></div><br><br><div>
<div lang="EN-GB" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Dear Council colleagues,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> This relates to agenda item 7 at our Council meeting of 15 May 2025.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">As the Co-Liaisons to the SubPro IRT, we need to raise a disagreement between staff and the IRT community group over the
proposed implementation language in the Next Round Base Registry Agreement of one of the Board-adopted recommendations (SubPro Recommendation 36.4). ICANN's proposed language to implement Recommendation 36.4 is as follows:<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-bottom:12.25pt;text-indent:72.0pt">
<span style="font-size:12.0pt;color:black">4.3(f) </span>
<span style="font-size:12.0pt">ICANN may, upon notice to Registry Operator, terminate this Agreement if<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-bottom:12.25pt;margin-left:36.0pt">
<span style="font-size:12.0pt"> (i) ICANN receives a complaint, or ICANN otherwise becomes aware, that Registry Operator is engaging in fraudulent or deceptive business practices in provision of Registry Services under this Agreement
for the TLD; and <u></u><u></u></span></p>
<p class="MsoNormal" style="margin-bottom:12.25pt;margin-left:36.0pt">
<span style="font-size:12.0pt">(ii) such fraudulent or deceptive business practices have resulted in an adverse action or decision and a failure to remediate finding against the Registry Operator by a relevant governmental consumer
protection authority or authorities with jurisdiction over the matter, or Registry Operator is the subject of a determination that ICANN reasonably deems as the substantive equivalent of any of the foregoing; provided that, if ICANN receives a complaint related
to the foregoing, all available relevant documentation from such adverse action or decision and a failure to remediate finding must be included as part of the complaint.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Rec 36.4 had full consensus in the SubPro PDP WG, and was adopted by the ICANN Board. It provides as follows (in bold
and divided into bullets by us for ease of reading). Our text in red explains why the IRT concluded that the above draft does NOT comply with the Board-adopted Recommendation:<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">ICANN must add a contractual provision [to the Next Round Registry Agreement] stating that the registry operator will not engage in fraudulent or deceptive practices</span></b><span style="font-size:12.0pt">.
<span style="color:red">It is not disputed that such fraudulent or deceptive practices should be in the provision of Registry Services. The added contractual obligation is a key part of Rec 36.4, because the PICDRP Panel in the .Feedback case found that there
was such conduct in the operation of the Registry, but that there was no contractual provision whereby the Registry Operator committed not to engage in such conduct. Consequently the Panel considered itself unable to apply a sanction against the Registry
Operator. In spite of the ramifications of the .Feedback decision</span>,<span style="color:red"> which Rec 36.4 sought to remedy, ICANN proposes NOT to include such a provision in the RA.
</span><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow
the registry to cure such breach in accordance with the Registry Agreement</span></b><span style="font-size:12.0pt">.
<span style="color:red">ICANN proposes to comply but provides in its draft language that the court or other governmental consumer protection authority order must include a finding that the fraudulent or deceptive practice has not been remediated by the Registry
Operator. As drafted (and this may simply be a drafting error) this is highly unlikely since no further order would normally follow in the event the Registry Operator remediates the problem. Of course the Registry Operator could prove up remediation to ICANN
but a court "finding" of a lack of remediation should not be required here. Rec 36.4 envisages ICANN making the determination of lack of remediation, after having given the RO the opportunity to cure the breach.</span><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either:</span></b><span style="font-size:12.0pt"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:72.0pt">
<b><span style="font-size:12.0pt;font-family:"Courier New"">o</span></b><b><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or
</span></b><span style="font-size:12.0pt"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:72.0pt">
<b><span style="font-size:12.0pt;font-family:"Courier New"">o</span></b><b><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">appoint a panel under the PICDRP</span></b><span style="font-size:12.0pt">. <span style="color:red"> ICANN proposes NOT to utilise either of these alternative
dispute resolution processes, where there is a credible allegation but no court order. Instead, ICANN proposes to treat such a situation as equivalent to there being a Court Order, and going straight to termination without allowing the registry Operator to
defend themselves via a DRP. Sub Pro had full consensus on the alternatives to be pursued in the absence of a court order. The Recommendation provides for ICANN, in its discretion, to pursue enforcement either via (a) dispute resolution under Article 5 or
(b) appointment of a PICDRP panel</span> <span style="color:red">(the latter being possible only if the contractual provision not to engage, set out in bullet 1, is dealt with in the RA as a PIC/RVC).
</span><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance,
but not that it personally has been harmed as a result of the registry operator’s act or omission.</span></b><span style="font-size:12.0pt;color:red"> ICANN proposes NOT to include this language.
</span><span style="font-size:12.0pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> By way of additional detail, we have (attached):<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:12.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span style="font-size:12.0pt">an explanation from Karla Hakansson of how staff propose to implement Rec 36.4 and why<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:12.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span style="font-size:12.0pt">a detailed note from Jeff Neuman, one of the SubPro Co-chairs, summarising what Rec 36.4 says, the rationale for this recommendation, and how the staff proposed implementation differs from what
was recommended. Cheryl Langdon-Or, the other Co-chair, supports this note.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Karla’s attached note states that Rec 36.4 requires “ICANN (or ICANN with the assistance of a PICDRP panel) to make the
substantive determinations as to whether a registry operator in fact engaged in fraudulent or deceptive practices”, and that this is outside of ICANN’s scope. The IRT disagrees with that interpretation. If there is a credible allegation (rather than an actual
court finding) ICANN may proceed via its choice of dispute resolution process. In other words, ICANN merely needs to believe there is sufficient evidence to bring the case, which is in its discretion, it is the DR panel that makes the substantive determination.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">We believe it is the full consensus of the SubPro IRT that staff’s proposed implementation does not meet Rec 36.4, in a
number of ways (as set out in more detail above and in the Co-chairs note). IRT members have expressed this concern on multiple calls since last November, and (to the best of our recollection) no IRT members have expressed an opposing view. One member of
the IRT has suggested that this issue needs to be addressed at the Board level.<u></u><u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">What action might Council take?
</span></b><span style="font-size:12.0pt">We do not believe this is a situation where the PDP recommendation is unclear, and therefore this isn’t a case where clarification or guidance would assist. Staff are aware of the meaning
and intent of the recommendation, but do not intend to implement it as written. As per Karla's attached note, ICANN believes it has followed the "intent" of the Recommendation. The IRT disagrees. We believe that Council should provide input to ICANN Staff
in charge of the IRT confirming Council's position that Rec 36.4 is clear, is designed to address an actual omission that has bearing on the Security and Stability of the Internet, and should be implemented as written. Accordingly, the current proposed implementation
is unacceptable. We also believe it would be helpful for this communication to be copied to the Board, perhaps with a request to discuss this in Prague.
<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>Susan and Anne<u></u><u></u></b></p>
<p class="MsoNormal">Joint Council Liaisons to SubPro IRT<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<hr>
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the
sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to
scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company
registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number
5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys
Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington
and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033,
Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see
<a href="https://comlaude.com" target="_blank">www.comlaude.com</a>
</div>
_______________________________________________<br>
council mailing list -- <a href="mailto:council@icann.org" target="_blank">council@icann.org</a><br>
To unsubscribe send an email to <a href="mailto:council-leave@icann.org" target="_blank">council-leave@icann.org</a><br>
<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" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">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.</div></div></div>
</div>