<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
Thanks Karl,
</div>
<div class="default-style">
</div>
<div class="default-style">
not totally new, but very helpful in the new environment of the 2020s.
</div>
<div class="default-style">
</div>
<div class="default-style">
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?
</div>
<div class="default-style">
</div>
<div class="default-style">
And "Happy Holidays"!!
</div>
<div class="default-style">
</div>
<div class="default-style">
Wolfgang
</div>
<div class="default-style">
</div>
<div class="default-style">
</div>
<blockquote type="cite">
<div>
Karl Auerbach via At-Large <<a href="mailto:at-large@atlarge-lists.icann.org">at-large@atlarge-lists.icann.org</a>> hat am 21.12.2023 20:31 CET geschrieben:
</div>
<div>
</div>
<div>
</div>
<div>
You make good points.
</div>
<div>
</div>
<div>
I have long accepted the concept of competing root systems and have
</div>
<div>
suggested various ways in which they could co-exist without causing
</div>
<div>
discomfort for users, particularly with regard to collisions between
</div>
<div>
divergent versions of the same TLD string. (See my year 1999 note:
</div>
<div>
<a href="https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#multiple_roots" target="_blank" rel="noopener">https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#multiple_roots</a> )
</div>
<div>
</div>
<div>
As you mention, we most definitely have some strong neo-root (as opposed
</div>
<div>
to fully distinct competing root) systems, such as Google's 8.8.8.8,
</div>
<div>
Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6
</div>
<div>
equivalents.) Whether the query streams to these are being data mined
</div>
<div>
is unknown to me. However, I doubt that in today's world of "shareholder
</div>
<div>
value" that commercial companies, particularly those who strongly
</div>
<div>
leverage their revenue streams from personal network usage data they
</div>
<div>
gather, will long resist the temptation to monetize those query streams
</div>
<div>
- indeed I would be surprised if some have not done so already. One may
</div>
<div>
ask, as I will do here: Why are these for-profit companies spending
</div>
<div>
not-inconsequential amounts of money to deploy services that are
</div>
<div>
redundant with the legacy root system? We would be naive to think that
</div>
<div>
these for-profit companies will long expend shareholder owned assets
</div>
<div>
without expectation of some compensating business advantage or revenue
</div>
<div>
stream.
</div>
<div>
</div>
<div>
The legacy root server system has one characteristic that we too often
</div>
<div>
overlook: It is run at an extremely high level of professionalism. It
</div>
<div>
is so high that there is usually no incentive to look to any other offering.
</div>
<div>
</div>
<div>
And that professionalism has little to do with ICANN.
</div>
<div>
</div>
<div>
For instance, remember the limitation (caused by the way that names are
</div>
<div>
encoded into 512 byte UDP DNS packets) that places a limit of about 13
</div>
<div>
root name servers? Remember the contention that that caused in the
</div>
<div>
early days of ICANN because those 13 places were not equitably
</div>
<div>
distributed around the world? It was not ICANN that came up with the
</div>
<div>
notion of anycast groups of name servers, rather it was the external
</div>
<div>
community that created the idea and it was the root server operators who
</div>
<div>
went forth and did the work to make it happen - they did not give ICANN
</div>
<div>
notice of this, nor await ICANN permission, nor did they ask for ICANN
</div>
<div>
funding - they just did it. And as a result, the net is a better place.
</div>
<div>
</div>
<div>
DNS technology is not the perfect answer to all questions - I've written
</div>
<div>
about how DNS is insufficient to support the naming needs of net based
</div>
<div>
distributed applications that move, split, and merge like blobs in a
</div>
<div>
lava lamp. E.g. My 2010 note "On Entity Associations In A Cloud
</div>
<div>
Network" <a href="https://www.cavebear.com/archive/public/cloud-entities.pdf" target="_blank" rel="noopener">https://www.cavebear.com/archive/public/cloud-entities.pdf</a>
</div>
<div>
</div>
<div>
And I see some well intentioned efforts that are trying to push DNS for
</div>
<div>
uses that it is not necessarily appropriate or in ways that could create
</div>
<div>
unnecessary risks of code flaws that could lead to attacks or security
</div>
<div>
vulnerabilities (this is especially true in the Internet-of-Things world
</div>
<div>
where code is often weak and relies on use in a confined, non-stressful
</div>
<div>
network environment. For example, should the coming generation of
</div>
<div>
TCP/IP based Engine Control Units [ECU] in a vehicle have to implement
</div>
<div>
Punycode and UTF-8 or ought they take the safer path of simply rejecting
</div>
<div>
any non-ASCII names?)
</div>
<div>
</div>
<div>
--karl--
</div>
<div>
</div>
<div>
On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:
</div>
<blockquote type="cite">
<div>
I suspect it may well be too late (20 years too late!) to use the
</div>
<div>
"reserve for posterity" approach for namespaces. A call to do this would
</div>
<div>
no doubt be taken up at WIPO not ICANN anyway given the long standing
</div>
<div>
issue with ICANN surrendering names as solely for business and
</div>
<div>
governmental utility over its designed use for edge to edge resolution
</div>
<div>
services. That would further push DNS away from the Internet edge and so
</div>
<div>
itself be destabilising.
</div>
<div>
</div>
<div>
There's also a question whether the single root argument made by IAB
</div>
<div>
in 2000 is still gospel in a world where e2e offers secure
</div>
<div>
frameworks for attestations of an infinite variety of namespaces and
</div>
<div>
identifiers than is even conceivable for the DNS infrastructure.
</div>
<div>
</div>
<div>
Particularly as DNS resolution is interpretative (punycode etc) today
</div>
<div>
and largely anycast with geographical routing depending source and
</div>
<div>
destination addressing which in turn depend on unofficial geo IP
</div>
<div>
databases which are far from dependable given the growth in over and
</div>
<div>
under private networks using their own choice of gateways into the
</div>
<div>
"Internet". I am almost never in the place "The Internet" tells me I am
</div>
<div>
in!
</div>
<div>
</div>
<div>
But I take your insider political perspective on the ICANN
</div>
<div>
firmament. But it rather confirms my concern that ICANN has been far to
</div>
<div>
comfortable with the DNS industry as a private club believing everybody
</div>
<div>
has to go through the DNS that it "controls".
</div>
<div>
</div>
<div>
The reality is ICANN does not control the DNS just access to the root
</div>
<div>
server resolution system. That is implemented as a tax and unsurprising
</div>
<div>
if users think differently
</div>
<div>
</div>
<div>
C
</div>
<div>
</div>
<div>
</div>
<div>
Alejandro Pisanty via At-Large <<a href="mailto:at-large@atlarge-lists.icann.org">at-large@atlarge-lists.icann.org</a>> writes:
</div>
<div>
</div>
<blockquote type="cite">
<div>
1. ( ) text/plain (*) text/html
</div>
<div>
</div>
<div>
Matthias,
</div>
<div>
</div>
<div>
thanks very much for this rich information. The summaries alone should be considered as strong alarm signs. The
</div>
<div>
foci of attention of ALAC and At-Large seem way out of phase, lagging years behind these developments. This is
</div>
<div>
not uniform; some RALOs are in even worse shape, considering recent publicly available evidence.
</div>
<div>
</div>
<div>
Alejandro Pisanty
</div>
<div>
</div>
<div>
On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via At-Large <<a href="mailto:at-large@atlarge-lists.icann.org">at-large@atlarge-lists.icann.org</a>> wrote:
</div>
<div>
</div>
<div>
Hi colleagues, the SSAC has published SAC123 and SAC122.
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
### SSAC Report on the Evolution of Internet Name Resolution (SAC123):
</div>
<div>
</div>
<div>
· Internet name resolution is evolving beyond just the global DNS to include alternative naming systems
</div>
<div>
that are experimenting with different approaches for reasons like speed, privacy, censorship resistance, and
</div>
<div>
governance.
</div>
<div>
</div>
<div>
· Many alternative systems adopt DNS name syntax to leverage existing software.
</div>
<div>
</div>
<div>
· Two concerning trends are increased ambiguity where the same name can resolve differently in
</div>
<div>
different systems, and less visibility of names to end users even as names remain vital for security and trust.
</div>
<div>
</div>
<div>
· Maintaining integrity and coordination in the shared domain namespace is important.
</div>
<div>
</div>
<div>
· The report explores different perspectives on these trends from end users and developers.
</div>
<div>
</div>
<div>
· It identifies proposals to facilitate namespace coordination and recommends ICANN continue tracking
</div>
<div>
these issues and provide regular updates to the community.
</div>
<div>
</div>
<div>
I highly recommend having a look at chapter: 7.1 End Users (some key aspects as follows):
</div>
<div>
</div>
<div>
· Domain names used to play an important role for end users in discovering web resources, but search
</div>
<div>
engines have now replaced them as the primary method of discovery.
</div>
<div>
</div>
<div>
· End users today rarely directly interact with domain names due to the dominance of search engines and
</div>
<div>
mobile devices. Features like browser "omnibars" also allow more free-form input.
</div>
<div>
</div>
<div>
· Other identifiers like QR codes and social media handles now also compete for users' attention rather
</div>
<div>
than domain names.
</div>
<div>
</div>
<div>
· Domain names are becoming less visible in users' environments, yet they still provide an underlying
</div>
<div>
ubiquitous resolution context relied upon by other technologies.
</div>
<div>
</div>
<div>
· Surveys found search engines are by far the predominant method for accessing websites, with domain
</div>
<div>
name usage declining. QR code usage is increasing but still limited except in Asia.
</div>
<div>
</div>
<div>
· Decreased domain name visibility makes it easier for fraudsters to deceive users with lookalike names.
</div>
<div>
Users are also generally unaware that some TLDs signal a different resolution context.
</div>
<div>
</div>
<div>
In summary, domain names are no longer the primary method end users employ to find and access Internet
</div>
<div>
resources, decreasing their visibility and understandability while introducing security issues.
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
Link to the report:
</div>
<div>
<a href="https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-123-15-12-2023-en.pdf" target="_blank" rel="noopener">https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-123-15-12-2023-en.pdf</a>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
### SSAC Report on Urgent Requests in gTLD Registration Data Policy (SAC122)
</div>
<div>
</div>
<div>
· Focus is on handling of Urgent Requests in proposed gTLD registration data policy
</div>
<div>
</div>
<div>
· Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation
</div>
<div>
</div>
<div>
· Proposed policy requires response to Urgent Requests in 24 hours generally
</div>
<div>
</div>
<div>
· SSAC contends proposed policy for Urgent Requests is not fit for purpose
</div>
<div>
</div>
<div>
· Definition and required response times are incompatible
</div>
<div>
</div>
<div>
· Questions if need and rationale for separate Urgent Request process is fully justified
</div>
<div>
</div>
<div>
· Existing ICANN policy and industry practices offer useful precedents
</div>
<div>
</div>
<div>
· Proposed extensions allow responses up to 7 days, not reflecting urgency
</div>
<div>
</div>
<div>
· Lack of concrete data on frequency and handling of such requests currently
</div>
<div>
</div>
<div>
· Risks reputation of ICANN multistakeholder model effectiveness
</div>
<div>
</div>
<div>
- Provides 3 recommendations
</div>
<div>
</div>
<div>
§ Add structure to ensure Urgent Requests handled expediently
</div>
<div>
</div>
<div>
§ Tighten response time requirements to be fit for purpose
</div>
<div>
</div>
<div>
§ Gather data on Urgent Requests for future policy making
</div>
<div>
</div>
<div>
Link to the report:
</div>
<div>
<a href="https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-122-12-12-2023-en.pdf" target="_blank" rel="noopener">https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-122-12-12-2023-en.pdf</a>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
Have a nice evening!
</div>
<div>
</div>
<div>
Best,
</div>
<div>
</div>
<div>
M.
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
______________________________
</div>
<div>
</div>
<div>
Ing. Mag. Matthias M. Hudobnik
</div>
<div>
</div>
<div>
FIP • CIPP/E • CIPT • DPO • CIS LA
</div>
<div>
</div>
<div>
<a href="mailto:matthias@hudobnik.at">matthias@hudobnik.at</a>
</div>
<div>
</div>
<div>
<a href="http://www.hudobnik.at" target="_blank" rel="noopener">http://www.hudobnik.at</a>
</div>
<div>
</div>
<div>
@mhudobnik
</div>
<div>
</div>
<div>
_______________________________________________
</div>
<div>
At-Large mailing list
</div>
<div>
<a href="mailto:At-Large@atlarge-lists.icann.org">At-Large@atlarge-lists.icann.org</a>
</div>
<div>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" target="_blank" rel="noopener">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a>
</div>
<div>
</div>
<div>
At-Large Official Site: <a href="http://atlarge.icann.org" target="_blank" rel="noopener">http://atlarge.icann.org</a>
</div>
<div>
_______________________________________________
</div>
<div>
By submitting your personal data, you consent to the processing of your personal data for purposes of
</div>
<div>
subscribing to this mailing list accordance with the ICANN Privacy Policy
</div>
<div>
(<a href="https://www.icann.org/privacy/policy" target="_blank" rel="noopener">https://www.icann.org/privacy/policy</a>) and the website Terms of Service
</div>
<div>
(<a href="https://www.icann.org/privacy/tos" target="_blank" rel="noopener">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status
</div>
<div>
or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g.,
</div>
<div>
for a vacation), and so on.
</div>
</blockquote>
<div>
</div>
</blockquote>
<div>
_______________________________________________
</div>
<div>
At-Large mailing list
</div>
<div>
<a href="mailto:At-Large@atlarge-lists.icann.org">At-Large@atlarge-lists.icann.org</a>
</div>
<div>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" target="_blank" rel="noopener">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a>
</div>
<div>
</div>
<div>
At-Large Official Site: <a href="http://atlarge.icann.org" target="_blank" rel="noopener">http://atlarge.icann.org</a>
</div>
<div>
_______________________________________________
</div>
<div>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank" rel="noopener">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank" rel="noopener">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
</div>
</blockquote>
</body>
</html>