Tim Shepard wrote:
We do not necessarily need such "a way to do lookups" that scales.
Indeed for some architectures for how these identifiers might be used,
we would need such a mechanism.
But other architectures might have other ways of doing things (like
referals might carry something other than just one of these flat
identifiers).
I think it might be helpful to understand all the different ways
referals might be passed, and then in each case, what lookupability
properties the various names, and locators would need to have.
Yes, one can contemplate such an approach. What is hard to determine is
how large set of the applications would need to be modified to handle
this. (Referrals, callbacks, and long-lived application associations
are all problematic - see draft-ietf-shim6-app-refer.)
Note that it isn't just the applications; in some cases the application
*protocols* would need to be modified (to be able to carry the new
"referral handle" in addition to a 128-bit IPv6 referral handle).
This means that the application needs to negotiate with the peer to
determine whether or not it supports the new type of referral handles
(whatever they might be).
These are all reasons why I'm personally trying to figure out what we
can do under the existing 128-bit API where the 128-bit quantities
passed over that API can be used as referral handles.
Erik 'don't break the app' Nordmark
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
