[At-Large] The SSAC has published SAC123 and SAC122
Carlton Samuels
carlton.samuels at gmail.com
Mon Jan 1 19:58:48 UTC 2024
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 at 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 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*
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/at-large/attachments/20240101/fc32d968/attachment-0001.html>
More information about the At-Large
mailing list