<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Although I served as a member, I am not speaking for the CCT Review Team. So what was my thinking in supporting these recommendations?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">ICANN committed to engender competition, consumer choice and consumer trust in the DNS; check the AOC. The review team was chartered to see how well competition, choice, and trust are holding up and what to do if threats to conservation are uncovered. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">We are clear the product of the concession is complicit in doing harm to end users. Defrauded end users lose trust. Abnormal extraction of value from end users causes them to think there is a breakdown in the security of the DNS. Taken together, this development devalues competition objectives, undermines consumer trust and suppresses consumer choice. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Mitigating systemic harms require systemic action. How we address harm at source when the harm, on its face, is an extension of an ordinary business process? Some of us thought a product liability framework may not be the right approach but certainly elements of that thinking could be useful for mitigation. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">We could avoid capricious compliance action, systematically privilege registrants who rent for non-fraudulent use and incentivize contracted parties to go beyond current commercial practice to winnon out registrant fraudsters. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The CCT outlined a very modest framework proposal. Rejected. Let's see a better mousetrap then. </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><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br>==============================<br><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 Fri, 15 Sept 2023 at 17:20, Karl Auerbach <<a href="mailto:karl@cavebear.com" target="_blank">karl@cavebear.com</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">
<div>
<p>In order to avoid reading the actual text (yes, I am lazy) what
is the definition of "DNS security abuse"?</p>
<p>The reason I ask is that I've seen the phrase "DNS abuse" (absent
the word "security") tossed about to whine (yes I am being
hyperbolic and pejorative) about things such as "this or that
practice annoys my cat" or "go to website abc.def.tld and buy
solid gold 1kg bars for $1 each." The first is simply out of
ICANN's scope and the second probably violates
fraud/misrepresentation laws in pretty much every country and
ought to be beyond ICANN's scope. I would put anything that is
covered by national and international trademark law outside the
umbra or penumbra of the word "security".<br>
</p>
<p>On the other hand it would, to my mind, be quite within ICANN's
scope to knock registr* bodies and TLD server operators if they do
bad things, like leaving logins open via telnet (clear text
passwords) or are running on easily penetrated foundations such as
(let me pick a crazy example) Windows 95.<br>
</p>
<p> --karl--<br>
</p>
<div>On 9/15/23 10:58 AM, Carlton Samuels
via At-Large wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div 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 style="font-family:tahoma,sans-serif"> </div>
<div 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 style="font-family:tahoma,sans-serif"><br>
</div>
<div 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 style="font-family:tahoma,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"><br>
</span></div>
<div 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 style="font-family:tahoma,sans-serif"><br>
</div>
<div 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 style="font-family:tahoma,sans-serif"><br>
</div>
<div style="font-family:tahoma,sans-serif">Our ICANN don't play
that!</div>
<div style="font-family:tahoma,sans-serif"><br>
</div>
<div style="font-family:tahoma,sans-serif">Carlton </div>
<div 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 | <a href="mailto:bzs@TheWorld.com" target="_blank">bzs@TheWorld.com</a> |
<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>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
At-Large mailing list
<a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a>
At-Large Official Site: <a href="http://atlarge.icann.org" target="_blank">http://atlarge.icann.org</a>
_______________________________________________
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" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" 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.</pre>
</blockquote>
</div>
</blockquote></div></div>