On 12/09/2023 18:17, Bill Jouris via At-Large wrote: isoc-il encountered a very similar problem. We implemented a new IDN ccTLD last year and planned a roll out only to find that no browser was recognizing the new IDN ccTLD.    We had to delay the rollout by 4 months: https://en.isoc.org.il/il-cctld/idn We had  discovered the issue of PSL. We had looked at ICANN  IDN Implementation Guidelines for guidance: https://www.icann.org/resources/pages/implementation-guidelines-2012-02-25-e... which did not indicate anything about updating the PSL. [Incidentally, buried in ICANN is this doc: The Public Suffix List: A Guide for TLD Administrators https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf] So I contacted the UA (Universal Acceptance) - https://www.icann.org/uasg-en and https://uasg.tech/ Among the quotes I received: "The IDN Guidelines generally have limited focus on security/stability related matters related to IDNs offered by the top-level domain registries and registrars. This issue is related more to the usability of IDNs, which is generally taken up through the UA related work" which sort of is contradicted by - https://icannwiki.org/PSL which states: "The PSL is a Mozilla initiative but is community-maintained. It is primarily used by web browser manufacturers and other domain-related software. This resource is crucial to the Universal Acceptance <https://icannwiki.org/Universal_Acceptance> of TLDs <https://icannwiki.org/TLD>." I would say that isoc-il was disappointed by ICANN's handling of this issue and their lack of willingness to better document this issue for future TLD owners. Regards, Hank Nussbacher

He complains that he couldn't get ICANN interested in the problem. It would be interesting to know just who at ICANN he was talking to.

Bill Jouris

Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_Andr...>

On Tue, Sep 12, 2023 at 7:43 AM, Dev Anand Teelucksingh via At-Large <at-large@atlarge-lists.icann.org> wrote: "*Developers of major pieces of internet software, including the world’s most-popular messaging app, may be relying on seriously outdated lists of top-level domains.*

That’s the picture that seems to be emerging from one new gTLD operator’s quest to discover why WhatsApp doesn’t recognize its TLD, and many others including major dot-brands, as valid."

....When most social media apps detect the user has inputted a URL or domain name, they automatically “linkify” it so it can be easily clicked or tapped without the need for copy/paste.

But when Rami Schwartz of new gTLD .tube discovered that .tube URLs sent via WhatsApp, said to have two billion users, were not being linkified, despite the TLD being delegated by ICANN almost eight years ago, he set out to find out why.

Schwartz compiled a spreadsheet (.xlsx) listing which gTLDs are recognized by WhatsApp and which are not and discovered a rough cut-off point in November 2015. TLDs delegated before then are linkified, those delegated after were not......This means that, for example, .microsoft domains linkify but .amazon and .apple domains do not; .asia domains linkify but .africa and .arab domains do not; .london works but .abudhabi doesn’t. Even .verisign missed the cut-off.

If WhatsApp users include a “www.” or “http://” then the app will linkify the domain, even if the specified TLD does not exist.

.....During the course of a discussion <https://github.com/publicsuffix/list/issues/1807> on the web site of the Public Suffix List — which maintains an open-source list of all TLDs and the levels at which names may be registered — it was discovered that the problem may be deeper rooted than the WhatsApp app.

It turns out a library in the Android operating system <https://cs.android.com/android/platform/superproject/main/+/main:frameworks/...> contains a hard-coded list of valid TLDs which hasn’t been updated since November 24, 2015"

Read full article : https://domainincite.com/29054-is-this-why-whatsapp-hates-some-tlds-but-not-...

Regards,

Dev Anand Teelucksingh _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

Folks, While I agree with Evan that most Internet users don’t know and don’t care about some less used TLDs - in the same way as most drivers and car buyers don’t know and don’t care about some less used car brands - I am missing something about the “problem" that started this thread, i.e.: Developers of major pieces of internet software, including the world’s most-popular messaging app, may be relying on seriously outdated lists of top-level domains. There is one single authoritative source of information, maintained by IANA, that is the root zone file. Why on earth should ICANN maintain a second one? This fancy tendency by developers (I can say that, as I have been in that business for decades) to rely on alternate sources of information and/or make incorrect assumptions (like assuming that TLDs are max 3 chars long, except for ARPA) is the root cause of most of the problems. By the way, when we say “One world, one Internet” we implicitly condemn having alternate or secondary sources of information about the Internet components. Cheers, Roberto

On 13.09.2023, at 15:50, Evan Leibovitch via At-Large <at-large@atlarge-lists.icann.org> wrote:

Can't say that I'm surprised. Welcome to the totally predictable consequences of ICANN's: Insisting that it's not a regulator Making "global" decisions without weight of international treaty Expanding the gTLD space *well* beyond that which benefits Internet users. At-Large's most useful activity is to document and publicize the list of gTLDs unrecognized by the Android library, and to encourage ICANN to engage with Android developers to update the library.

It should be telling that nobody has noticed this problem that has existed since 2015, and that the news appeared in an industry news site rather than in the IT mainstream. That tells me that most Internet end-users don't know and don't care about these other domains.

There's a lesson here to be learned.

Evan Leibovitch, Toronto Canada @evanleibovitch / @el56

On Tue, Sep 12, 2023 at 10:43 AM Dev Anand Teelucksingh via At-Large <at-large@atlarge-lists.icann.org <mailto:at-large@atlarge-lists.icann.org>> wrote: "Developers of major pieces of internet software, including the world’s most-popular messaging app, may be relying on seriously outdated lists of top-level domains. That’s the picture that seems to be emerging from one new gTLD operator’s quest to discover why WhatsApp doesn’t recognize its TLD, and many others including major dot-brands, as valid."

....When most social media apps detect the user has inputted a URL or domain name, they automatically “linkify” it so it can be easily clicked or tapped without the need for copy/paste.

But when Rami Schwartz of new gTLD .tube discovered that .tube URLs sent via WhatsApp, said to have two billion users, were not being linkified, despite the TLD being delegated by ICANN almost eight years ago, he set out to find out why.

Schwartz compiled a spreadsheet (.xlsx) listing which gTLDs are recognized by WhatsApp and which are not and discovered a rough cut-off point in November 2015. TLDs delegated before then are linkified, those delegated after were not......This means that, for example, .microsoft domains linkify but .amazon and .apple domains do not; .asia domains linkify but .africa and .arab domains do not; .london works but .abudhabi doesn’t. Even .verisign missed the cut-off.

If WhatsApp users include a “www.” or “http://” then the app will linkify the domain, even if the specified TLD does not exist.

.....During the course of a discussion <https://github.com/publicsuffix/list/issues/1807> on the web site of the Public Suffix List — which maintains an open-source list of all TLDs and the levels at which names may be registered — it was discovered that the problem may be deeper rooted than the WhatsApp app. It turns out a library in the Android operating system <https://cs.android.com/android/platform/superproject/main/+/main:frameworks/...> contains a hard-coded list of valid TLDs which hasn’t been updated since November 24, 2015"

Read full article : https://domainincite.com/29054-is-this-why-whatsapp-hates-some-tlds-but-not-... <https://domainincite.com/29054-is-this-why-whatsapp-hates-some-tlds-but-not-...>

Regards,

Dev Anand Teelucksingh _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org <mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large <https://atlarge-lists.icann.org/mailman/listinfo/at-large>

At-Large Official Site: http://atlarge.icann.org <http://atlarge.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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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. _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

Hi Hank Thanks for confirming my points. As PSL states: "It is in the interest of Internet registries to see that their section of the list is up to date.”. Exactly. It is up to the contracted parties to deal with the matter, not the Internet user community. xkcd's picture expresses colourfully - although in B&W - what I stated, we are sometimes at the mercy of creative developers upon which some bits and pieces of the Internet infrastructure might have been built. This affects users, of course, but the solution is not to be found in users’ approach, nor in ICANN’s supposed supervisory powers, but in a self-managed behaviour of the software industry. It is upon this industry to develop according to standards and not to personal intuitions of developers, to make sure that a maintenance path is designed and enforced, that audit trails are implemented, etc. What the mainstream IT industry has learned at its own expenses at the eve of the year 2000 seems to be still ignored by large part of the commercial Internet software development industry, where creative approaches are the rule to bring fast to the market products that are poorly tested, not even to speak about adherence to standards. I am not neglecting that we have a problem, I am just saying that At-Large is not the right place where to raise the issue asking for solutions. Cheers, Roberto

