<div dir="auto"><div>Hi Kathy, all,</div><div dir="auto"><br></div><div dir="auto">Thanks for that input, very helpful. </div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">As an IRT member, do you know of anything we could use to strengthen your argument from a procedural perspective?</div><div><br></div><div data-smartmail="gmail_signature">Remain blessed, <br>Tomslin</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 13 May 2025, 02:26 Kathy Kleiman, <kathy@dnrc.tech> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<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>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><b><br>
</b></div>
<div>As our only actived participant
in the SubPro IRT at this time (and I've attended the last 30
meetings), I share: </div>
<div><br>
</div>
<div>I agree with what ICANN Org
recommended and disagree with the Liaisons of the Implementation
Review Team. <br>
</div>
<div><br>
</div>
<div>Best and tx, Kathy<br>
-------- Forwarded Message --------
<table cellpadding="0" cellspacing="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT" 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>Date: </th>
<td>Mon, 12 May 2025 23:18:59 +1000</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap>From: </th>
<td>Tomslin Samme-Nlar <a href="mailto:mesumbeslin@GMAIL.COM" target="_blank" rel="noreferrer"><mesumbeslin@GMAIL.COM></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap>Reply-To:
</th>
<td>Tomslin Samme-Nlar <a href="mailto:mesumbeslin@GMAIL.COM" target="_blank" rel="noreferrer"><mesumbeslin@GMAIL.COM></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap>To: </th>
<td><a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU" target="_blank" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">council@icann.org</a>
<<a href="mailto:council@icann.org" target="_blank" rel="noreferrer">council@icann.org</a>><br>
Cc: Tomslin Samme-Nlar via council <<a href="mailto:council@icann.org" target="_blank" rel="noreferrer">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 <a href="https://www.google.com/maps/search/28%0D%0A++++++++++++++++Little+Russell+Street,+London,+WC1A+2HN+England?entry=gmail&source=g">28
Little Russell Street, London, WC1A 2HN England</a>. 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 <a href="https://www.google.com/maps/search/28+Little%0D%0A++++++++++++++++Russell+Street,+London,+WC1A+2HN+England?entry=gmail&source=g">28 Little
Russell Street, London, WC1A 2HN England</a>; Valideus
Limited, a company registered in England and Wales with
company number 6181291 and registered office at <a href="https://www.google.com/maps/search/28%0D%0A++++++++++++++++Little+Russell+Street,+London,+WC1A+2HN+England?entry=gmail&source=g">28
Little Russell Street, London, WC1A 2HN England</a>; Demys
Limited, a company registered in Scotland with company
number SC197176 and registered office at <a href="https://www.google.com/maps/search/15+William%0D%0A++++++++++++++++Street,+South+West+Lane,+Edinburgh,+EH3+7LL+Scotland?entry=gmail&source=g">15 William
Street, South West Lane, Edinburgh, EH3 7LL Scotland</a>;
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 <a href="https://www.google.com/maps/search/Calle+Barcas+2?entry=gmail&source=g">Calle Barcas 2</a>, 2,
Valencia, 46002, Spain. For further information see
<a href="https://comlaude.com" target="_blank" rel="noreferrer">www.comlaude.com</a>
</div>
_______________________________________________<br>
council mailing list -- <a href="mailto:council@icann.org" target="_blank" rel="noreferrer">council@icann.org</a><br>
To unsubscribe send an email to <a href="mailto:council-leave@icann.org" target="_blank" rel="noreferrer">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 noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer noreferrer" target="_blank">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>
</div>
<br><br><br>---------- Forwarded message ----------<br>From: Jeff Neuman via SubPro-IRT <<a href="mailto:subpro-irt@icann.org" target="_blank" rel="noreferrer">subpro-irt@icann.org</a>><br>To: Karla Hakansson <<a href="mailto:karla.hakansson@icann.org" target="_blank" rel="noreferrer">karla.hakansson@icann.org</a>>, Anne ICANN <<a href="mailto:anneicanngnso@gmail.com" target="_blank" rel="noreferrer">anneicanngnso@gmail.com</a>>, Jared Erwin via SubPro-IRT <<a href="mailto:subpro-irt@icann.org" target="_blank" rel="noreferrer">subpro-irt@icann.org</a>><br>Cc: <br>Bcc: <br>Date: Wed, 30 Apr 2025 19:38:35 +0000<br>Subject: [SubPro-IRT] Re: [Ext] Base RA redline<br>
<div lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="m_7949973189238896168WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Dear Anne and Susan,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
The .feedback PICDRP report (<a href="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" target="_blank" rel="noreferrer">found
here</a>) 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.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><u><span style="font-size:11.0pt">Recommendation 36.4 </span>
</u><span style="font-size:11.0pt">“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.”</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<ul style="margin-top:0in" type="disc">
<li class="m_7949973189238896168MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt">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. </span></li><li class="m_7949973189238896168MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt">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.</span></li><li class="m_7949973189238896168MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt">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).</span></li><li class="m_7949973189238896168MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt">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.</span></li></ul>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">To reiterate the SubPro Recommendation:</span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="m_7949973189238896168MsoListParagraph" style="color:red;margin-left:0in"><span style="font-size:11.0pt;color:windowtext">ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices.
</span><span style="font-size:11.0pt">– ICANN has not done this.</span></li><li class="m_7949973189238896168MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt">If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach
<span style="color:#4ea72e">– ICANN has done this</span>.</span></li><li class="m_7949973189238896168MsoListParagraph" style="margin-left:0in"><span style="font-size:11.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 commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. <span style="color:red">ICANN has NOT done this</span>.</span></li></ol>
<p class="m_7949973189238896168MsoListParagraph"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Sincerely,<br>
<br>
Jeff</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<div>
<p class="MsoNormal"><span style="color:black"><img border="0" width="364" height="121" style="width:3.7916in;height:1.2583in" id="m_7949973189238896168Picture_x0020_1" src="cid:image001.png@01DBB9E1.FBFDB550"></span><span></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Karla Hakansson via SubPro-IRT <<a href="mailto:subpro-irt@icann.org" target="_blank" rel="noreferrer">subpro-irt@icann.org</a>>
<br>
<b>Sent:</b> Wednesday, April 30, 2025 1:12 PM<br>
<b>To:</b> Anne ICANN <<a href="mailto:anneicanngnso@gmail.com" target="_blank" rel="noreferrer">anneicanngnso@gmail.com</a>>; Jared Erwin via SubPro-IRT <<a href="mailto:subpro-irt@icann.org" target="_blank" rel="noreferrer">subpro-irt@icann.org</a>><br>
<b>Cc:</b> <a href="mailto:subpro-irt@icann.org" target="_blank" rel="noreferrer">subpro-irt@icann.org</a><br>
<b>Subject:</b> [SubPro-IRT] Re: [Ext] Base RA redline</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Anne, </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki:
<a rel="noreferrer">
file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf</a></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Best, </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Karla</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;color:black">From:
</span></b><span style="font-family:"Calibri",sans-serif;color:black">Anne ICANN <<a href="mailto:anneicanngnso@gmail.com" target="_blank" rel="noreferrer">anneicanngnso@gmail.com</a>><br>
<b>Date: </b>Tuesday, April 29, 2025 at 15:52<br>
<b>To: </b>Karla Hakansson <<a href="mailto:karla.hakansson@icann.org" target="_blank" rel="noreferrer">karla.hakansson@icann.org</a>>, Jared Erwin via SubPro-IRT <<a href="mailto:subpro-irt@icann.org" target="_blank" rel="noreferrer">subpro-irt@icann.org</a>><br>
<b>Subject: </b>[Ext] Base RA redline</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">Hi Karla,</p>
</div>
<div>
<p class="MsoNormal">Do we currently have a link to the entire Base RA redline as previously requested?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">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?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thank you,</p>
</div>
<div>
<p class="MsoNormal">Anne</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Anne Aikman-Scalese</p>
</div>
<p class="MsoNormal">GNSO Councilor </p>
<div>
<p class="MsoNormal">NomCom Non-Voting 2022-2026</p>
</div>
<div>
<p class="MsoNormal"><a href="mailto:anneicanngnso@gmail.com" target="_blank" rel="noreferrer">anneicanngnso@gmail.com</a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
NCSG-PC mailing list<br>
<a href="mailto:NCSG-PC@lists.ncsg.is" target="_blank" rel="noreferrer">NCSG-PC@lists.ncsg.is</a><br>
<a href="https://lists.ncsg.is/mailman/listinfo/ncsg-pc" rel="noreferrer noreferrer" target="_blank">https://lists.ncsg.is/mailman/listinfo/ncsg-pc</a><br>
</blockquote></div>