Dear Council, Just in case anyone is having trouble with the .eml file format attachment to Susan's background email from last week, below is the text of Jeff Neuman's email on the topic of Recommendation 36.4 which will be discussed in our upcoming Council meeting. As you know, Jeff was Co-Chair of the Sub Pro Working Group. We will also have a brief update from ICANN Compliance regarding some new text that will be shared shortly with the IRT. "Dear Anne and Susan, I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review. During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry. The .feedback PICDRP report (found here <https://www.icann.org/en/system/files/files/feedback-picdrp-panel-report-14m...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report. The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states: *Recommendation 36.4 *“CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. 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. 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 commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. 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.” It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification. ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth. - First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. - Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. - Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). - Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused. What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless. It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability. To reiterate the SubPro Recommendation: 1. ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. 2. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. 3. 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 commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this . Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement. Sincerely, Jeff Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Thu, May 8, 2025 at 9:59 AM Susan Payne <susan.payne@comlaude.com> wrote:
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 <https://comlaude.com>
