[NCSG-PC] Fwd: Fwd: [council] Council Agenda Item 7: Implementation of SubPro Rec 36.4 - Deep concerns

[Tomslin Samme-Nlar]

Hi Kathy, all,

Thanks for that input, very helpful.
I didn't mention this during our PC meeting, but I believe the scope of the
discussion in the council will be around the procedural and interpretation
aspects of the issue, since this is about an already board-adopted
recommendation.

I agree with the point you make but i think the question will end up being:
is ICANN implementing the recommendation as written? (Atleast from a
council perspective). If not, which process can be used to retract board
adoption of the recommendation.

As an IRT member, do you know of anything we could use to strengthen your
argument from a procedural perspective?

Remain blessed,
Tomslin

On Tue, 13 May 2025, 02:26 Kathy Kleiman, <kathy at dnrc.tech> wrote:

> 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> <mesumbeslin at GMAIL.COM>
> Reply-To: Tomslin Samme-Nlar <mesumbeslin at GMAIL.COM>
> <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
> <https://www.google.com/maps/search/28%0D%0A++++++++++++++++Little+Russell+Street,+London,+WC1A+2HN+England?entry=gmail&source=g>.
> 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
> <https://www.google.com/maps/search/28+Little%0D%0A++++++++++++++++Russell+Street,+London,+WC1A+2HN+England?entry=gmail&source=g>;
> 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
> <https://www.google.com/maps/search/28%0D%0A++++++++++++++++Little+Russell+Street,+London,+WC1A+2HN+England?entry=gmail&source=g>;
> 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
> <https://www.google.com/maps/search/15+William%0D%0A++++++++++++++++Street,+South+West+Lane,+Edinburgh,+EH3+7LL+Scotland?entry=gmail&source=g>;
> 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
> <https://www.google.com/maps/search/Calle+Barcas+2?entry=gmail&source=g>,
> 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.
>
>
>
> ---------- Forwarded message ----------
> From: Jeff Neuman via SubPro-IRT <subpro-irt at icann.org>
> To: Karla Hakansson <karla.hakansson at icann.org>, Anne ICANN <
> anneicanngnso at gmail.com>, Jared Erwin via SubPro-IRT <subpro-irt at icann.org
> >
> Cc:
> Bcc:
> Date: Wed, 30 Apr 2025 19:38:35 +0000
> Subject: [SubPro-IRT] Re: [Ext] Base RA redline
>
> 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://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles%2Ffiles%2Ffeedback-picdrp-panel-report-14mar17-en.pdf&data=05%7C02%7Csusan.payne%40comlaude.com%7Cafe90a852170423d72cb08dd881eabfe%7C442149eed2004029b9b18f029e916b85%7C0%7C0%7C638816387512634054%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8lqG7kEiosf%2BPg2%2FmxUwTEyuNOm%2BOxmRSntilzMfsaw%3D&reserved=0>)
> 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
>
>
>
>
>
> *From:* Karla Hakansson via SubPro-IRT <subpro-irt at icann.org>
> *Sent:* Wednesday, April 30, 2025 1:12 PM
> *To:* Anne ICANN <anneicanngnso at gmail.com>; Jared Erwin via SubPro-IRT <
> subpro-irt at icann.org>
> *Cc:* subpro-irt at icann.org
> *Subject:* [SubPro-IRT] Re: [Ext] Base RA redline
>
>
>
> Hi Anne,
>
>
>
> You can find the NxR Base RA redline in the working documents under Topic
> 36: Base RA on the SubPro IRT wiki:
> file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf
>
>
>
> Still TBD on the date when we post the RA for public comment. We are
> shooting for the end of May. The public comment period will be the standard
> 40 days.
>
>
>
> Best,
>
> Karla
>
>
>
> *From: *Anne ICANN <anneicanngnso at gmail.com>
> *Date: *Tuesday, April 29, 2025 at 15:52
> *To: *Karla Hakansson <karla.hakansson at icann.org>, Jared Erwin via
> SubPro-IRT <subpro-irt at icann.org>
> *Subject: *[Ext] Base RA redline
>
>
>
> Hi Karla,
>
> Do we currently have a link to the entire Base RA redline as previously
> requested?
>
>
>
> Will the Base RA language be going out for public comment at the same time
> as the draft AGB in its entirety?  How long with the public comment period
> be?
>
>
>
> Thank you,
>
> Anne
>
>
>
> Anne Aikman-Scalese
>
> GNSO Councilor
>
> NomCom Non-Voting 2022-2026
>
> anneicanngnso at gmail.com
> _______________________________________________
> NCSG-PC mailing list
> NCSG-PC at lists.ncsg.is
> https://lists.ncsg.is/mailman/listinfo/ncsg-pc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20250514/40e74963/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13020 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20250514/40e74963/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13020 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20250514/40e74963/attachment-0003.png>