[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Persistent or opportunistic IDs

On 6-mei-04, at 23:48, Erik Nordmark wrote:

If we are assuming that the persistent identifiers provide a superset
of the functionality/semantics prociuded by the short-lived identifiers,

No, that's not the case. Unfortunately we all seem to mean something slightly different when talking about these two types of identifiers. The difference I'm interested in is the one between a NOID-like approach where we have FQDNs and locators, but no new identifier space, vs the FQDN -> long lived ID -> locators approach. We had solutions in this area on the table a little under a year ago, but this type of approach isn't so much in vogue any more now. (This is what I was getting at with "old fashioned id/loc approaches".)

Anyway, to get to the point: in NOID-type approaches it's possible to be backward compatible with existing transport protocols. This isn't really possible with approaches that introduce a new ID namespace. So the latter isn't a proper superset of the former.

then taking the step should be easy; the question is what benefit
one would derive, if any, (and at what cost) from taking the step to
the persistent identifiers.

Three things:

1. It's possible to set up new sessions when some locators are unreachable without cooperation from applications.
2. References work.
3. If the identifiers are properly secured (secure mapping service such as DNSSEC or the identifiers are crypto-based) there are more and better ways to secure the multihoming solution.

As one example, I think that multihoming with short-lived identifiers
implies a change to the applications that do referrals and/or callbacks
(depending on the actual multi6 approach they might need to change to
pass FQDNs, locator lists, or something else where they today
might pass a single IP address). Thus they need some change.

Yes.

Will moving from short-lived identifiers to persistent identifiers
imply another change to that class of applications?
[This is just an example; I don't expect anybody to answer this particular
question at this point in time.]

If we can make these identifiers fit inside locators (= they must be 62 bits or shorter) I don't think we need to change anything that's visible to applications. Obviously the multi6 solution must be extended to support the identifiers, there will probably have to be a mapping service of some kind and we need changes to address configuration so hosts can configure themselves with an appropriate identifier.

Thus I do think we'd need to understand more details about such a transition
(or probably, coexistence) between different classes of identifiers
before being able to guage the cost/benefit tradeoffs.

Of course. Let's start with a question that's probably a bit easier to answer: is a NOID-like solution that's mostly about keeping existing sessions running when there is an outage sufficient?