<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Tomslin and all of our Counselors, <br>
</p>
<p>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. <br>
</p>
<p><b>Here's some more background: </b>For the IPC, fraud is one
of a series of content issues they think registries and registrars
should handle: For example: </p>
<p>=> [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<br>
Holders from <b>distributing malware, abusively operating
botnets, phishing, piracy, trademark or<br>
copyright infringement, fraudulent or deceptive practices,
counterfeiting or otherwise engaging in<br>
activity contrary to applicable law, </b>and providing
(consistent with applicable law and any related<br>
procedures) consequences for such activities including suspension
of the domain name." [I added the bold]</p>
<p>Certainly the SubPro WG majority wanted New gTLD registries <i>to
do all of this enforcement actively -- and yet<u> trademark and
copyright infringement and alleged fraudulent and deceptive or
counterfeiting issues are <b>content and contrary to ICANN
Bylaws - we don't regulate content in ICANN </b>(as the
June 8th, 2024, ICANN Board Resolution in Kigali confirmed).</u></i></p>
<p>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.</p>
<p>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<i>y to enforce it, but ICANN
cannot regulate content. This is a legal issue outside of ICANN.
<br>
</i></p>
<p>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. </p>
<p><i>But if someone says that a Registry is engaged in fraud of
this sort -- how does ICANN know? </i>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. <i>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. <br>
</i></p>
<div class="moz-forward-container">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 -- <b>trademark
of copyright infringement, fraudulent or deceptive practices,
counterfeiting, etc. <br>
</b></div>
<div class="moz-forward-container"><b><br>
</b></div>
<div class="moz-forward-container">As our only actived participant
in the SubPro IRT at this time (and I've attended the last 30
meetings), I share: </div>
<div class="moz-forward-container"><br>
</div>
<div class="moz-forward-container">I agree with what ICANN Org
recommended and disagree with the Liaisons of the Implementation
Review Team. <br>
</div>
<div class="moz-forward-container"><br>
</div>
<div class="moz-forward-container">Best and tx, Kathy<br>
-------- Forwarded Message --------
<table cellpadding="0" cellspacing="0" border="0"
class="moz-email-headers-table">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Subject:
</th>
<td>Fwd: [council] Council Agenda Item 7: Implementation of
SubPro Rec 36.4</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Date: </th>
<td>Mon, 12 May 2025 23:18:59 +1000</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">From: </th>
<td>Tomslin Samme-Nlar <a class="moz-txt-link-rfc2396E" href="mailto:mesumbeslin@GMAIL.COM"><mesumbeslin@GMAIL.COM></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Reply-To:
</th>
<td>Tomslin Samme-Nlar <a class="moz-txt-link-rfc2396E" href="mailto:mesumbeslin@GMAIL.COM"><mesumbeslin@GMAIL.COM></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU">NCSG-DISCUSS@LISTSERV.SYR.EDU</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<div dir="ltr">
<div dir="ltr">
<div>Hi NCSG,</div>
<div><br>
</div>
<div>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.</div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>Remain blessed,<br>
</div>
Tomslin</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">---------- Forwarded
message ---------<br>
From: <b class="gmail_sendername" dir="auto">Susan Payne
via council</b> <span dir="auto"><<a
href="mailto:council@icann.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">council@icann.org</a>></span><br>
Date: Fri, 9 May 2025 at 02:59<br>
Subject: [council] Council Agenda Item 7: Implementation
of SubPro Rec 36.4<br>
To: <a href="mailto:council@icann.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">council@icann.org</a>
<<a href="mailto:council@icann.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">council@icann.org</a>><br>
Cc: Tomslin Samme-Nlar via council <<a
href="mailto:council@icann.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">council@icann.org</a>><br>
</div>
<br>
<br>
<div>
<div lang="EN-GB" link="#467886" vlink="#96607D"
style="word-wrap:break-word">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Dear
Council colleagues,</span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> This
relates to agenda item 7 at our Council meeting of
15 May 2025.
</span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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:</span></p>
<p class="MsoNormal"
style="margin-bottom:12.25pt;text-indent:72.0pt">
<span style="font-size:12.0pt;color:black">4.3(f) </span>
<span style="font-size:12.0pt">ICANN may, upon
notice to Registry Operator, terminate this
Agreement if</span></p>
<p class="MsoNormal"
style="margin-bottom:12.25pt;margin-left:36.0pt">
<span style="font-size:12.0pt"> (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 </span></p>
<p class="MsoNormal"
style="margin-bottom:12.25pt;margin-left:36.0pt">
<span style="font-size:12.0pt">(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.</span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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:</span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">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</span></b><span
style="font-size:12.0pt">.
<span style="color:red">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</span>,<span
style="color:red"> which Rec 36.4 sought to
remedy, ICANN proposes NOT to include such a
provision in the RA.
</span></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">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</span></b><span
style="font-size:12.0pt">.
<span style="color:red">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.</span></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">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:</span></b><span
style="font-size:12.0pt"></span></p>
<p class="MsoNormal" style="margin-left:72.0pt">
<b><span
style="font-size:12.0pt;font-family:"Courier New"">o</span></b><b><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">commence
dispute resolution actions under the Registry
Agreement (Currently Article 5 of the Registry
Agreement), or
</span></b><span style="font-size:12.0pt"></span></p>
<p class="MsoNormal" style="margin-left:72.0pt">
<b><span
style="font-size:12.0pt;font-family:"Courier New"">o</span></b><b><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">appoint
a panel under the PICDRP</span></b><span
style="font-size:12.0pt">. <span
style="color:red"> 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</span> <span
style="color:red">(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).
</span></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:Symbol">·</span></b><b><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span></b><b><span style="font-size:12.0pt">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.</span></b><span
style="font-size:12.0pt;color:red"> ICANN
proposes NOT to include this language.
</span><span style="font-size:12.0pt"></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> By
way of additional detail, we have (attached):</span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:12.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span style="font-size:12.0pt">an explanation
from Karla Hakansson of how staff propose to
implement Rec 36.4 and why</span></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:12.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span style="font-size:12.0pt">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.</span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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. </span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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.</span></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">What
action might Council take?
</span></b><span style="font-size:12.0pt">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.
</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>Susan and Anne</b></p>
<p class="MsoNormal">Joint Council Liaisons to SubPro
IRT</p>
<p class="MsoNormal"> </p>
</div>
<hr>
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
<a href="https://comlaude.com" target="_blank"
moz-do-not-send="true">www.comlaude.com</a>
</div>
_______________________________________________<br>
council mailing list -- <a
href="mailto:council@icann.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">council@icann.org</a><br>
To unsubscribe send an email to <a
href="mailto:council-leave@icann.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">council-leave@icann.org</a><br>
<br>
_______________________________________________<br>
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 (<a
href="https://www.icann.org/privacy/policy"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a
href="https://www.icann.org/privacy/tos"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.icann.org/privacy/tos</a>).
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.</div>
</div>
</div>
</div>
</div>
</body>
</html>