[ih] Multi-homing naming Was: Re: History question -- multi-homing

[Brian E Carpenter]

Karl,

> 
> That dynamic has created the need for not only what ISO/OSI called 
> "titles" but also something more.

The hot money now is on how AI agents will find each another. I agree
that DNS is not up to this task.

https://datatracker.ietf.org/group/dawn/about/

Regards/Ngā mihi
    Brian Carpenter

On 13-Sep-26 10:56, Karl Auerbach via Internet-history wrote:
> 
> On 9/12/26 2:06 AM, vinton cerf via Internet-history wrote:
>> It would be an interesting exercise to posit a different identification
>> scheme that would scale and also permit multi-homing. Has someone already
>> worked that out? Would it require a flat ID space?
> 
> Back in the 1970's my (now gone) friend (and Best Man at my wedding)
> Frank Heinrich (student of Dave Farber and who worked on DCS) taught me
> that we ought not to think of application-to-application associations as
> having invariant locations for the participant entities.  The idea was
> that on a network, application level stuff can move - that the binding
> of applications to network addresses ought not to be considered as
> immutable.
> 
> Others seem to have had similar thoughts - I, however, being slow on the
> uptake, never really understood the reasons why ISO/OSI defined "titles"
> for things.
> 
> It wasn't until the web came along, and more recently use of web
> protocols as vehicles for service APIs, i.e. "cloud computing", that I
> began to realize that we now live on a network in which Frank's wisdom
> has come true.
> 
> In today's network world, at the application layer, we have entities
> that split/partition, move, join, vanish, and appear.
> 
> That dynamic has created the need for not only what ISO/OSI called
> "titles" but also something more.  We need more because after a
> client-application association is created, the client or the application
> could split/partition.  Yet because of things like state and caching, we
> want to have handles that let us preserve that association relationship
> without abandoning all of the context (or relying on troublesome things
> like "cookies".)
> 
> To answer Vint's question: I think that our experience with DNS has
> informed us that caching is not only important, it is necessary.  And
> that structure in identifiers is needed in order to do effective caching
> of what are very large (and growing), dynamic, name spaces and mappings.
> 
> Personally, I am dubious whether DNS is dynamic enough for this. (And I
> certainly want to avoid the wars, particularly trademark wars, that have
> burdened DNS administration - so my preferred format for elements of
> these new kinds of names are tokens that do not carry human semantics.)
> 
> (I have come to also believe that on today's net we often need to find
> instances of resources by attributes rather than names.  This suggests,
> to me, that we need something parallel to DNS that does lookups based on
> some sort of flexible and extensible set of attributes - sort of like
> the core of a search engine, but better packaged as a network service
> for software to use, and more efficient and dynamic.)
> 
> I wrote about this way back in 2010:
> 
> On Entity Associations In A Cloud Network
> 
> https://www.cavebear.com/archive/public/cloud-entities.pdf
> 
>           --karl--
>