<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">If you missed it, after a year in pending status, the ICANN Board just voted to reject Recs 14 & 15 from the CCT Review. These were offered for mitigating systemic DNS <b><u>security</u></b> abuse. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"> </div><div class="gmail_default" style="font-family:tahoma,sans-serif">#14 recommends amendments offering incentives - inclusive of financial ones - in<span style="font-family:Arial,Helvetica,sans-serif"> the [RA/RAA] Agreements for the contracted parties adopting p</span><span style="font-family:Arial,Helvetica,sans-serif">roactive anti-abuse measures. Nothing too heretical. </span></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">#15 recommends amendments to [RA/RAA] Agreements that establish <span style="font-family:Arial,Helvetica,sans-serif">thresholds of abuse at which compliance inquiries are automatically </span><span style="font-family:Arial,Helvetica,sans-serif">triggered and a higher one at which registrars and registries are presumed </span><span style="font-family:Arial,Helvetica,sans-serif">to be in default of their agreements. </span></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">We went on to recommend </span><span style="font-family:Arial,Helvetica,sans-serif">a community-developed DNS Abuse Dispute Resolution Policy (DADRP) i</span><span style="font-family:Arial,Helvetica,sans-serif">f ICANN Compliance falls asleep on the enforcement job. [The text delicately eased into that like only "...<i>i</i></span><i><span style="font-family:Arial,Helvetica,sans-serif">f the community determines that ICANN org </span><span style="font-family:Arial,Helvetica,sans-serif">itself is ill-suited or unable to enforce such provisions.</span></i><span style="font-family:Arial,Helvetica,sans-serif">"]</span> </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">In my own view #14 is something regulators do with concessionaires time and again. Even the "light touch and by suasion" telecoms ones I know well in my home region. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Our ICANN don't play that!</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Carlton </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:large"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">==============================</span><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><i><font face="comic sans ms, sans-serif">Carlton A Samuels</font></i><br><font face="comic sans ms, sans-serif"><i>Mobile: 876-818-1799<br><font color="#33CC00">Strategy, Process, Governance, Assessment & Turnaround</font></i></font><br>=============================</div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 14 Sept 2023 at 20:33, Barry Shein via At-Large <<a href="mailto:at-large@atlarge-lists.icann.org" target="_blank">at-large@atlarge-lists.icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
As a company which provides email and other internet services maybe if<br>
the new gTLDs agreements included some serious commitment to avoid<br>
allowing the use of these gTLDs for massive spamming and phishing etc<br>
maybe the service providers would have been more enthusiastic about<br>
acceptance.<br>
<br>
Unfortunately the opposite is true and many of these new gTlDs can<br>
safely be blocked in entirety, they just spew spam etc, with no<br>
customer complaints.<br>
<br>
I'll guess these new gTLD registrars/registries would complain that's<br>
not equitable since it's not required of other TLDs.<br>
<br>
Which is all a very nice argument to make sitting in an airless room<br>
somewhere.<br>
<br>
So instead they tend to get blocked and ignored, or at least marked<br>
"suspicious" by spam filters, but equitably!<br>
<br>
If I had a nickel for every ISP who said or recommended "oh just block<br>
all .pick-a-nGTLD, you and your customers will be happier"...<br>
<br>
-- <br>
-Barry Shein<br>
<br>
Software Tool & Die | bzs@TheWorld.com | <a href="http://www.TheWorld.com" rel="noreferrer" target="_blank">http://www.TheWorld.com</a><br>
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD<br>
The World: Since 1989 | A Public Information Utility | *oo*<br>
_______________________________________________<br>
At-Large mailing list<br>
<a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a><br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" rel="noreferrer" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br>
<br>
At-Large Official Site: <a href="http://atlarge.icann.org" rel="noreferrer" target="_blank">http://atlarge.icann.org</a><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">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">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.<br>
</blockquote></div></div>