[At-Large] The SSAC has published SAC123 and SAC122
bzs at theworld.com
bzs at theworld.com
Mon Dec 25 05:34:33 UTC 2023
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 at 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 at 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 at 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 at 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 at hudobnik.at
>
> http://www.hudobnik.at
>
> @mhudobnik
>
> _______________________________________________
> At-Large mailing list
> At-Large at 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 at 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 at 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 at 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*
More information about the At-Large
mailing list