Hi Council colleagues.  Just to keep you all informed, there has been some development with respect to recommendation 36.4.  Staff has proposed some new language which has just been shared with the IRT mailing list.  As yet, there has not been an opportunity for this to be discussed by the IRT in a meeting, and nor has there yet been an opportunity for feedback on the mailing list.  We’d like to keep this on the agenda, still, so that Anne and I can brief Council.

 

 

Dear Council colleagues,

 This relates to agenda item 7 at our Council meeting of 15 May 2025. 

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:

4.3(f) ICANN may, upon notice to Registry Operator, terminate this Agreement if

 (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 

(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.

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:

·       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. 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, which Rec 36.4 sought to remedy, ICANN proposes NOT to include such a provision in the RA.

·       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. 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.

·       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:

o   commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or

o   appoint a panel under the PICDRP.   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 (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). 

·       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.  ICANN proposes NOT to include this language.  

 By way of additional detail, we have (attached):

·       an explanation from Karla Hakansson of how staff propose to implement Rec 36.4 and why

·       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.

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.   

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.

What action might Council take?  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.

 

Susan and Anne

Joint Council Liaisons to SubPro IRT

 

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 www.comlaude.com