On 13.09.2023, at 19:22, Hank Nussbacher via At-Large <at-large@atlarge-lists.icann.org> wrote:

On 13/09/2023 17:55, Roberto Gaetano via At-Large wrote:

Welcome to the world of PSL - https://publicsuffix.org/ <https://publicsuffix.org/> xkcd nailed it: https://www.explainxkcd.com/wiki/index.php/2347:_Dependency <https://www.explainxkcd.com/wiki/index.php/2347:_Dependency>

Regards, Hank

...

Folks,

While I agree with Evan that most Internet users don’t know and don’t care about some less used TLDs - in the same way as most drivers and car buyers don’t know and don’t care about some less used car brands - I am missing something about the “problem" that started this thread, i.e.:

*/Developers of major pieces of internet software, including the world’s most-popular messaging app, may be relying on seriously outdated lists of top-level domains./*

There is one single authoritative source of information, maintained by IANA, that is the root zone file. Why on earth should ICANN maintain a second one? This fancy tendency by developers (I can say that, as I have been in that business for decades) to rely on alternate sources of information and/or make incorrect assumptions (like assuming that TLDs are max 3 chars long, except for ARPA) is the root cause of most of the problems.

By the way, when we say “One world, one Internet” we implicitly condemn having alternate or secondary sources of information about the Internet components.

Cheers, Roberto

...

On 13.09.2023, at 15:50, Evan Leibovitch via At-Large <at-large@atlarge-lists.icann.org> wrote:

Can't say that I'm surprised. Welcome to the totally predictable consequences of ICANN's:

* Insisting that it's not a regulator * Making "global" decisions without weight of international treaty * Expanding the gTLD space *well* beyond that which benefits Internet users.

At-Large's most useful activity is to document and publicize the list of gTLDs unrecognized by the Android library, and to encourage ICANN to engage with Android developers to update the library.

It should be telling that nobody has noticed this problem that has existed since 2015, and that the news appeared in an industry news site rather than in the IT mainstream. That tells me that most Internet end-users don't know and don't care about these other domains.

There's a lesson here to be learned.

Evan Leibovitch, Toronto Canada @evanleibovitch / @el56

On Tue, Sep 12, 2023 at 10:43 AM Dev Anand Teelucksingh via At-Large <at-large@atlarge-lists.icann.org> wrote:

"*Developers of major pieces of internet software, including the world’s most-popular messaging app, may be relying on seriously outdated lists of top-level domains.*

That’s the picture that seems to be emerging from one new gTLD operator’s quest to discover why WhatsApp doesn’t recognize its TLD, and many others including major dot-brands, as valid."

....When most social media apps detect the user has inputted a URL or domain name, they automatically “linkify” it so it can be easily clicked or tapped without the need for copy/paste.

But when Rami Schwartz of new gTLD .tube discovered that .tube URLs sent via WhatsApp, said to have two billion users, were not being linkified, despite the TLD being delegated by ICANN almost eight years ago, he set out to find out why.

Schwartz compiled a spreadsheet (.xlsx) listing which gTLDs are recognized by WhatsApp and which are not and discovered a rough cut-off point in November 2015. TLDs delegated before then are linkified, those delegated after were not......This means that, for example, .microsoft domains linkify but .amazon and .apple domains do not; .asia domains linkify but .africa and .arab domains do not; .london works but .abudhabi doesn’t. Even .verisign missed the cut-off.

If WhatsApp users include a “www.” or “http://” then the app will linkify the domain, even if the specified TLD does not exist.

.....During the course of a discussion <https://github.com/publicsuffix/list/issues/1807 <https://github.com/publicsuffix/list/issues/1807>> on the web site of the Public Suffix List — which maintains an open-source list of all TLDs and the levels at which names may be registered — it was discovered that the problem may be deeper rooted than the WhatsApp app.

It turns out a library in the Android operating system <https://cs.android.com/android/platform/superproject/main/+/main:frameworks/... <https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/util/Patterns.java;l=114>> contains a hard-coded list of valid TLDs which hasn’t been updated since November 24, 2015"

Read full article : https://domainincite.com/29054-is-this-why-whatsapp-hates-some-tlds-but-not-...

Regards,

Dev Anand Teelucksingh _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org <mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large <https://atlarge-lists.icann.org/mailman/listinfo/at-large>

At-Large Official Site: http://atlarge.icann.org <http://atlarge.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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org <mailto:At-Large@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/at-large <https://atlarge-lists.icann.org/mailman/listinfo/at-large>

At-Large Official Site: http://atlarge.icann.org <http://atlarge.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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.

Evan, if the At Large / ALAC's role is to inform - whom? I read from your note that it should be informing the broader community of users, developers, operators of all kinds of online services, etc. It has failed. Alejandro Pisanty On Wed, Sep 13, 2023 at 3:07 PM Evan Leibovitch via At-Large < at-large@atlarge-lists.icann.org> wrote:

Roberto Gaetano wrote:

I am just saying that At-Large is not the right place where to raise the

...

issue asking for solutions.

We are fully agreed that this is not At-Large's task to fix. I *will*, however, advance that it is At-Large's task to *inform*. We have an important but sadly neglected role to play in public education.

There are many issues related to domain names about which people may ask but for which answers are either absent, partial or inaccurate. The most obvious of these is explaining the difference between .co and .com -- that is, how is a ccTLD operationally different from a gTLD. The differences can be non-trivial to both domain consumers and end-users, and are complicated by the way some ccTLDs are marketed by gTLDs. Over the years I have not found an end-user perspective to this issue, only those which inform domain investors.

"Why are there so many TLDs and why can't I access some of them?", today's topic, is clearly another worthy of some treatment. And maybe someone somewhere can explain the status of the .su TLD.

We all know that ALAC sits very low on the list of ICANN community parts actually capable of affecting significant change. We're an expense to ICANN rather than a source of revenue, and we lack the economic clout of domain buyers and sellers or the political clout of the GAC.

That's not going to change any time soon (how's progress on that second At-Large Board seat coming along?) but that's OK. There is still much that we can do to inform end-users (that is, those who wish to be informed) with answers to questions that nobody else seems to be answering, from a perspective unlike any other within ICANN. After all, if we're going to represent the interests of end-users, having them as informed as possible is helpful.

- Evan

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . .

"My premise is that since ALAC's power to actually effect change within ICANN is so weak, that it may find its resources better spent on having end-users that are better informed about the ICANN issues that affect them. ALAC has the unique opportunity to speak to end-users in their vernacular from their perspective (which may not be the same as that of ICANN corporate). It has failed."

As a former NARALO ALAC member I disagree with the premise and the conclusion. ALAC's power to effect change is not weak; it is subtle. It requires a lot of one-on-one conversations with other stakeholders filled with passion and integrity to persuade. "having end-users that are better informed" is a fool's errand in a world where people have smart phones but struggle for clean water and avoid government oppression. The vast majority of end users are or would be just not that into us, even if they knew who we are and what we do. ALAC has not failed. It could however do better. Best regards, John Laprise, Ph.D. On Thu, Sep 14, 2023 at 9:14 AM Evan Leibovitch via At-Large < at-large@atlarge-lists.icann.org> wrote:

On Thu, Sep 14, 2023 at 2:45 AM Alejandro Pisanty via At-Large < at-large@atlarge-lists.icann.org> wrote:

...

if the At Large / ALAC's role is to inform - whom?

The constituency for which the ICANN bylaws enable us to speak -- Internet end users.

I read from your note that it should be informing the broader community

...

My premise is that since ALAC's power to actually effect change within ICANN is so weak, that it may find its resources better spent on having end-users that are better informed about the ICANN issues that affect them. ALAC has the unique opportunity to speak to end-users in their vernacular from their perspective (which may not be the same as that of ICANN corporate).

It has failed.

...

In order to fail you have to first try. That hasn't happened yet.

- Evan

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

Point taken, Evan. With the caveat that to inform the user community is a daunting task for which we do not have sufficient resources. One starting point would be to involve the consumer protection organisations worldwide, but we had little success so far. I remember in the early days of ALAC when I contacted many European consumer protection organisations, getting the same reply from all: “We have far more important things to do”. At that time I thought they were shortsighted, but several years later I have to recognise that they were - and they still probably are - right. Cheers, Roberto

On 13.09.2023, at 23:06, Evan Leibovitch via At-Large <at-large@atlarge-lists.icann.org> wrote:

Roberto Gaetano wrote:

I am just saying that At-Large is not the right place where to raise the issue asking for solutions.

We are fully agreed that this is not At-Large's task to fix. I *will*, however, advance that it is At-Large's task to inform. We have an important but sadly neglected role to play in public education.

There are many issues related to domain names about which people may ask but for which answers are either absent, partial or inaccurate. The most obvious of these is explaining the difference between .co and .com -- that is, how is a ccTLD operationally different from a gTLD. The differences can be non-trivial to both domain consumers and end-users, and are complicated by the way some ccTLDs are marketed by gTLDs. Over the years I have not found an end-user perspective to this issue, only those which inform domain investors.

"Why are there so many TLDs and why can't I access some of them?", today's topic, is clearly another worthy of some treatment. And maybe someone somewhere can explain the status of the .su TLD.

We all know that ALAC sits very low on the list of ICANN community parts actually capable of affecting significant change. We're an expense to ICANN rather than a source of revenue, and we lack the economic clout of domain buyers and sellers or the political clout of the GAC.

That's not going to change any time soon (how's progress on that second At-Large Board seat coming along?) but that's OK. There is still much that we can do to inform end-users (that is, those who wish to be informed) with answers to questions that nobody else seems to be answering, from a perspective unlike any other within ICANN. After all, if we're going to represent the interests of end-users, having them as informed as possible is helpful.

- Evan

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

Wondering how effective can ALAC ever be when the scope, interest and capacity is so varied and so wide. I remember my first meeting as a software engineer interested in the ICANN process running into a room of lawyers debating internet related policy. It was to say the least quite intimidating, and left me thinking about how I fit in given the environment. The disrespect from the other constituencies is one thing, but I would submit that some leveling of the playfield needs to be addressed within ALAC itself. I live in a region where the ICANN process and the understanding of the needs of the average user is still rarified air. If ALAC's role, as per Evan, is to inform, it also needs to effectively educate. I have no bright ideas (yet). but maybe some inward reflection is first required before anything else. My mere two cents. On Thu, Sep 14, 2023 at 10:59 AM Evan Leibovitch via At-Large < at-large@atlarge-lists.icann.org> wrote:

On Thu, Sep 14, 2023 at 7:19 AM Roberto Gaetano via At-Large < at-large@atlarge-lists.icann.org> wrote:

Point taken, Evan.

...

With the caveat that to inform the user community is a daunting task for which we do not have sufficient resources.

My premises on how to fix ALAC stem primarily from the "who the hell are you to challenge us?" challenge that would always arise when ALAC proposed policies or priorities that displease the domain industry. I recall being in closed-door meetings (I recall Alan and Olivier in there too) where that exact question was raised. So long as ALAC continues to exist in its political, self-selected form that challenge will always have validity. So long as what ALAC does aligns with ICANN's monied interests, all is well. But any time it dares stray from that path it will be successfully countered by attacking ALAC's credibility to speak on behalf of end users.

This credibility challenge can only be addressed by a radical rethink of ALAC, and changes that go far beyond those of the third-party reviews held to date. These changes keep in mind that the general public attitudes towards ICANN are close to those regarding other kinds of public infrastructure. In other words, most people just don't care until something breaks.

(Funny how other forms of public infrastructure such as sewage, electricity generation, air-travel coordination and roads don't see any calls to be improved through multi-stakeholder governance.)

I have detailed and specific ideas on how to get there from here, but that goes beyond this thread. Suffice it to say that they focus heavily on public education and public polling, rather than politics and outreach, as the means to establish authority.

One starting point would be to involve the consumer protection

...

organisations worldwide, but we had little success so far.

We've had our share of such advocates. Beau, Garth and Marc come to mind quickly. All were immensely frustrated by ALAC's combination of lack of authority and self-importance, and I am aware that other consumer organizations were informed by their experiences. Marc Rotenberg in particular lasted only a few months of his ALAC term because he quickly saw it as an utter waste of time. I had the opportunity to speak to him at length and was quite enlightened; his views on ALAC and ICANN inspire my present approach. And I maintain contact with Beau and Garth, who I consider friends, to this day.

- Evan

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

-- Lance Hinds Chief Technology Officer BrainStreet Group 287 'C' Albert St. Georgetown Guyana This message contains information that may be privileged and/or confidential and is the property of BrainStreet Technologies or BrainStreet Learning. The information contained herein is intended only for the individual or entity to whom it is addressed and others authorized to receive it . If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or take any action in reliance to the contents of this information or any part thereof and it may be unlawful to do so. If you receive this message in error, please notify the sender immediately and delete all copies of this message from your system. BrainStreet Technologies or BrainStreet Learning are neither liable for the proper and complete transmission of the information contained in this communication nor any delay in its receipt.

On 9/14/23 7:58 AM, Evan Leibovitch via At-Large wrote:

This credibility challenge can only be addressed by a radical rethink of ALAC, and changes that go far beyond those of the third-party reviews held to date. These changes keep in mind that the general public attitudes towards ICANN are close to those regarding other kinds of public infrastructure. In other words, most people just don't care until something breaks.

(Funny how other forms of public infrastructure such as sewage, electricity generation, air-travel coordination and roads don't see any calls to be improved through multi-stakeholder governance.) I'll try to refrain from a pre-ICANN formation, 25+ year old "I told us so".  ;-)

But perhaps I'll allude to a 14 year old one: See page 32-37 of the "Review of the At‐Large Advisory Committee - Final Report of the ALAC Review Working Group on ALAC Improvements" (I'll link to a copy on my website - I'm having trouble finding this rather expensive report on ICANN's own website. Perhaps my web search skills are taking the day off.) https://www.cavebear.com/docs/final-report-alac-review-28jan09-en.pdf And never bypassing a chance at self promotion, here's my general feeling about "stakeholder" models (summary: it's not a positive feeling.) Democracy Versus Stakeholderism https://www.cavebear.com/cavebear-blog/stakeholder_sock_puppet/         --karl--

Evan, to quickly extract a soundbite from your statement on sewage, water, and electricity, I love the idea! Municipal DNS is the way to go! Let's explore whether this brilliant, radical, new idea doesn't find hurdles in scalability, innovation, participation, and the fact that the object itself is still being built by many of the same who are its users.

Cherry picking and misquoting (under the guise of extracting soundbites) is always a nice, easy and lazy way to make one's point. Does your municipality generate its own electricity? How many do? - Evan

I quite agree with you that "legitimacy" is important and can be difficult to achieve. I had not thought of how ICANN's perceived authority is weakened as the world tends to de-globalize into competing fiefdoms.  I'm glad you brought that up.  (My sense is that you have revealed to us something that is going to be a growing issue in the coming years.) If we start to think of other jobs the Internet needs then there is value in looking at what ICANN got right and what it got wrong.  (Among those potential jobs are some that are quite touchy and sensitive, such as identification/authentication tokens, and some that will irritate those who think in terms of trade secrets, such as getting better handles on sources of damaging traffic.) I've usually thought that any body - whether it be ICANN or the Red Cross or whatever - achieves legitimacy as sort of an additive process performed both by national governments (usually by treaty or something similar) and by the body itself through doing its job well for a long time. ICANN has definitely done some things well for a quarter of a century - but often in the realm of taking credit for the work of root server operators.  ICANN's imposition of business models and its heavy cost burden on consumers (by my estimate this cost is in the $billions) is not something that has been done well.  (ICANN [perhaps under the guise of IANA] also did valuable, yeoman work, in conjunction with the IETF, with regard to multi-lingualization and DNSSEC.) Then there is the 25 year old fact that ICANN was designed (if not intentionally than naively) to be captured by those who it purports to regulate and has since become a pliable vehicle for the trademark branch of my tribe, Intellectual Property attorneys.  These things do not contribute to the weight of legitimacy as measured by others not so well situated, such as the community of Internet users. As anyone who knows me knows, I'm a strong believer that our institutions ought to have clear and reasonably direct lines of accountability to the living, breathing people who populate our planet.  Add to that that I reject the injection of bookkeeping conveniences (we call them "corporations") into those lines of accountability because they create means for multiplying of the influence of some, block the influence of others, and create opacity rather than transparency of the strings of accountability. As such I have believed that ICANN ought to be under the sole control of the public.  And, further, that a wise exercise of that public role ought to be to view those we call "stakeholders" entirely through the lens of the individual people who hold those interests and thus represent those interests merely as members of the public, rather than through some elevated, privileged, ordained role as "stakeholder".  (Of course, any wise member of the public ought to recognize that those we today call "stakeholders" often have expertise and views we ought to hear and consider.) I've held myself apart from the ALAC system.  Not because I reject its value.  But rather that I reject the Procrustean form that was forced upon it.  To my mind it was designed to be of weak voice with weaker influence. In balance, after 25 years, the name "ICANN" tends to elicit more groans than lauds.  That's not a path that leads to a solid, enduring foundation of legitimacy.         --karl-- On 9/14/23 2:59 PM, Evan Leibovitch wrote:

On Thu, Sep 14, 2023 at 3:54 PM Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> wrote:

Democracy Versus Stakeholderism

https://www.cavebear.com/cavebear-blog/stakeholder_sock_puppet/

There are many forms of stakeholderism. Some, like Netmundial's, have potential to be sustainable and adaptable for other environments. Other models, developed in standards-making environments, provide examples as diverse as the IETF's and ISO's.

And then there's ICANN's inmates-running-the-asylum model, by far worst of the bunch, in numerous ways explicitly designed to serve industry at the expense of the public interest. For all of its A&T noise the world has seen that ICANN's only real external accountability is to the California Attorney-General.

It is no coincidence that for most international treaties, the ICANN script is flipped; it is governments and public-interest groups who set the agenda while industry advises. Without the backing of such treaties, ICANN's decisions survive only because of governmental tolerance rather than validation.  And as a result of said lack of validation, we have issues arise such as we have in this thread: "ICANN-approved" gTLDs which are ignored by significant swaths of the Internet (and without anyone realizing it for YEARS).

How can anyone be surprised? It is notable that even this shocking news was revealed by an industry-insider website and has received no mainstream coverage of which I'm aware. Nobody outside the ICANN bubble cares.

And this is ICANN at peak respect. As globalization declines, ICANN's  lack of treaty backing is going to prove even more costly to international connectivity as time passes. It's going to get worse, not better.

- Evan

On Thu, Sep 14, 2023 at 11:26 PM Bill Jouris via At-Large < at-large@atlarge-lists.icann.org> wrote:

You have to admit, ICANN has been marvelously successful. As a trade association for the "contracted parties".

Fully admitted. ICANN pretends to the world that it's ICAO <https://www.icao.int> but actually functions like IATA <https://www.iata.org/>. It may, at some point in the future, be immortalized as a type case of

"regulatory capture."

As a case study in such capture ... there's nothing to wait for, it's already here. - Evan

As a company which provides email and other internet services maybe if the new gTLDs agreements included some serious commitment to avoid allowing the use of these gTLDs for massive spamming and phishing etc maybe the service providers would have been more enthusiastic about acceptance. Unfortunately the opposite is true and many of these new gTlDs can safely be blocked in entirety, they just spew spam etc, with no customer complaints. I'll guess these new gTLD registrars/registries would complain that's not equitable since it's not required of other TLDs. Which is all a very nice argument to make sitting in an airless room somewhere. So instead they tend to get blocked and ignored, or at least marked "suspicious" by spam filters, but equitably! If I had a nickel for every ISP who said or recommended "oh just block all .pick-a-nGTLD, you and your customers will be happier"... -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

In order to avoid reading the actual text (yes, I am lazy) what is the definition of "DNS security abuse"? 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". 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.     --karl-- On 9/15/23 10:58 AM, Carlton Samuels via At-Large wrote:

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 *_security_* abuse. #14 recommends amendments offering incentives - inclusive of financial ones - in the [RA/RAA] Agreements for the contracted parties adopting proactive anti-abuse measures. Nothing too heretical.

#15 recommends amendments to [RA/RAA] Agreements that establish thresholds of abuse at which compliance inquiries are automatically triggered and a higher one at which registrars and registries are presumed to be in default of their agreements.

We went on to recommend a community-developed DNS Abuse Dispute Resolution Policy (DADRP) if ICANN Compliance falls asleep on the enforcement job. [The text delicately eased into that like only ".../i//f the community determines that ICANN org itself is ill-suited or unable to enforce such provisions./"]

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.

Our ICANN don't play that!

Carlton ============================== /Carlton A Samuels/ /Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround/ =============================

On Thu, 14 Sept 2023 at 20:33, Barry Shein via At-Large <at-large@atlarge-lists.icann.org> wrote:

As a company which provides email and other internet services maybe if the new gTLDs agreements included some serious commitment to avoid allowing the use of these gTLDs for massive spamming and phishing etc maybe the service providers would have been more enthusiastic about acceptance.

Unfortunately the opposite is true and many of these new gTlDs can safely be blocked in entirety, they just spew spam etc, with no customer complaints.

I'll guess these new gTLD registrars/registries would complain that's not equitable since it's not required of other TLDs.

Which is all a very nice argument to make sitting in an airless room somewhere.

So instead they tend to get blocked and ignored, or at least marked "suspicious" by spam filters, but equitably!

If I had a nickel for every ISP who said or recommended "oh just block all .pick-a-nGTLD, you and your customers will be happier"...

--         -Barry Shein

Software Tool & Die    | bzs@TheWorld.com             | http://www.TheWorld.com <http://www.TheWorld.com> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD The World: Since 1989  | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site:http://atlarge.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.

All domain names are machine-generated.

On Sep 15, 2023, at 21:53, Barry Shein via At-Large <at-large@atlarge-lists.icann.org> wrote:

 How about selling tens of thousands (maybe hundreds of thousands) of machine-generated domains to spammers/phishers for a steeply discounted price?

...

On September 15, 2023 at 15:20 karl@cavebear.com (Karl Auerbach) wrote: In order to avoid reading the actual text (yes, I am lazy) what is the definition of "DNS security abuse"?

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".

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.

--karl--

On 9/15/23 10:58 AM, Carlton Samuels via At-Large wrote:

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 security abuse.

#14 recommends amendments offering incentives - inclusive of financial ones - in the [RA/RAA] Agreements for the contracted parties adopting proactive anti-abuse measures. Nothing too heretical.

#15 recommends amendments to [RA/RAA] Agreements that establish thresholds of abuse at which compliance inquiries are automatically triggered and a higher one at which registrars and registries are presumed to be in default of their agreements.

We went on to recommend a community-developed DNS Abuse Dispute Resolution Policy (DADRP) if ICANN Compliance falls asleep on the enforcement job. [The text delicately eased into that like only "...if the community determines that ICANN org itself is ill-suited or unable to enforce such provisions."]

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.

Our ICANN don't play that!

Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround =============================

On Thu, 14 Sept 2023 at 20:33, Barry Shein via At-Large < at-large@atlarge-lists.icann.org> wrote:

As a company which provides email and other internet services maybe if the new gTLDs agreements included some serious commitment to avoid allowing the use of these gTLDs for massive spamming and phishing etc maybe the service providers would have been more enthusiastic about acceptance.

Unfortunately the opposite is true and many of these new gTlDs can safely be blocked in entirety, they just spew spam etc, with no customer complaints.

I'll guess these new gTLD registrars/registries would complain that's not equitable since it's not required of other TLDs.

Which is all a very nice argument to make sitting in an airless room somewhere.

So instead they tend to get blocked and ignored, or at least marked "suspicious" by spam filters, but equitably!

If I had a nickel for every ISP who said or recommended "oh just block all .pick-a-nGTLD, you and your customers will be happier"...

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http:// www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

You would think that a group representing internet users would concentrate on what just about all users of anything concentrate on, which is price. And yet apart from Karl's contributions, it is not an issue that raises its head here at ALAC very much at all. Instead, complaints are about how much money registrars and registries make, which isn’t a user concern at all unless it affects pricing. In fact, unbelievably, there are complaints that domain names are too cheap, because people with ideas that are unsavory might take advantage. I have never in my life before seen a group that is supposed to care about the average user/consumer complain that prices are too high. P.S. Karl, ICANN’s scope also includes introducing and maintaining choice and competition in the marketplace. It’s a squishy remit, obviously, but it is there.

On Sep 16, 2023, at 12:25 PM, Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> wrote:

On 9/15/23 9:53 PM, bzs@theworld.com wrote:

...

How about selling tens of thousands (maybe hundreds of thousands) of machine-generated domains to spammers/phishers for a steeply discounted price?

I would not jump to agree that dealing with this is withing ICANN's scope - which is the matter of keeping the top two layers of the primary DNS system reliably, promptly, and accurately turning domain name queries into domain name responses. (A nod may be made in the direction of also including oversight of the addition and removal of TLDs.)

If generating domain names and selling them for what they actually cost (mere pennies rather than the ICANN system's dollars) is, in itself, something ill that ICANN should regulate against?

There are laws, passed by real legislatures, against fraud, misrepresentation, and conspiracies to do ill. Those things are the acts to be complained of, not the registration of lots of names that someone conjectures might be used in ill ways. It is no more ICANN's role to enforce laws about fraud than it is for ICANN to enforce laws about murder.

There is a vast distance between ICANN punishing a registrar or registry for, one one hand, merely selling lots of names for cheap and, on the other hand, a conspiracy, an agreement, between spammers and that registrar and registry. ICANN ought to leave the determination of such conspiracies to the legal systems of the world. Yes, there is a problem, not just ICANN's problem, of different jurisdictions arriving at contradictory results. But that is a problem much broader than ICANN.

Automobiles are used in many crimes. Would that justify the US Society of Automotive Engineers (a standards body) regulate Ford, GM, Honda, Toyota (etc) for producing and selling low cost cars?

Is ICANN to be the policeman - and perhaps the Puritan minister - of the Internet?

ICANN is a textbook case of mission creep (actually in ICANN's case it is mission gallop) and regulatory capture. Do we want to encourage and applaud this?

To me, the most interesting aspect of the practice of which you complain is that it demonstrates the utter fallacy of the ICANN imposed business model, a model that multiples un-audited costs by tens of thousands of percent so that internet users pay prices for domain names that are thousands of times higher than the actual cost of providing that service. ICANN is a money pump that sucks $$billions out of the pockets of internet users - and yet it gives those users no real voice or vote. That is the real scandal of which we ought to be complaining.

--karl--

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

Just my two cents: The amount of profit any company makes if in a competitive environment is not the business of any users, no matter the field the companies are working. As defending users interests our group shall focus on a) keeping a competitive environment. b) security in the product offered. c)enforcement against any kind of abuse. If we fight for those points keep working, any user interest will be preserved. Vanda From: At-Large <at-large-bounces@atlarge-lists.icann.org> on behalf of Antony Van Couvering via At-Large <at-large@atlarge-lists.icann.org> Date: Saturday, 16 September 2023 17:20 To: Antony Van Couvering <avc@avc.vc>, Karl Auerbach <karl@cavebear.com> Cc: At-Large Worldwide <at-large@atlarge-lists.icann.org> Subject: Re: [At-Large] DomainIncite : Is this why WhatsApp hates some TLDs but not others? Small correction: should be “complain that prices are too low.”

On Sep 16, 2023, at 13:04, Antony Van Couvering <avc@avc.vc> wrote:

You would think that a group representing internet users would concentrate on what just about all users of anything concentrate on, which is price. And yet apart from Karl's contributions, it is not an issue that raises its head here at ALAC very much at all.

Instead, complaints are about how much money registrars and registries make, which isn’t a user concern at all unless it affects pricing. In fact, unbelievably, there are complaints that domain names are too cheap, because people with ideas that are unsavory might take advantage. I have never in my life before seen a group that is supposed to care about the average user/consumer complain that prices are too high.

P.S. Karl, ICANN’s scope also includes introducing and maintaining choice and competition in the marketplace. It’s a squishy remit, obviously, but it is there.

...

On Sep 16, 2023, at 12:25 PM, Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> wrote:

...

On 9/15/23 9:53 PM, bzs@theworld.com wrote: How about selling tens of thousands (maybe hundreds of thousands) of machine-generated domains to spammers/phishers for a steeply discounted price?

I would not jump to agree that dealing with this is withing ICANN's scope - which is the matter of keeping the top two layers of the primary DNS system reliably, promptly, and accurately turning domain name queries into domain name responses. (A nod may be made in the direction of also including oversight of the addition and removal of TLDs.)

If generating domain names and selling them for what they actually cost (mere pennies rather than the ICANN system's dollars) is, in itself, something ill that ICANN should regulate against?

There are laws, passed by real legislatures, against fraud, misrepresentation, and conspiracies to do ill. Those things are the acts to be complained of, not the registration of lots of names that someone conjectures might be used in ill ways. It is no more ICANN's role to enforce laws about fraud than it is for ICANN to enforce laws about murder.

There is a vast distance between ICANN punishing a registrar or registry for, one one hand, merely selling lots of names for cheap and, on the other hand, a conspiracy, an agreement, between spammers and that registrar and registry. ICANN ought to leave the determination of such conspiracies to the legal systems of the world. Yes, there is a problem, not just ICANN's problem, of different jurisdictions arriving at contradictory results. But that is a problem much broader than ICANN.

Automobiles are used in many crimes. Would that justify the US Society of Automotive Engineers (a standards body) regulate Ford, GM, Honda, Toyota (etc) for producing and selling low cost cars?

Is ICANN to be the policeman - and perhaps the Puritan minister - of the Internet?

ICANN is a textbook case of mission creep (actually in ICANN's case it is mission gallop) and regulatory capture. Do we want to encourage and applaud this?

To me, the most interesting aspect of the practice of which you complain is that it demonstrates the utter fallacy of the ICANN imposed business model, a model that multiples un-audited costs by tens of thousands of percent so that internet users pay prices for domain names that are thousands of times higher than the actual cost of providing that service. ICANN is a money pump that sucks $$billions out of the pockets of internet users - and yet it gives those users no real voice or vote. That is the real scandal of which we ought to be complaining.

--karl--

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large At-Large Official Site: http://atlarge.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.

ICANN is if nothing else a network of contracts with various provisions. The general term of art used within the ICANN context for registries, registrars etc is the "contracted parties". ICANN has acted previously to curtail the mass use of throw-away domains by putting restrictions on refunds. In the past spammers et al were able to buy thousands of domains, use them for spamming, phishing, etc for several days, and then request a refund. So in that past case the cost was zero other than the effort involved. And certainly nothing to ICANN as the fees were refunded and the miscreant could lather, rinse, repeat. ICANN's mission statement includes the "stability and integrity" of the net. So for example they believe they can put requirements on identity of the purchaser. Imperfectly implemented but no one questions ICANN's ability to contractually require the registrar to attempt to gather accurate information at registration. And the notion of disallowing the use of their product (domains) for likely illegal or fraudulent purposes is hardly unique to ICANN. The automobile analogy falls flat with me since there are many restrictions on sales of automobiles such as proper identification of seller and buyer, etc. Try to buy a car without a VIN tag. There was even a time in the 1990s when you could buy ready to use cell phones in bubble packs for about $50 each, cash. They had some number of minutes included which one could refill, or just toss in a public trash can after harassing or threatening someone. Anyhow the point is that registrars can be contractually bound to not engage in behaviors known to be of advantage to micreants. On September 16, 2023 at 12:25 karl@cavebear.com (Karl Auerbach) wrote:

On 9/15/23 9:53 PM, bzs@theworld.com wrote:

...

How about selling tens of thousands (maybe hundreds of thousands) of machine-generated domains to spammers/phishers for a steeply discounted price?

I would not jump to agree that dealing with this is withing ICANN's scope - which is the matter of keeping the top two layers of the primary DNS system reliably, promptly, and accurately turning domain name queries into domain name responses.  (A nod may be made in the direction of also including oversight of the addition and removal of TLDs.)

If generating domain names and selling them for what they actually cost (mere pennies rather than the ICANN system's dollars) is, in itself, something ill that ICANN should regulate against?

There are laws, passed by real legislatures, against fraud, misrepresentation, and conspiracies to do ill.  Those things are the acts to be complained of, not the registration of lots of names that someone conjectures might be used in ill ways.  It is no more ICANN's role to enforce laws about fraud than it is for ICANN to enforce laws about murder.

There is a vast distance between ICANN punishing a registrar or registry for, one one hand, merely selling lots of names for cheap and, on the other hand, a conspiracy, an agreement, between spammers and that registrar and registry.  ICANN ought to leave the determination of such conspiracies to the legal systems of the world.  Yes, there is a problem, not just ICANN's problem, of different jurisdictions arriving at contradictory results.  But that is a problem much broader than ICANN.

Automobiles are used in many crimes.  Would that justify the US Society of Automotive Engineers (a standards body) regulate Ford, GM, Honda, Toyota (etc) for producing and selling low cost cars?

Is ICANN to be the policeman - and perhaps the Puritan minister - of the Internet?

ICANN is a textbook case of mission creep (actually in ICANN's case it is mission gallop) and regulatory capture.  Do we want to encourage and applaud this?

To me, the most interesting aspect of the practice of which you complain is that it demonstrates the utter fallacy of the ICANN imposed business model, a model that multiples un-audited costs by tens of thousands of percent so that internet users pay prices for domain names that are thousands of times higher than the actual cost of providing that service.   ICANN is a money pump that sucks $$billions out of the pockets of internet users - and yet it gives those users no real voice or vote.  That is the real scandal of which we ought to be complaining.

         --karl--

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On September 16, 2023 at 18:14 karl@cavebear.com (Karl Auerbach) wrote:

If a registry/registrar combination wants to make refunds after a few days, that's their business.  It's a stupid thing for them to allow without a "restocking charge", but that's their choice.

This is a settled matter from several years ago, you're lacking context. They were refunded the ICANN fee also which was one issue. The presumption was that the registrar was being slipped some amount of $$ (presumably less than the legitimate reg fees) to help the miscreant orchestrate this. So, register 100,000 domains which would be $18,000 in ICANN fees (18c/reg), slip the registrar $5,000 to help you refund them all a few days later when you're done with them, get your $18,000 back, lather, rinse, repeat every few days. I have no idea if $5K was a going rate, probably some registrars would do that for $5K/mo or less, not per turnaround. For the registrar it's fairly easily automated. And I'm not including speculation on what the registries' involvement might have been, perhaps none.

Sure, ICANN can be the policeman of the world.  But should it be?  And should it be when it effectively captured by those it would police and keeps those who are affected at arms length and powerless.

How many times were social media top execs pulled in front of Congress et al to answer about issues like privacy (e.g., sharing FB's data with Cambridge Analytics during the 2016 US elections), ad content whose source they couldn't seem to identify, and even content (the latter I'm less comfortable with but that doesn't negate the facts.) So we got the EU's GDPR, laws regarding onshoring of individuals' data, and so forth. Fundamentally ICANN performs a quasi-governmental service, unlike social media who at least can claim their servers, their rules (i.e., private, for-profit, etc.) That's the basis under which they are tax exempt (501c3), they claim to perform a service the govt (or govts but the US IRS doesn't care about that much) might otherwise have to figure out how to perform. See for example: https://www.icann.org/en/system/files/files/icann-irs-990-fy22-10may23-en.pd... in particular Schedule O beginning on page 67.

I have a rather long personal list of things I don't like:  I don't like churches that spew hate, I don't like those who would ban books, I don't like those who throw out science and spread disease to everyone else.  Sure, let's have ICANN regulate domain names that back those things.  And, let's be fair: let's add your list of ill-favored practices.

I never suggested anything of the sort nor would I. ICANN, like many other regulators, can focus on ways they (via their contracted parties) may be abetting criminal behavior directly, such as enabling criminals to hide their identities and/or thwart normal and ordinary security measures such as switching between tens of thousands of domains. Not the criminal behavior itself, but to extend your analogy about automobiles, in effect selling getaway cars without regard to obtaining the identity of the purchasers. Or many other common commercial situations where one might be aiding and abetting criminality even if by negligence.

Pretty soon we will have an Internet that makes Singapore and its restrictions (like chewing gum) look like a Libertarian paradise.

You're just making wild assumptions and running with them. If something seems to abet a pattern of criminality it might be worth investigating whether some regulation might curtail that.

I was mistaken when I said that ICANN would be a mere policeman - it would be far more, it would be complainant, policeman, judge, jury, and executioner all in one convenient place.

Ok, now you're shadow boxing, I don't know with whom.

On that model our power utilities could cut one off if we watched the wrong  shows or ate the wrong foods.

There's no limit.

That's why we have governments that are (in theory) bound by strict Constitutions and subject to in depth due process procedures.

ICANN is not a government, it has none of those protections.

Yet there are many among us who seem to want that and to want that in a way in which we - the community of internet users - end up paying vastly inflated prices.

There's little reason to believe that cost of goods sold (COGS) in general sets prices, other than it suggests a minimum price below which you would lose money. But the sale price tends to be set by what the market will bear. At any rate, for your statement to be true we would already have to be in your scenario.

    --karl--

On 9/16/23 5:37 PM, bzs@theworld.com wrote:

...

ICANN is if nothing else a network of contracts with various provisions.

The general term of art used within the ICANN context for registries, registrars etc is the "contracted parties".

ICANN has acted previously to curtail the mass use of throw-away domains by putting restrictions on refunds.

In the past spammers et al were able to buy thousands of domains, use them for spamming, phishing, etc for several days, and then request a refund.

So in that past case the cost was zero other than the effort involved. And certainly nothing to ICANN as the fees were refunded and the miscreant could lather, rinse, repeat.

ICANN's mission statement includes the "stability and integrity" of the net.

So for example they believe they can put requirements on identity of the purchaser. Imperfectly implemented but no one questions ICANN's ability to contractually require the registrar to attempt to gather accurate information at registration.

And the notion of disallowing the use of their product (domains) for likely illegal or fraudulent purposes is hardly unique to ICANN.

The automobile analogy falls flat with me since there are many restrictions on sales of automobiles such as proper identification of seller and buyer, etc. Try to buy a car without a VIN tag.

There was even a time in the 1990s when you could buy ready to use cell phones in bubble packs for about $50 each, cash. They had some number of minutes included which one could refill, or just toss in a public trash can after harassing or threatening someone.

Anyhow the point is that registrars can be contractually bound to not engage in behaviors known to be of advantage to micreants.

On September 16, 2023 at 12:25 karl@cavebear.com (Karl Auerbach) wrote:

...

On 9/15/23 9:53 PM, bzs@theworld.com wrote:

...

How about selling tens of thousands (maybe hundreds of thousands) of machine-generated domains to spammers/phishers for a steeply discounted price?

I would not jump to agree that dealing with this is withing ICANN's scope - which is the matter of keeping the top two layers of the primary DNS system reliably, promptly, and accurately turning domain name queries into domain name responses.  (A nod may be made in the direction of also including oversight of the addition and removal of TLDs.)

If generating domain names and selling them for what they actually cost (mere pennies rather than the ICANN system's dollars) is, in itself, something ill that ICANN should regulate against?

There are laws, passed by real legislatures, against fraud, misrepresentation, and conspiracies to do ill.  Those things are the acts to be complained of, not the registration of lots of names that someone conjectures might be used in ill ways.  It is no more ICANN's role to enforce laws about fraud than it is for ICANN to enforce laws about murder.

There is a vast distance between ICANN punishing a registrar or registry for, one one hand, merely selling lots of names for cheap and, on the other hand, a conspiracy, an agreement, between spammers and that registrar and registry.  ICANN ought to leave the determination of such conspiracies to the legal systems of the world.  Yes, there is a problem, not just ICANN's problem, of different jurisdictions arriving at contradictory results.  But that is a problem much broader than ICANN.

Automobiles are used in many crimes.  Would that justify the US Society of Automotive Engineers (a standards body) regulate Ford, GM, Honda, Toyota (etc) for producing and selling low cost cars?

Is ICANN to be the policeman - and perhaps the Puritan minister - of the Internet?

ICANN is a textbook case of mission creep (actually in ICANN's case it is mission gallop) and regulatory capture.  Do we want to encourage and applaud this?

To me, the most interesting aspect of the practice of which you complain is that it demonstrates the utter fallacy of the ICANN imposed business model, a model that multiples un-audited costs by tens of thousands of percent so that internet users pay prices for domain names that are thousands of times higher than the actual cost of providing that service.   ICANN is a money pump that sucks $$billions out of the pockets of internet users - and yet it gives those users no real voice or vote.  That is the real scandal of which we ought to be complaining.

         --karl--

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

Domain Tasting stopped domain names that would have naturally gone through the deletion process becoming available for reregistration. That created an artificial demand for new gTLDs and drove a lot of the enthusiasm for the new gTLD round of 2012.

John, While I agree with the rest of your excellent post, the idea that domain tasting was in any way responsible for the demand for new gTLDs is speculative at best and doesn’t at all accord with my own (extremely close) experience of the introduction of new gTLDs. If you are saying that consumers were frustrated with the (lack of) choice in the .com space, and that (therefore?) consumers were pushing for new gTLDs, I couldn’t agree less. Consumers at the time had no idea about new gTLDs; my bet, and those of other business people at the time, was that upon the introduction of new gTLDs, consumers would wake up to the idea of choice once it was presented to them. Consumers didn’t have much idea of choice outside of local ccTLDs before the new gTLDs were introduced, and so they couldn’t have driven demand for new gTLDs. Quite the contrary — we bet on consumers being interested in new gTLDs *despite* there being no direct evidence that they were. I often used the quote from Henry Ford — “If I asked my customers what they wanted, they’d all say they wanted a faster horse” — as an illustration of how we approached this possible new market. Domain tasting could not have created an artificial (or any) demand for new gTLDs, because no-one outside of ICANN even knew about new gTLDs prior to their introduction. The long fight to get them introduced was ignored by the press, including the tech press, and if you recall correctly, ICANN ran exactly one advertisement to promote them. As I said at the time: “One World, One Internet, One Ad.” Of those that did know about new gTLDs, many, including ALAC, worked to quash them. The only ones promoting them were the new registries, and we were having to spend all of our time and money trying to win over the supposed champions of choice and competition. So no, there was no consumer demand for new gTLDs prior to their introduction, whether artificial or otherwise, and certainly none created by domain tasting. Maybe you have evidence that shows I’m wrong; I’d love to see it. Antony

On Sep 17, 2023, at 11:34 AM, John McCormac via At-Large <at-large@atlarge-lists.icann.org> wrote:

On 17/09/2023 01:37, Barry Shein via At-Large wrote:

...

ICANN is if nothing else a network of contracts with various provisions. The general term of art used within the ICANN context for registries, registrars etc is the "contracted parties". ICANN has acted previously to curtail the mass use of throw-away domains by putting restrictions on refunds.

This was Domain Tasting in the 2000s where the five day Add Grace Period was exploited. The AGP was intended to allow registrars to deleted domain names without cost where bad payment details had been used or the domain name had been registered in error. Domain names were registered for less than the five day period, tested with PPC advertising and held if they made advertising revenue. Those that did not generate money from clicks were dropped. The process went on for a number of years and over 1,000,000,000 .COM domain names were registered and deleted.

Domain Tasting is quite different to the Bulk Registrations issue (2014 to present) in that Domain Tasting was driven by a small number of registrars. Bulk registrations are driven by a combination of registries, registrars and end-users.

ICANN eventually got around to dealing with the Domain Tasting problem when it had become so bad that more domain names were being registered and deleted each month than were active in the gTLD zones.

The problem was discussed and discussed in ICANN groups. There was even a report drafted. It was Google's decision not to monetise these AGP domain names and legal action by Dell against some of the registrars involved in Domain Tasting who were targeting trademarks and other Intellectual Property that changed things. ICANN brought in the "restocking fee" and the combination effectively destroyed large-scale registration patterns by 2009. ICANN hasn't done anything, as far as I know, about Bulk Registrations because it may be business issue for the registries rather than a regulatory issue.

...

So for example they believe they can put requirements on identity of the purchaser. Imperfectly implemented but no one questions ICANN's ability to contractually require the registrar to attempt to gather accurate information at registration. And the notion of disallowing the use of their product (domains) for likely illegal or fraudulent purposes is hardly unique to ICANN.

Domain Tasting stopped domain names that would have naturally gone through the deletion process becoming available for reregistration. That created an artificial demand for new gTLDs and drove a lot of the enthusiasm for the new gTLD round of 2012.

ICANN's introduction of the "restocking fee" had the unintended effect of channging the demand for new gTLDs. People could reregister deleting domain names (those that weren't shifted to sales and auction sites by the registrars) and outside the US, a lot of new registration activity shifted to the ccTLDs. ICANN expected tens of millions of new gTLD registrations for the first year of their operation. It didn't happen.

What did happen was Bulk Registrations as a mainstream business model when registries saw demand for their new gTLDs was not commercially viable for their continued existence as a registry.

Bulk Registrations are the heavily discounted registrations that flooded some of the new gTLDs. ICANN got its fee and some of the registries using bulk registrations to inflate their zones appeared, for a while, to be successful. Rather than the smooth growth curve of a healthy gTLD, the growth curve for gTLDs using heavy discounting as a business model took on a kind of sawtooth shape with the spikes of large numbers of discounted registrations being followed by a trough of deletions just over a year later.

These registrations were used for advertising, affiliated landing pages, phishing and search engine manipulation (backlinks from fake websites using scraped content etc). The economic model meant that it was cheaper to register a new domain name than pay the full renewal fee. The non-renewal rate for some of these gTLDs was over 95%. One of the largest of these new gTLDs peaked at over 2 million registrations and within five years, approximately 2,000 of those domain names were still in the zone. The rest were deleted.

The .INFO had used a similar approach to inflate its zone but that was a long time before the new gTLDs and it was different and there was no "restocking fee" back then.) When it comes to adding conditions to the registry and registrar contracts, the line between DNS Abuse (phishing, spam and malware) and Content Abuse (intellectual property and trademark infringement etc) is blurred.

...

Anyhow the point is that registrars can be contractually bound to not engage in behaviors known to be of advantage to micreants.

Would some of these new gTLDs be commercially viable if such a policy was part of the contract? No. Heavy discounting is a business model that has kept some of these registries in business. While 95% of some gTLD registrations may not renew on their first renewal, a small percentage will renew at full fee. If a registry continues this process, it builds up a core of domain names that will continue to renew at full fee.

There was a study by SIDN Labs (2017) that indicated that a lot of the bad activity in the legacy gTLDs had switched to these heavily discounted new gTLDs because the heavy discounting model had changed the economics of DNS Abuse.

ICANN's big problem is that it is a reactive, rather than pro-active, organisation. Worse still, it often relies on studies that do not accurately represent the market or its dynamics.

The domain name market is a continually changing one. The delivery date for some of these studies is often a year or so after the RFP. By then, the market has changed because the circumstances that applied to registrations made a year ago may have changed and this can affect renewals. To put this into some perspective, the first renewal rate for .COM hovers between 50% and 54%. That means that up to half of the new .COM registrations in 2022 will not renew. Some gTLDs are better and some are much worse.

Changing registry or registrar contracts involves a lot of discussion and takes years. The problem for ICANN, and the registries, with the link between heavily discounted registrations and DNS Abuse is that ICANN setting a minimum price for a registration or restricting the abilities of registries and registrars to engage in discounting would create a lot of legal problems for ICANN's almost hands-off approach with the operation of registries and gTLDs. ICANN is damned if it does and damned if it doesn't.

Regards...jmcc -- ********************************************************** John McCormac * e-mail: jmcc@hosterstats.com MC2 * web: http://www.hosterstats.com/ 22 Viewmount * Domain Registrations Statistics Waterford * Domnomics - the business of domain names Ireland * https://amzn.to/2OPtEIO IE * Skype: hosterstats.com **********************************************************

-- This email has been checked for viruses by Avast antivirus software. www.avast.com _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

Thanks for the concrete numbers.  As you mentioned, ICANN is often reactive.  My point is orthogonal - that the decision making in ICANN minimizes the public voice while elevating the voice of selected others and that as a result ICANN's policies tend to favor the latter and impose large costs upon the former. But I have some disagreement with one thing you said: On 9/17/23 11:34 AM, John McCormac via At-Large wrote:

... DNS Abuse (phishing, spam and malware) and Content Abuse (intellectual property and trademark infringement etc) ...

I consider these things (phishing, spam and malware) and Content Abuse (intellectual property and trademark infringement etc) to be ill practices that ought to be suppressed. However, I do not believe these should be classified as "DNS Abuse". Yes, DNS is involved.  But it is involved in the same way that a Toyota car might be involved in a bank robbery.  (I've often joked that the way to stop middle eastern terrorist groups is to stop the production of small Toyota pickups.) The point is to focus on the ill act itself, not the instrumentality. So rather than focusing on "DNS Abuse (phishing, spam and malware) and Content Abuse (intellectual property and trademark infringement etc)" we ought to focus on the harmful aspects - fraud, misrepresentation, violation of copyright or trademark - rather than on a gear tooth (DNS) in one kind of machinery though which these harmful acts are committed. (By-the-way, I am somewhat hypocritical in this as I do support constraints on firearms because they are so often instrumentalities used in crimes or personal injury torts.)         --karl--

On 9/17/23 2:51 PM, John McCormac wrote:

...

So rather than focusing on "DNS Abuse (phishing, spam and malware) and Content Abuse (intellectual property and trademark infringement etc)" we ought to focus on the harmful aspects - fraud, misrepresentation, violation of copyright or trademark - rather than on a gear tooth (DNS) in one kind of machinery though which these harmful acts are committed.

That might put ICANN, the registries, and the registrars in the position of being content regulators. I don't think that any of them want that.

I think we may have what in legal circles we call "a distinction without a difference". At the end of the day, whether we regulate an act via DNS or because of laws against fraud, the end result is regulation of content. Indeed, until we have widespread systems of remotely operated robotics, pretty much anything we act on on the internet is based on content. (The exceptions to that are things like response time metrics, which, to my mind, when they pertain to DNS are clearly within ICANN's remit.)         --karl--

Although I served as a member, I am not speaking for the CCT Review Team. So what was my thinking in supporting these recommendations? 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. 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. 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. 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. The CCT outlined a very modest framework proposal. Rejected. Let's see a better mousetrap then. Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Fri, 15 Sept 2023 at 17:20, Karl Auerbach <karl@cavebear.com> wrote:

In order to avoid reading the actual text (yes, I am lazy) what is the definition of "DNS security abuse"?

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".

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.

--karl-- On 9/15/23 10:58 AM, Carlton Samuels via At-Large wrote:

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 *security* abuse.

#14 recommends amendments offering incentives - inclusive of financial ones - in the [RA/RAA] Agreements for the contracted parties adopting proactive anti-abuse measures. Nothing too heretical.

#15 recommends amendments to [RA/RAA] Agreements that establish thresholds of abuse at which compliance inquiries are automatically triggered and a higher one at which registrars and registries are presumed to be in default of their agreements.

We went on to recommend a community-developed DNS Abuse Dispute Resolution Policy (DADRP) if ICANN Compliance falls asleep on the enforcement job. [The text delicately eased into that like only "...*i**f the community determines that ICANN org itself is ill-suited or unable to enforce such provisions.*"]

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.

Our ICANN don't play that!

Carlton ============================== *Carlton A Samuels*

*Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround* =============================

On Thu, 14 Sept 2023 at 20:33, Barry Shein via At-Large < at-large@atlarge-lists.icann.org> wrote:

...

As a company which provides email and other internet services maybe if the new gTLDs agreements included some serious commitment to avoid allowing the use of these gTLDs for massive spamming and phishing etc maybe the service providers would have been more enthusiastic about acceptance.

Unfortunately the opposite is true and many of these new gTlDs can safely be blocked in entirety, they just spew spam etc, with no customer complaints.

I'll guess these new gTLD registrars/registries would complain that's not equitable since it's not required of other TLDs.

Which is all a very nice argument to make sitting in an airless room somewhere.

So instead they tend to get blocked and ignored, or at least marked "suspicious" by spam filters, but equitably!

If I had a nickel for every ISP who said or recommended "oh just block all .pick-a-nGTLD, you and your customers will be happier"...

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

_______________________________________________ At-Large mailing listAt-Large@atlarge-lists.icann.orghttps://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

KYC requirements would be a reasonable start, as would reporting requirements for large sales of domains to a single customer. A pattern of behavior could also be discerned after the fact, it doesn't necessarily have to be presumptive. There are quite a few organizations which track for example phishing and spamming usually to generate blacklists. I've seen discussions where such behavior was tracked back to specific registrars. I'm not sure how trademarks came into this, I think you're talking about typosquatting and similar? That's certainly been a tactic for fraud such as obtaining redcros.org (missing 's') and putting up a site resembling Red Cross' soliciting donations. And a thousand other modi operandi. But there may be a nugget of a germ of an idea about the essence of the problem which is that ICANN has a monopoly on domains and their sale thus a monopoly on generating contracts and enforcing those contracts, or not. And doing so without plebiscite. So, as Blanche Dubois might say, we have always depended on the kindness of strangers. On September 18, 2023 at 12:03 karl@cavebear.com (Karl Auerbach) wrote:

Last night it struck me that some of these "DNS abuse" contractual "remedies" that have been proposed my prove to have a couple of Achilles Heels...

First there are the laws about anti-competitive agreements.  I am far from an expert in these, but my neurons begin to buzz when I read about ICANN agreements that effectively penalize sales of domain names simply on the basis of volume or price without any evidence that these specific sales are part of an agreement associated with unlawful acts (such as phishing.)

What concerns me is that these proposed contractual terms are not triggered by actual unlawful acts but by the fear, without evidence, that mass sales of domain names must somehow lead to unlawful acts.

There are ways to deal with this kind of thing that carry less risk of triggering complaints of anti-competitive actions by ICANN.  One would be a "know your customer" requirement, such as is imposed on financial institutions, for large transactions. Another is simply reporting large transactions so that an inquiry could be made whether something nefarious is actually going on.

Second there is the fact that ICANN's agreements are formed under the laws of California (and the US).  And under California law contractual remedies for breach (which, despite common belief, can be partial) must be tied to the actual amount of harm caused. In other words, punitive remedies, are generally not allowed or are restricted.

An ICANN contractual provision that punishes a registr* for selling large blocks of names, perhaps at a discount, could be considered punitive and unrelated to actual or reasonable (agreed-upon, "liquidated") harms.

These considerations reinforce my concern that ICANN rules that restrict sales or punish registr*s or users for merely imagined downstream unlawful uses of names may be rules that are themselves unlawful.

So, again, I express my sense that if ICANN desires to impose rules to restrict undesirable uses of domain names then those rules must be triggered by evidence of actual, concrete unlawful activities.

And, further, I sense that some of the downstream activities that some among us wish to restrict are not actually unlawful.  I am not aware of (but I could be wrong) that there is anything unlawful about buying up large numbers of domain names as part of a system of influencing web search engines' ranking algorithms.

I and my companies hold trademarks - I understand the urge to cry wolf whenever I see someone using something that gets close to my marks.  So I understand the desire for Intellectual Property protection attorneys (remember, I am part of that tribe) to seek to protected beyond the strict limits of our marks.  All of this is to say that it would be wise for ICANN to avoid putting into place contractual rules that get in the middle of often murky and often hard fought copyright or trademark disputes.

(I would also add that the purpose of trademark law is to protect the consumer - in other words, to protect you and me - and not to protect the vendor of goods and services.  Consequently it seems to me that within ICANN it is odd that the making of policy in these matters is largely in the hands of those vendors, with nary a seat at that policy-making table given to consumers - the community of Internet users.)

        --karl--

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

I would have to sit down and read the text and hear the arguments but they seem like reasonable proposals from your description. I suppose at this point it's not a good use of time. On September 15, 2023 at 12:58 carlton.samuels@gmail.com (Carlton Samuels) wrote:

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 security abuse.    #14 recommends amendments offering incentives - inclusive of financial ones - in the [RA/RAA] Agreements for the contracted parties adopting proactive anti-abuse measures. Nothing too heretical. 

#15 recommends amendments to [RA/RAA] Agreements that establish thresholds of abuse at which compliance inquiries are automatically triggered and a higher one at which registrars and registries are presumed to be in default of their agreements. 

We went on to recommend a community-developed DNS Abuse Dispute Resolution Policy (DADRP) if ICANN Compliance falls asleep on the enforcement job. [The text delicately eased into that like only "...if the community determines that ICANN org itself is ill-suited or unable to enforce such provisions."] 

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. 

Our ICANN don't play that!

Carlton    ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround =============================

On Thu, 14 Sept 2023 at 20:33, Barry Shein via At-Large < at-large@atlarge-lists.icann.org> wrote:

As a company which provides email and other internet services maybe if the new gTLDs agreements included some serious commitment to avoid allowing the use of these gTLDs for massive spamming and phishing etc maybe the service providers would have been more enthusiastic about acceptance.

Unfortunately the opposite is true and many of these new gTlDs can safely be blocked in entirety, they just spew spam etc, with no customer complaints.

I'll guess these new gTLD registrars/registries would complain that's not equitable since it's not required of other TLDs.

Which is all a very nice argument to make sitting in an airless room somewhere.

So instead they tend to get blocked and ignored, or at least marked "suspicious" by spam filters, but equitably!

If I had a nickel for every ISP who said or recommended "oh just block all .pick-a-nGTLD, you and your customers will be happier"...

--         -Barry Shein

Software Tool & Die    | bzs@TheWorld.com             | http:// www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD The World: Since 1989  | A Public Information Utility | *oo* _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large

At-Large Official Site: http://atlarge.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.

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*