[NCSG-PC] Fwd: Fwd: [council] Council Agenda Item 7: Implementation of SubPro Rec 36.4 - Deep concerns
Kathy Kleiman
kathy at dnrc.tech
Mon May 12 19:23:44 EEST 2025
Hi Tomslin and all of our Counselors,
Tx to Tomslin for sharing. As discussed in the PC meeting earlier, the
two SubPro liaisons in this case are both members of the IPC (although
Anne is also a Nomcom appointee to Council). They are good, but they
have very clear views, as does the IPC.
*Here's some more background: *For the IPC, fraud is one of a series of
content issues they think registries and registrars should handle: For
example:
=> [ICANN Registry Agreement ] Registry Operator will include a
provision in its Registry-Registrar Agreement that requires Registrars
to include in their Registration Agreements a provision prohibiting
Registered Name
Holders from *distributing malware, abusively operating botnets,
phishing, piracy, trademark or
copyright infringement, fraudulent or deceptive practices,
counterfeiting or otherwise engaging in
activity contrary to applicable law, *and providing (consistent with
applicable law and any related
procedures) consequences for such activities including suspension of the
domain name." [I added the bold]
Certainly the SubPro WG majority wanted New gTLD registries /to do all
of this enforcement actively -- and yet_trademark and copyright
infringement and alleged fraudulent and deceptive or counterfeiting
issues are *content and contrary to ICANN Bylaws - we don't regulate
content in ICANN *(as the June 8th, 2024, ICANN Board Resolution in
Kigali confirmed)._/
But some leading members of the SubPro Implementation Review Team don't
like this June 8th resolution (and don't remember we told that the
SubPro WG recommendations on this topic were contrary to ICANN Bylaws).
>From they perspective: if the SubPro WG recommended it, they want it
done just that way.
But ICANN cannot look at fraudulent content on a webpage - because
fraudulent content is content (for example, I post that my washing
detergent is better than yours - my Tide and better than your Arm&
Hammer. In the US, comparative advertising is legal; in Germany, it is
not. Regardless, Arm & Hammer wants to take down my website down saying
that my claims (as Tide) are fraudulent... and wants the Registr/y to
enforce it, but ICANN cannot regulate content. This is a legal issue
outside of ICANN.
/
Appropriately (IMHO), ICANN Org (recently in the SubPro IRT) countered
and offered the IRT an alternative that I consider reasonable: ICANN
Org wrote and said that "fraud" within ICANN's mission is how a Registry
manages its registry business. For example (and these are my examples):
if a Registry says that it is putting new domain names into the root,
and instead resells them via another registry (charging twice), that
would be fraudulent.
/But if someone says that a Registry is engaged in fraud of this sort --
how does ICANN know? /ICANN Org now says that the person/company/group
should go to court for a finding of fraud against the Registry - and
then bring it to ICANN. Or go to a government consumer protection
agency - and bring their finding to ICANN. /Then ICANN will know what is
illegal and fraudulent from an expert tribunal (within the scope of the
Bylaws) and will act. That seems fair and right to me.
/
But if anyone (an IP attorney, etc) can bring a PICDRP action against
any registry at any time in the PICDRP, then we will find the
definitions of fraud expanding to content - right way -- because so many
see DNS abuse as one continuum (although NCSG does not) and including --
*trademark of copyright infringement, fraudulent or deceptive practices,
counterfeiting, etc.
*
*
*
As our only actived participant in the SubPro IRT at this time (and I've
attended the last 30 meetings), I share:
I agree with what ICANN Org recommended and disagree with the Liaisons
of the Implementation Review Team.
Best and tx, Kathy
-------- Forwarded Message --------
Subject: Fwd: [council] Council Agenda Item 7: Implementation of SubPro
Rec 36.4
Date: Mon, 12 May 2025 23:18:59 +1000
From: Tomslin Samme-Nlar <mesumbeslin at GMAIL.COM>
Reply-To: Tomslin Samme-Nlar <mesumbeslin at GMAIL.COM>
To: NCSG-DISCUSS at LISTSERV.SYR.EDU
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-pc/attachments/20250512/d6bfc674/attachment-0001.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-pc/attachments/20250512/d6bfc674/attachment-0001.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: 60382
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20250512/d6bfc674/attachment-0001.eml>
More information about the NCSG-PC
mailing list