Fwd: [council] Council Agenda Item 7: Implementation of SubPro Rec 36.4

[Tomslin Samme-Nlar]

Hi NCSG,

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.

Remain blessed,
Tomslin


---------- Forwarded message ---------
From: Susan Payne via council <council at icann.org>
Date: Fri, 9 May 2025 at 02:59
Subject: [council] Council Agenda Item 7: Implementation of SubPro Rec 36.4
To: council at icann.org <council at icann.org>
Cc: Tomslin Samme-Nlar via council <council at icann.org>


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>
_______________________________________________
council mailing list -- council at icann.org
To unsubscribe send an email to council-leave at icann.org

_______________________________________________
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 (https://www.icann.org/privacy/policy) and
the website Terms of Service (https://www.icann.org/privacy/tos). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250512/11cb03e3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rec 36.4_ 4.3(f) Fraudulent & Deceptive Practices - ICANN's position.pdf
Type: application/pdf
Size: 136290 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250512/11cb03e3/attachment.pdf>
-------------- next part --------------
An embedded message was scrubbed...
From: Jeff Neuman via SubPro-IRT <subpro-irt at icann.org>
Subject: [SubPro-IRT] Re: [Ext] Base RA redline
Date: Wed, 30 Apr 2025 19:38:35 +0000
Size: 60381
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250512/11cb03e3/attachment.eml>