<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I am concerned about fragmentation of the net, but in ways that
seem to be divergent than the concerns I usually hear.</p>
<p>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.</p>
<p>I think that world is dead.</p>
<p>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.)</p>
<p>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.</p>
<p>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.</p>
<p>(This idea is the underlying theme of my somewhat long blog item
from 2016: "Internet: Quo Vadis (Where are you going?" at
<a class="moz-txt-link-freetext" href="https://www.cavebear.com/cavebear-blog/internet_quo_vadis/">https://www.cavebear.com/cavebear-blog/internet_quo_vadis/</a> 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.)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p> --karl--<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 12/22/23 1:04 AM, Wolfgang
Kleinwächter wrote:<br>
</div>
<blockquote type="cite"
cite="mid:840950645.1328422.1703235870543@email.ionos.de">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta charset="UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">matthias@hudobnik.at</a>
</div>
<div> </div>
<div> <a href="http://www.hudobnik.at" target="_blank"
rel="noopener" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">At-Large@atlarge-lists.icann.org</a>
</div>
<div> <a
href="https://atlarge-lists.icann.org/mailman/listinfo/at-large"
target="_blank" rel="noopener" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">At-Large@atlarge-lists.icann.org</a>
</div>
<div> <a
href="https://atlarge-lists.icann.org/mailman/listinfo/at-large"
target="_blank" rel="noopener" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
</blockquote>
</body>
</html>