RE: Persistent or opportunistic IDs

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Interesting approach indeed.
> This would also save us the need to perform the reverse+forward DNS lookup
> by the taget nodes, which would reduce the latency imposed by noid, since ,
> the client (initiating host) will discover the multiple addresses of the
> server using DNS as in noid, but the server will discover the multiple
> addresses of the client using WIMP

And the downside being that the server application will not be able 
do remember the client ID in order to do a "callback" (connect to the
client) a day later, because the ID->locator mapping wouldn't exist
in general - it would only exist when there is active communication
using the ephemeral ID.

Further understanding the pros and cons of such IDs is worth-while.

> Yes, the cost is aosociated with the fact that if you have a non ephemeral
> id you need to defend it, i guess

Yep. If you use ephemeral IDs, as long as the peer returns a "that ID is
already used by somebody other than you", the client
can pick a new ephemeral and try again.

> I guess is more than that, it implies the additional round trips to get the
> information from the central data base (DNS).

Agreed.

> An interesting point of the WIMP noid combination that you suggest is that
> you provide just what each end point needs i.e. if it is working as a
> server, it gets a mechanisms to be reached and discovered, the RR asociated
> with noid. If it is client, it gets an ephemeral identifier, which cannot be
> used to initiate contact. In the case pf p2p, i guess that it will be
> required to fall back to full noid.

Yes. In effect the application need to know and express to the "stack"
whether there is a need to do "callbacks" on referrals, since this
affects which source identifier to use for the communication.
Would such a scheme be acceptable for the applications?

   Erik