Re: identity persistence and comparison issues

Joe Touch wrote:
> 
> 
> Iljitsch van Beijnum wrote:
> 
>> On 14 jun 2004, at 12:12, Joe Touch wrote:
>>
>>>     a) are two IDs comparable within the same app over time?
>>>         i.e., can an ID change? if so, can the old ID be used?
>>
>>
>>
>>>     b) can two IDs on different apps on the same node be compared?
>>
>>
>>
>>>     c) can two IDs on different nodes be compared?
>>
>>
>>
>> During the meeting there was some talk about per-session identifiers. 
>> Wouldn't such identifiers be pretty much useless?
> 
> 
> They're used in HIP, e.g.
> 
>> What I want from an identifier is be able to set up sessions towwards 
>> it, the same way I can now with a FQDN or IP address. If this isn't 
>> possible, what use are these identifiers? In this situation an 
>> identifierless solution would be better. And if there are ephemeral 
>> values that are used internally somewhere, we should probably avoid 
>> calling them "identifiers".
> 
> 
> The name of the endpoint (A) that you talk to isn't the same as the name 
> used for forwarding (B), which may not be the same as any of the 
> multiple endpoint addresses (C1...CN).
> 
> The one I'm referring to is B. A might be a DNS name or current 'well 
> known' IP address used to bootstrap the communication.
> 
>> In the good old days it would have been possible to presume that if 
>> two FQDN or IP address values are identical, they point to the same host.
> 
> 
> A FQDN has always been mappable to multiple IP addresses. If two IP 
> addresses are identical, it is still the case that they either point to 
> the same host or something that emulates one host.
> 
>> However, in these days of load balancers this is no longer true, 
>> although it's usually safe to make this assumption in applications 
>> because the different hosts would be providing the same service.
> 
> 
> When load balancers break the 'same host or equivalent' they can 'break 
> the Internet' (e.g., arbitrary protocols can break).
> 
>> In the design team # 1 we had some discussions on the FQDN <-> ID <-> 
>> locator relationship and I think we agreed that the ID should be tied 
>> to a single host, even if the FQDN is shared between more than one host.
> 
> 
> A must be tied to a single host or something that emulates such, for the 
> reasons above.
> 
>> Obviously it must be possible to change identifiers. This means it 
>> must be possible to have more than one at the same time or operators 
>> will revolt. Another reason to have more than one ID at one point in 
>> time is for privacy reasons, this would be similar to RFC 3041.
> 
> 
> Changing A is like renumbering now; a slow, out-of-band operation that 
> requires resynchronization (e.g., of the DNS). Changing B is more of an 
> opportunity than a liability...

I think this is a very hard conversation to have in the abstract.
I think it will be much easier to analyze these questions in terms
of a specific proposal. So maybe we should note them as open, until
our ongoing reduction of the solution set from many to few has
been achieved.

   Brian