You make good points. I have long accepted the concept of competing root systems and have suggested various ways in which they could co-exist without causing discomfort for users, particularly with regard to collisions between divergent versions of the same TLD string. (See my year 1999 note: https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#multiple_roots ) As you mention, we most definitely have some strong neo-root (as opposed to fully distinct competing root) systems, such as Google's 8.8.8.8, Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6 equivalents.)  Whether the query streams to these are being data mined is unknown to me. However, I doubt that in today's world of "shareholder value" that commercial companies, particularly those who strongly leverage their revenue streams from personal network usage data they gather, will long resist the temptation to monetize those query streams - indeed I would be surprised if some have not done so already.  One may ask, as I will do here: Why are these for-profit companies spending not-inconsequential amounts of money to deploy services that are redundant with the legacy root system?  We would be naive to think that these for-profit companies will long expend shareholder owned assets without expectation of some compensating business advantage or revenue stream. The legacy root server system has one characteristic that we too often overlook: It is run at an extremely high level of professionalism.  It is so high that there is usually no incentive to look to any other offering. And that professionalism has little to do with ICANN. For instance, remember the limitation (caused by the way that names are encoded into 512 byte UDP DNS packets) that places a limit of about 13 root name servers?  Remember the contention that that caused in the early days of ICANN because those 13 places were not equitably distributed around the world?  It was not ICANN that came up with the notion of anycast groups of name servers, rather it was the external community that created the idea and it was the root server operators who went forth and did the work to make it happen - they did not give ICANN notice of this, nor await ICANN permission, nor did they ask for ICANN funding - they just did it.  And as a result, the net is a better place. DNS technology is not the perfect answer to all questions - I've written about how DNS is insufficient to support the naming needs of net based distributed applications that move, split, and merge like blobs in a lava lamp.  E.g. My 2010 note "On Entity Associations In A Cloud Network" https://www.cavebear.com/archive/public/cloud-entities.pdf And I see some well intentioned efforts that are trying to push DNS for uses that it is not necessarily appropriate or in ways that could create unnecessary risks of code flaws that could lead to attacks or security vulnerabilities (this is especially true in the Internet-of-Things world where code is often weak and relies on use in a confined, non-stressful network environment.  For example, should the coming generation of TCP/IP based Engine Control Units [ECU] in a vehicle have to implement Punycode and UTF-8 or ought they take the safer path of simply rejecting any non-ASCII names?)         --karl-- On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:

I suspect it may well be too late (20 years too late!) to use the "reserve for posterity" approach for namespaces. A call to do this would no doubt be taken up at WIPO not ICANN anyway given the long standing issue with ICANN surrendering names as solely for business and governmental utility over its designed use for edge to edge resolution services. That would further push DNS away from the Internet edge and so itself be destabilising.

There's also a question whether the single root argument made by IAB in 2000 is still gospel in a world where e2e offers secure frameworks for attestations of an infinite variety of namespaces and identifiers than is even conceivable for the DNS infrastructure.

Particularly as DNS resolution is interpretative (punycode etc) today and largely anycast with geographical routing depending source and destination addressing which in turn depend on unofficial geo IP databases which are far from dependable given the growth in over and under private networks using their own choice of gateways into the "Internet". I am almost never in the place "The Internet" tells me I am in!

But I take your insider political perspective on the ICANN firmament. But it rather confirms my concern that ICANN has been far to comfortable with the DNS industry as a private club believing everybody has to go through the DNS that it "controls".

The reality is ICANN does not control the DNS just access to the root server resolution system. That is implemented as a tax and unsurprising if users think differently

C

Alejandro Pisanty via At-Large <at-large@atlarge-lists.icann.org> writes:

...

1. ( ) text/plain (*) text/html

Matthias,

thanks very much for this rich information. The summaries alone should be considered as strong alarm signs. The foci of attention of ALAC and At-Large seem way out of phase, lagging years behind these developments. This is not uniform; some RALOs are in even worse shape, considering recent publicly available evidence.

Alejandro Pisanty

On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via At-Large <at-large@atlarge-lists.icann.org> wrote:

Hi colleagues, the SSAC has published SAC123 and SAC122.

### SSAC Report on the Evolution of Internet Name Resolution (SAC123):

· Internet name resolution is evolving beyond just the global DNS to include alternative naming systems that are experimenting with different approaches for reasons like speed, privacy, censorship resistance, and governance.

· Many alternative systems adopt DNS name syntax to leverage existing software.

· Two concerning trends are increased ambiguity where the same name can resolve differently in different systems, and less visibility of names to end users even as names remain vital for security and trust.

· Maintaining integrity and coordination in the shared domain namespace is important.

· The report explores different perspectives on these trends from end users and developers.

· It identifies proposals to facilitate namespace coordination and recommends ICANN continue tracking these issues and provide regular updates to the community.

I highly recommend having a look at chapter: 7.1 End Users (some key aspects as follows):

· Domain names used to play an important role for end users in discovering web resources, but search engines have now replaced them as the primary method of discovery.

· End users today rarely directly interact with domain names due to the dominance of search engines and mobile devices. Features like browser "omnibars" also allow more free-form input.

· Other identifiers like QR codes and social media handles now also compete for users' attention rather than domain names.

· Domain names are becoming less visible in users' environments, yet they still provide an underlying ubiquitous resolution context relied upon by other technologies.

· Surveys found search engines are by far the predominant method for accessing websites, with domain name usage declining. QR code usage is increasing but still limited except in Asia.

· Decreased domain name visibility makes it easier for fraudsters to deceive users with lookalike names. Users are also generally unaware that some TLDs signal a different resolution context.

In summary, domain names are no longer the primary method end users employ to find and access Internet resources, decreasing their visibility and understandability while introducing security issues.

Link to the report: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...

### SSAC Report on Urgent Requests in gTLD Registration Data Policy (SAC122)

· Focus is on handling of Urgent Requests in proposed gTLD registration data policy

· Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation

· Proposed policy requires response to Urgent Requests in 24 hours generally

· SSAC contends proposed policy for Urgent Requests is not fit for purpose

· Definition and required response times are incompatible

· Questions if need and rationale for separate Urgent Request process is fully justified

· Existing ICANN policy and industry practices offer useful precedents

· Proposed extensions allow responses up to 7 days, not reflecting urgency

· Lack of concrete data on frequency and handling of such requests currently

· Risks reputation of ICANN multistakeholder model effectiveness

- Provides 3 recommendations

§ Add structure to ensure Urgent Requests handled expediently

§ Tighten response time requirements to be fit for purpose

§ Gather data on Urgent Requests for future policy making

Link to the report: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...

Have a nice evening!

Best,

M.

______________________________

Ing. Mag. Matthias M. Hudobnik

FIP • CIPP/E • CIPT • DPO • CIS LA

matthias@hudobnik.at

http://www.hudobnik.at

@mhudobnik

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

I am concerned about fragmentation of the net, but in ways that seem to be divergent than the concerns I usually hear. Many, probably most, of us Internet grey beards think of "the Internet" in terms of the end-to-end principal of IP (v4 or v6) packets moving without much hindrance from a source network interface with an global/public IP address to another network interface with its own global/public IP address. I think that world is dead. NATs put a nail into the end-to-end principle, but a nail that actually helped us expand the IPv4 net without too much damage (except to some old protocols, such as FTP, that carry IP addresses as data - most modern protocols are reasonably amenable to NATs and TCP-concatenating proxies.) But there is a different way of looking at The Internet that is not based on the old packet-based end-to-end principle.  That way is to look at The Internet as a collection of underlying internets (lower case) of various technologies and addressing that are connected together so that favored (there is much danger in that word "favored" - I'll get to that in a moment) applications work between users. This is really saying that we have turned the wheel once more in our long progression from "networks" (e.g. ARPAnet) to "network of networks" (Postel's "Internet") and now a "network of networks of networks" - a world in which "end-to-end" refers not to packets but to application inter-operation. (This idea is the underlying theme of my somewhat long blog item from 2016: "Internet: Quo Vadis (Where are you going?"  at https://www.cavebear.com/cavebear-blog/internet_quo_vadis/  That note envisioned an evolution - one that I believe is happening - in which the once unified Internet changes into a system of highly protected "islands" [such as a Google island, a Facebook island, a China island, various fundamentalist religious islands, etc] that are interconnected by guarded, taxed, filtered, and inspected bridges.  This is not unlike the walled cities of medieval Europe where the gates in the walls were used as much for taxation and excluding undesirables and foreigners as they were for defense in war.) I mentioned that there is danger - that danger is that these inter-island bridges will be open only to the most popular of applications.  To use a modern example, this future Internet-of-internets, might allow protocols such as Twitter or Facebook but might exclude new ideas such as Activity Pub (used by things like Mastodon.)  In other words, our notion of "innovation at the edge" will not necessary be valid across this global Internet-of-internets. I have concerns about this future that I see.  But those concerns are not necessarily fears as much as concessions to the reality that despite our protestations, we humans tend to form clumps - tribes, nations, corporations, religions - and we seem to like having the means to pull up the drawbridges, in full or in part, that connect us with others.  In addition, security concerns, intellectual property concerns, and the like are pushing in that direction - note recent legal developments around the world to impose content restrictions or require proof-of-age or proof-of-identity.  Or there may be content restrictions, for instance music that is still under copyright in the US may be in the public domain elsewhere. The early Internet grew out of the one-world ideas of the hippie culture of the late 1960s - I know, I was there.  But rather than tearing down borders, the Internet is drawing more boundaries and making the old ones more complicated.         --karl-- On 12/22/23 1:04 AM, Wolfgang Kleinwächter wrote:

Thanks Karl, not totally new, but very helpful in the new environment of the 2020s. Isn´t this a more serious threat to "Internet Fragmentation" than govermental efforts to introduce "national sovereignty" (on the application layer) into the borderless cyberspace? And "Happy Holidays"!! Wolfgang

...

Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> hat am 21.12.2023 20:31 CET geschrieben: You make good points. I have long accepted the concept of competing root systems and have suggested various ways in which they could co-exist without causing discomfort for users, particularly with regard to collisions between divergent versions of the same TLD string. (See my year 1999 note: https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#multiple_roots ) As you mention, we most definitely have some strong neo-root (as opposed to fully distinct competing root) systems, such as Google's 8.8.8.8, Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6 equivalents.)  Whether the query streams to these are being data mined is unknown to me. However, I doubt that in today's world of "shareholder value" that commercial companies, particularly those who strongly leverage their revenue streams from personal network usage data they gather, will long resist the temptation to monetize those query streams - indeed I would be surprised if some have not done so already.  One may ask, as I will do here: Why are these for-profit companies spending not-inconsequential amounts of money to deploy services that are redundant with the legacy root system?  We would be naive to think that these for-profit companies will long expend shareholder owned assets without expectation of some compensating business advantage or revenue stream. The legacy root server system has one characteristic that we too often overlook: It is run at an extremely high level of professionalism.  It is so high that there is usually no incentive to look to any other offering. And that professionalism has little to do with ICANN. For instance, remember the limitation (caused by the way that names are encoded into 512 byte UDP DNS packets) that places a limit of about 13 root name servers?  Remember the contention that that caused in the early days of ICANN because those 13 places were not equitably distributed around the world?  It was not ICANN that came up with the notion of anycast groups of name servers, rather it was the external community that created the idea and it was the root server operators who went forth and did the work to make it happen - they did not give ICANN notice of this, nor await ICANN permission, nor did they ask for ICANN funding - they just did it.  And as a result, the net is a better place. DNS technology is not the perfect answer to all questions - I've written about how DNS is insufficient to support the naming needs of net based distributed applications that move, split, and merge like blobs in a lava lamp.  E.g. My 2010 note "On Entity Associations In A Cloud Network" https://www.cavebear.com/archive/public/cloud-entities.pdf And I see some well intentioned efforts that are trying to push DNS for uses that it is not necessarily appropriate or in ways that could create unnecessary risks of code flaws that could lead to attacks or security vulnerabilities (this is especially true in the Internet-of-Things world where code is often weak and relies on use in a confined, non-stressful network environment.  For example, should the coming generation of TCP/IP based Engine Control Units [ECU] in a vehicle have to implement Punycode and UTF-8 or ought they take the safer path of simply rejecting any non-ASCII names?)         --karl-- On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:

...

I suspect it may well be too late (20 years too late!) to use the "reserve for posterity" approach for namespaces. A call to do this would no doubt be taken up at WIPO not ICANN anyway given the long standing issue with ICANN surrendering names as solely for business and governmental utility over its designed use for edge to edge resolution services. That would further push DNS away from the Internet edge and so itself be destabilising. There's also a question whether the single root argument made by IAB in 2000 is still gospel in a world where e2e offers secure frameworks for attestations of an infinite variety of namespaces and identifiers than is even conceivable for the DNS infrastructure. Particularly as DNS resolution is interpretative (punycode etc) today and largely anycast with geographical routing depending source and destination addressing which in turn depend on unofficial geo IP databases which are far from dependable given the growth in over and under private networks using their own choice of gateways into the "Internet". I am almost never in the place "The Internet" tells me I am in! But I take your insider political perspective on the ICANN firmament. But it rather confirms my concern that ICANN has been far to comfortable with the DNS industry as a private club believing everybody has to go through the DNS that it "controls". The reality is ICANN does not control the DNS just access to the root server resolution system. That is implemented as a tax and unsurprising if users think differently C Alejandro Pisanty via At-Large <at-large@atlarge-lists.icann.org> writes:

...

1. ( ) text/plain (*) text/html Matthias, thanks very much for this rich information. The summaries alone should be considered as strong alarm signs. The foci of attention of ALAC and At-Large seem way out of phase, lagging years behind these developments. This is not uniform; some RALOs are in even worse shape, considering recent publicly available evidence. Alejandro Pisanty On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via At-Large <at-large@atlarge-lists.icann.org> wrote: Hi colleagues, the SSAC has published SAC123 and SAC122. ### SSAC Report on the Evolution of Internet Name Resolution (SAC123): · Internet name resolution is evolving beyond just the global DNS to include alternative naming systems that are experimenting with different approaches for reasons like speed, privacy, censorship resistance, and governance. · Many alternative systems adopt DNS name syntax to leverage existing software. · Two concerning trends are increased ambiguity where the same name can resolve differently in different systems, and less visibility of names to end users even as names remain vital for security and trust. · Maintaining integrity and coordination in the shared domain namespace is important. · The report explores different perspectives on these trends from end users and developers. · It identifies proposals to facilitate namespace coordination and recommends ICANN continue tracking these issues and provide regular updates to the community. I highly recommend having a look at chapter: 7.1 End Users (some key aspects as follows): · Domain names used to play an important role for end users in discovering web resources, but search engines have now replaced them as the primary method of discovery. · End users today rarely directly interact with domain names due to the dominance of search engines and mobile devices. Features like browser "omnibars" also allow more free-form input. · Other identifiers like QR codes and social media handles now also compete for users' attention rather than domain names. · Domain names are becoming less visible in users' environments, yet they still provide an underlying ubiquitous resolution context relied upon by other technologies. · Surveys found search engines are by far the predominant method for accessing websites, with domain name usage declining. QR code usage is increasing but still limited except in Asia. · Decreased domain name visibility makes it easier for fraudsters to deceive users with lookalike names. Users are also generally unaware that some TLDs signal a different resolution context. In summary, domain names are no longer the primary method end users employ to find and access Internet resources, decreasing their visibility and understandability while introducing security issues. Link to the report: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...

### SSAC Report on Urgent Requests in gTLD Registration Data Policy (SAC122) · Focus is on handling of Urgent Requests in proposed gTLD registration data policy · Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation · Proposed policy requires response to Urgent Requests in 24 hours generally · SSAC contends proposed policy for Urgent Requests is not fit for purpose · Definition and required response times are incompatible · Questions if need and rationale for separate Urgent Request process is fully justified · Existing ICANN policy and industry practices offer useful precedents · Proposed extensions allow responses up to 7 days, not reflecting urgency · Lack of concrete data on frequency and handling of such requests currently · Risks reputation of ICANN multistakeholder model effectiveness - Provides 3 recommendations § Add structure to ensure Urgent Requests handled expediently § Tighten response time requirements to be fit for purpose § Gather data on Urgent Requests for future policy making Link to the report: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...

Have a nice evening! Best, M. ______________________________ Ing. Mag. Matthias M. Hudobnik FIP • CIPP/E • CIPT • DPO • CIS LA matthias@hudobnik.at http://www.hudobnik.at @mhudobnik _______________________________________________ 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.

On Mon, Dec 25, 2023 at 12:35 AM Barry Shein via At-Large < at-large@atlarge-lists.icann.org> wrote: I'd also point out that the global voice phone network, postal systems,

package delivery, various forms of travel, at least, also had a "one world" goal.

Sure, and we actually got there. To sort out standards and interoperability between the countries of the world, we used these archaic things called "treaties", managed by purpose-built intergovernmental organizations, that have to date worked out pretty well over the decades. We've had ITU for phones since 1865, UPU for mail since 1874, and ICAO for air travel since 1947. Treaties were messy to make and occasionally get abused but have worked out relatively well. Traditionally in these operations, governments and the public interest drive decision-making, while business interests serve in an advisory role, usually through industry associations. As a result, major decisions made by such bodies usually have force of law among treaty signatories. But the Internet world thought it knew better; it consciously and deliberately chose a different path. It bypassed the messiness of treaty-making and let industry make decisions while governments and the public interest were relegated to dispensable advisory roles. Generally this has worked, if only by accident and fortune. In the case of purely technical bodies such as IETF, W3C and ICANN's *SACs, decisions and standards have been generally accepted on technical merit; yet they still don't have the power of treaties behind them. Any sovereign jurisdiction can trivially choose to opt out, jeopardizing its own interoperability with the rest of the world but otherwise not breaking international law. Decisions involving politics, money or other non-technical factors have a tougher path. Institutions must make visible and ongoing efforts to sustain legitimacy, and these decisions often need to be promoted through marketing campaigns or other forms of collective begging. Two perfect example subjects of such begging are IPv6 and Internationalised Domain Names. And without force of treaty, dealing with obvious abuses (such as the continued presence of .su) have no means of enforcement. (IMO, ICANN actually did come close to "apocalyptic disaster" in 2020 -- whether it knew it or not at the time -- but was saved at the last minute by the California Attorney General) Every time ICANN or its pieces envision an existential threat, vested interests always hold up ITU as a boogeyman just waiting to consume ICANN were it to falter. At this time it would be difficult to demonstrate that an ITU-ran domain namespace would have botched as many public interest issues as ICANN has. Or maybe not the ITU, but another purpose-built treaty-based IGO.

And in the same period we began to understand the negative aspects of globalization like nuclear-tipped ICBMs and pollution (particularly the CO2 responsible for climate change) which also know no political boundaries tho don't require interoperability with their target other than the laws of physics.

Funny how even for those issues there are international treaties and conventions and IGOs. The Internet stands alone as being the one phenomenon of global public interest without treaties behind it (or even in the works). The UN tasked the IGF with coming up with a usable path forward, and it has failed pretty hard at that task. Maybe the WSIS follow-ups can start afresh, so the world can set some standards for the app- and island- and AI-centric future Internet that Karl described. And maybe this reboot could at last put the public interest at the forefront rather than an afterthought. Maybe, even, mention of the "T" word to ensure that Internet openness is maintained by law rather than whim. Happy holidays, -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56

Now those calls are free, and no travel necessary. Is that due to treaties? That cannot be said. They were not a good thing unless you were wealthy. The rest of us were sending mail on onion-skin paper to save on the postage. Is it because of the technology evolution or because the treaties were bad (well, they weren’t perfect) You can say the same about crossing a distance of 10 km before the technology of motor vehicles and now, nothing to do with treaties. De : At-Large <at-large-bounces@atlarge-lists.icann.org> au nom de Antony Van Couvering via At-Large <at-large@atlarge-lists.icann.org> Répondre à : Antony Van Couvering <avc@avc.vc> Date : lundi 25 décembre 2023 à 20:34 À : Evan Leibovitch <evanleibovitch@gmail.com> Cc : Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> Objet : Re: [At-Large] The SSAC has published SAC123 and SAC122 The premise is doubtful. Did all those treaties work out that well in fact? I remember taking a truck to a boat to a taxi to post office, then waiting for an hour to have a 10-minute phone call with my grandparents in a tiny booth, along with my brothers and sisters. That hit the family budget hard. We got to do that once a year, as a special treat, while in Kenya. Make no mistake, the rates were set by a coterie of state monopolists and large corporations who played that role in some countries. Now those calls are free, and no travel necessary. Is that due to treaties? That cannot be said. They were not a good thing unless you were wealthy. The rest of us were sending mail on onion-skin paper to save on the postage. On Dec 25, 2023, at 01:52, Evan Leibovitch via At-Large <at-large@atlarge-lists.icann.org> wrote:  On Mon, Dec 25, 2023 at 12:35 AM Barry Shein via At-Large <at-large@atlarge-lists.icann.org> wrote: I'd also point out that the global voice phone network, postal systems, package delivery, various forms of travel, at least, also had a "one world" goal. Sure, and we actually got there. To sort out standards and interoperability between the countries of the world, we used these archaic things called "treaties", managed by purpose-built intergovernmental organizations, that have to date worked out pretty well over the decades. We've had ITU for phones since 1865, UPU for mail since 1874, and ICAO for air travel since 1947. Treaties were messy to make and occasionally get abused but have worked out relatively well. Traditionally in these operations, governments and the public interest drive decision-making, while business interests serve in an advisory role, usually through industry associations. As a result, major decisions made by such bodies usually have force of law among treaty signatories. But the Internet world thought it knew better; it consciously and deliberately chose a different path. It bypassed the messiness of treaty-making and let industry make decisions while governments and the public interest were relegated to dispensable advisory roles. Generally this has worked, if only by accident and fortune. In the case of purely technical bodies such as IETF, W3C and ICANN's *SACs, decisions and standards have been generally accepted on technical merit; yet they still don't have the power of treaties behind them. Any sovereign jurisdiction can trivially choose to opt out, jeopardizing its own interoperability with the rest of the world but otherwise not breaking international law. Decisions involving politics, money or other non-technical factors have a tougher path. Institutions must make visible and ongoing efforts to sustain legitimacy, and these decisions often need to be promoted through marketing campaigns or other forms of collective begging. Two perfect example subjects of such begging are IPv6 and Internationalised Domain Names. And without force of treaty, dealing with obvious abuses (such as the continued presence of .su) have no means of enforcement. (IMO, ICANN actually did come close to "apocalyptic disaster" in 2020 -- whether it knew it or not at the time -- but was saved at the last minute by the California Attorney General) Every time ICANN or its pieces envision an existential threat, vested interests always hold up ITU as a boogeyman just waiting to consume ICANN were it to falter. At this time it would be difficult to demonstrate that an ITU-ran domain namespace would have botched as many public interest issues as ICANN has. Or maybe not the ITU, but another purpose-built treaty-based IGO. And in the same period we began to understand the negative aspects of globalization like nuclear-tipped ICBMs and pollution (particularly the CO2 responsible for climate change) which also know no political boundaries tho don't require interoperability with their target other than the laws of physics. Funny how even for those issues there are international treaties and conventions and IGOs. The Internet stands alone as being the one phenomenon of global public interest without treaties behind it (or even in the works). The UN tasked the IGF with coming up with a usable path forward, and it has failed pretty hard at that task. Maybe the WSIS follow-ups can start afresh, so the world can set some standards for the app- and island- and AI-centric future Internet that Karl described. And maybe this reboot could at last put the public interest at the forefront rather than an afterthought. Maybe, even, mention of the "T" word to ensure that Internet openness is maintained by law rather than whim. Happy holidays, -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 _______________________________________________ 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.

FWIW, I have been an avid reader of Karl's various pieces time out memory. They still make sense. Quite apart from a global standard, there is one major influence enabling interoperability across all those surfaces mentioned here. Treaties...and the obligations thereto! I have come to know two from making a living in a day job. To post a letter or parcel from here to there, the UPU Global Postal Model imposes a rule for various pieces of information - CN 23 data, inclusive of personally-identifying info - must be shared electronically between the origin postal authority, the destination postal authority, the carrier and destination customs. The letter or parcel must await a 'consent to send' (positive acknowledgement!) advised by the destination postal authority to both the origin postal authority and shipper. The ICAO protocols surrounding movement of Passenger Name Records (PNR) have a similar framework. CAS ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Mon, 25 Dec 2023 at 00:35, Barry Shein via At-Large < at-large@atlarge-lists.icann.org> wrote:

I agree with what you're saying but I'd also point out that the global voice phone network, postal systems, package delivery, various forms of travel, at least, also had a "one world" goal.

I can pretty much make a phone call, mail a letter, deliver a package, to almost anyone one the planet or perhaps with some effort travel most anywhere. With perhaps the exception of some extremely poor or draconian authoritative places.

And in the same period we began to understand the negative aspects of globalization like nuclear-tipped ICBMs and pollution (particularly the CO2 responsible for climate change) which also know no political boundaries tho don't require interoperability with their target other than the laws of physics.

So the model was fomenting w/o some "hippie" notion, it was just (mostly) post-WW2 globalization.

Perhaps a minor point but it raises the question as to whether this overall trend is part of some grand plan or is it just an organic process like the spread of language, music, religion, etc. which may hit some bumps in the road but is likely to keep rolling along barring some apocalyptic disaster.

On December 22, 2023 at 15:45 at-large@atlarge-lists.icann.org (Karl Auerbach via At-Large) wrote:

...

I am concerned about fragmentation of the net, but in ways that seem to be divergent than the concerns I usually hear.

Many, probably most, of us Internet grey beards think of "the Internet" in terms of the end-to-end principal of IP (v4 or v6) packets moving without much hindrance from a source network interface with an global/public IP address to another network interface with its own global/public IP address.

I think that world is dead.

NATs put a nail into the end-to-end principle, but a nail that actually helped us expand the IPv4 net without too much damage (except to some old protocols, such as FTP, that carry IP addresses as data - most modern protocols are reasonably amenable to NATs and TCP-concatenating proxies.)

But there is a different way of looking at The Internet that is not based on the old packet-based end-to-end principle. That way is to look at The Internet as a collection of underlying internets (lower case) of various technologies and addressing that are connected together so that favored (there is much danger in that word "favored" - I'll get to that in a moment) applications work between users.

This is really saying that we have turned the wheel once more in our long progression from "networks" (e.g. ARPAnet) to "network of networks" (Postel's "Internet") and now a "network of networks of networks" - a world in which "end-to-end" refers not to packets but to application inter-operation.

(This idea is the underlying theme of my somewhat long blog item from 2016: "Internet: Quo Vadis (Where are you going?" at https://www.cavebear.com/ cavebear-blog/internet_quo_vadis/ That note envisioned an evolution - one that I believe is happening - in which the once unified Internet changes into a system of highly protected "islands" [such as a Google island, a Facebook island, a China island, various fundamentalist religious islands, etc] that are interconnected by guarded, taxed, filtered, and inspected bridges. This is not unlike the walled cities of medieval Europe where the gates in the walls were used as much for taxation and excluding undesirables and foreigners as they were for defense in war.)

I mentioned that there is danger - that danger is that these inter-island bridges will be open only to the most popular of applications. To use a modern example, this future Internet-of-internets, might allow protocols such as Twitter or Facebook but might exclude new ideas such as Activity Pub (used by things like Mastodon.) In other words, our notion of "innovation at the edge" will not necessary be valid across this global Internet-of-internets.

I have concerns about this future that I see. But those concerns are not necessarily fears as much as concessions to the reality that despite our protestations, we humans tend to form clumps - tribes, nations, corporations, religions - and we seem to like having the means to pull up the drawbridges, in full or in part, that connect us with others. In addition, security concerns, intellectual property concerns, and the like are pushing in that direction - note recent legal developments around the world to impose content restrictions or require proof-of-age or proof-of-identity. Or there may be content restrictions, for instance music that is still under copyright in the US may be in the public domain elsewhere.

The early Internet grew out of the one-world ideas of the hippie culture of the late 1960s - I know, I was there. But rather than tearing down borders, the Internet is drawing more boundaries and making the old ones more complicated.

--karl--

On 12/22/23 1:04 AM, Wolfgang Kleinwächter wrote:

Thanks Karl,

not totally new, but very helpful in the new environment of the 2020s.

Isn´t this a more serious threat to "Internet Fragmentation" than govermental efforts to introduce "national sovereignty" (on the application layer) into the borderless cyberspace?

And "Happy Holidays"!!

Wolfgang

Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> hat am 21.12.2023 20:31 CET geschrieben:

You make good points.

I have long accepted the concept of competing root systems and have suggested various ways in which they could co-exist without causing discomfort for users, particularly with regard to collisions between divergent versions of the same TLD string. (See my year 1999 note: https://www.cavebear.com/archive/cavebear/growl/issue_2.htm# multiple_roots )

As you mention, we most definitely have some strong neo-root (as opposed to fully distinct competing root) systems, such as Google's 8.8.8.8, Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6 equivalents.) Whether the query streams to these are being data mined is unknown to me. However, I doubt that in today's world of "shareholder value" that commercial companies, particularly those who strongly leverage their revenue streams from personal network usage data they gather, will long resist the temptation to monetize those query streams - indeed I would be surprised if some have not done so already. One may ask, as I will do here: Why are these for-profit companies spending not-inconsequential amounts of money to deploy services that are redundant with the legacy root system? We would be naive to think that these for-profit companies will long expend shareholder owned assets without expectation of some compensating business advantage or revenue stream.

The legacy root server system has one characteristic that we too often overlook: It is run at an extremely high level of professionalism. It is so high that there is usually no incentive to look to any other offering.

And that professionalism has little to do with ICANN.

For instance, remember the limitation (caused by the way that names are encoded into 512 byte UDP DNS packets) that places a limit of about 13 root name servers? Remember the contention that that caused in the early days of ICANN because those 13 places were not equitably distributed around the world? It was not ICANN that came up with the notion of anycast groups of name servers, rather it was the external community that created the idea and it was the root server operators who went forth and did the work to make it happen - they did not give ICANN notice of this, nor await ICANN permission, nor did they ask for ICANN funding - they just did it. And as a result, the net is a better place.

DNS technology is not the perfect answer to all questions - I've written about how DNS is insufficient to support the naming needs of net based distributed applications that move, split, and merge like blobs in a lava lamp. E.g. My 2010 note "On Entity Associations In A Cloud Network" https://www.cavebear.com/archive/public/cloud-entities.pdf

And I see some well intentioned efforts that are trying to push DNS for uses that it is not necessarily appropriate or in ways that could create unnecessary risks of code flaws that could lead to attacks or security vulnerabilities (this is especially true in the Internet-of-Things world where code is often weak and relies on use in a confined, non-stressful network environment. For example, should the coming generation of TCP/IP based Engine Control Units [ECU] in a vehicle have to implement Punycode and UTF-8 or ought they take the safer path of simply rejecting any non-ASCII names?)

--karl--

On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:

I suspect it may well be too late (20 years too late!) to use the "reserve for posterity" approach for namespaces. A call to do this would no doubt be taken up at WIPO not ICANN anyway given the long standing issue with ICANN surrendering names as solely for business and governmental utility over its designed use for edge to edge resolution services. That would further push DNS away from the Internet edge and so itself be destabilising.

There's also a question whether the single root argument made by IAB in 2000 is still gospel in a world where e2e offers secure frameworks for attestations of an infinite variety of namespaces and identifiers than is even conceivable for the DNS infrastructure.

Particularly as DNS resolution is interpretative (punycode etc) today and largely anycast with geographical routing depending source and destination addressing which in turn depend on unofficial geo IP databases which are far from dependable given the growth in over and under private networks using their own choice of gateways into the "Internet". I am almost never in the place "The Internet" tells me I am in!

But I take your insider political perspective on the ICANN firmament. But it rather confirms my concern that ICANN has been far to comfortable with the DNS industry as a private club believing everybody has to go through the DNS that it "controls".

The reality is ICANN does not control the DNS just access to the root server resolution system. That is implemented as a tax and unsurprising if users think differently

C

Alejandro Pisanty via At-Large < at-large@atlarge-lists.icann.org> writes:

1. ( ) text/plain (*) text/html

Matthias,

thanks very much for this rich information. The summaries alone should be considered as strong alarm signs. The foci of attention of ALAC and At-Large seem way out of phase, lagging years behind these developments. This is not uniform; some RALOs are in even worse shape, considering recent publicly available evidence.

Alejandro Pisanty

On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via At-Large <at-large@atlarge-lists.icann.org> wrote:

Hi colleagues, the SSAC has published SAC123 and SAC122.

### SSAC Report on the Evolution of Internet Name Resolution (SAC123):

· Internet name resolution is evolving beyond just the global DNS to include alternative naming systems that are experimenting with different approaches for reasons like speed, privacy, censorship resistance, and governance.

· Many alternative systems adopt DNS name syntax to leverage existing software.

· Two concerning trends are increased ambiguity where the same name can resolve differently in different systems, and less visibility of names to end users even as names remain vital for security and trust.

· Maintaining integrity and coordination in the shared domain namespace is important.

· The report explores different perspectives on these trends from end users and developers.

· It identifies proposals to facilitate namespace coordination and recommends ICANN continue tracking these issues and provide regular updates to the community.

I highly recommend having a look at chapter: 7.1 End Users (some key aspects as follows):

· Domain names used to play an important role for end users in discovering web resources, but search engines have now replaced them as the primary method of discovery.

· End users today rarely directly interact with domain names due to the dominance of search engines and mobile devices. Features like browser "omnibars" also allow more free-form input.

· Other identifiers like QR codes and social media handles now also compete for users' attention rather than domain names.

· Domain names are becoming less visible in users' environments, yet they still provide an underlying ubiquitous resolution context relied upon by other technologies.

· Surveys found search engines are by far the predominant method for accessing websites, with domain name usage declining. QR code usage is increasing but still limited except in Asia.

· Decreased domain name visibility makes it easier for fraudsters to deceive users with lookalike names. Users are also generally unaware that some TLDs signal a different resolution context.

In summary, domain names are no longer the primary method end users employ to find and access Internet resources, decreasing their visibility and understandability while introducing security issues.

Link to the report: https://itp.cdn.icann.org/en/files/ security-and-stability-advisory-committee-ssac-reports/ sac-123-15-12-2023-en.pdf

### SSAC Report on Urgent Requests in gTLD Registration Data Policy (SAC122)

· Focus is on handling of Urgent Requests in proposed gTLD registration data policy

· Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation

· Proposed policy requires response to Urgent Requests in 24 hours generally

· SSAC contends proposed policy for Urgent Requests is not fit for purpose

· Definition and required response times are incompatible

· Questions if need and rationale for separate Urgent Request process is fully justified

· Existing ICANN policy and industry practices offer useful precedents

· Proposed extensions allow responses up to 7 days, not reflecting urgency

· Lack of concrete data on frequency and handling of such requests currently

· Risks reputation of ICANN multistakeholder model effectiveness

- Provides 3 recommendations

§ Add structure to ensure Urgent Requests handled expediently

§ Tighten response time requirements to be fit for purpose

§ Gather data on Urgent Requests for future policy making

Link to the report: https://itp.cdn.icann.org/en/files/ security-and-stability-advisory-committee-ssac-reports/ sac-122-12-12-2023-en.pdf

Have a nice evening!

Best,

M.

______________________________

Ing. Mag. Matthias M. Hudobnik

FIP • CIPP/E • CIPT • DPO • CIS LA

matthias@hudobnik.at

http://www.hudobnik.at

@mhudobnik

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

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