Subject: [rrg] Next topic: properties of identifiers

From: Tony Li <[email-masked]>
Date: Tue, 14 Apr 2009 20:52:00 -0700

Hi all,

Thank you for your help with the terminology discussion.  I'd like to 
propose the next question: what are the necessary and sufficient 
properties of identifiers?

We discussed this at Dagstuhl and came away with the following:

- topology‐independent
- stable, at discretion of owner
- unambiguous
- distinguishable (two for same object?)
- facilitate session‐level referrals

Thoughts?

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 15 Apr 2009 13:53:52 +0800

> - facilitate session‐level referrals

Does the identifier need any structure? e.g. hierarchical information. so as
to make the ID based routing on overlay network (mapping overlay)more
efficient and make the ACL more flexible.

Xiaohu

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Apr 2009 10:35:01 -0400

As I understand it, while an identifier may, in a specific protocol
proposal, have structure (hierarchical or otherwise), there are no
specific structural requirements for identifiers in general.  There is
no general requirement that they have structure.

Yours,
Joel

Xu Xiaohu wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Peter Sherbin <[email-masked]>
Date: Wed, 15 Apr 2009 08:10:51 -0700 (PDT)

> necessary and sufficient properties of identifiers?

- generated, distributed, managed by whom / how?
- private property of the owner?
- if permanent lifetime, what happens if the object dies?

Thanks,

Peter

--- On Tue, 4/14/09, Tony Li <[email-masked]> wrote:

> From: Tony Li <[email-masked]>
> Subject: [rrg] Next topic: properties of identifiers
> To: [email-masked]
> Date: Tuesday, April 14, 2009, 11:52 PM
> Hi all,
> 
> Thank you for your help with the terminology discussion. 
> I'd like to propose the next question: what are the
> necessary and sufficient properties of identifiers?
>

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Apr 2009 14:40:37 -0400

Tony, 

First, there are a different uses for identifiers and each has
different requirements.  Before we can talk about properties for
"identifiers" in general we need to separate out which particular uses
we are talking about.  For example, are you including discovery
starting from FQDNs?  Kerberos identifiers for auth/auth?  

Second, what is the purpose of the exercise?  I suspect that every
practical use case knows what properties it needs already for its
various identifiers.  If you look at the requirements of a specific
use case the properties fall out.  One possible purpose I could see
(and one I was trying to get at in my slides) would be to reduce the
number of identifiers we think we need.  What do you have in mind?

Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Apr 2009 15:35:36 -0400

> - topology‐independent

by definition

> - stable, at discretion of owner

Is that a useful attribute?  Is the point that they are not
necessarily persistent, or that they might be persistent, or ... ?  

> - unambiguous

Is this a statement about scope?  Please clarify.

> - distinguishable (two for same object?)

Does "distinguishable" mean a name only names one object?  

I don't see why an object can't have multiple names from the same
namespace.  

> - facilitate session‐level referrals

That's a statement about a requirement for identifiers used in session
control.  It's not a requirement for any particular identifier, e.g.
it's not a requirement for FQDNs.  We need to make a statement about
the scope of this exercise, and what requirements it is meant to meet,
before proceeding much further.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Apr 2009 11:18:06 +1200

> - stable, at discretion of owner

I'd say: must have a defined lifetime, set by the owner, which may be infinite.

> - unambiguous

I'd say: must have a defined scope within which they are unique and unambiguous.
The scope may be universal. [Now define 'universal'. It's not so easy.]

> - facilitate session‐level referrals

   Brian

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Apr 2009 21:03:09 -0700

Hi Scott,

 > number of identifiers we think we need.  What do you have in mind?

So, at a high order, I'm hoping to make forward progress.  ;-)

More specifically, if we can converge on what properties we would like 
identifiers to have, it might help to constrain the solution space.

> starting from FQDNs?  Kerberos identifiers for auth/auth?  

I'm trying to stay independent of any particular use case and look at 
the abstract properties that we'd like to have in a locator/ID split.

To help simplify the discussion (I hope ;-), I'll certainly stipulate 
that every solution is certainly going to have a number of identifiers. 
  I think we're most interested in the identifiers that correspond to 
locators.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Apr 2009 22:31:44 -0700

> I'd say: must have a defined lifetime, set by the owner, which may be infinite.

I like this.  How about: "... and can be terminated at any time at the 
owner's discretion."

> The scope may be universal. [Now define 'universal'. It's not so easy.]

How about 'global' instead?

Do we really want local identifiers?

Tony

---

From: Scott Brim <[email-masked]>
Date: Mon, 20 Apr 2009 15:28:51 -0400

Excerpts from Tony Li on Fri, Apr 17, 2009 09:03:09PM -0700:
> More specifically, if we can converge on what properties we would
> like  identifiers to have, it might help to constrain the solution
> space.
>
>> "identifiers" in general we need to separate out which particular
>> uses we are talking about.  For example, are you including
>> discovery starting from FQDNs?  Kerberos identifiers for auth/auth?  
>
> I'm trying to stay independent of any particular use case and look
> at  the abstract properties that we'd like to have in a locator/ID
> split.

But identifiers need different properties for different purposes. 

> I think we're most interested in the identifiers that correspond to  

Let's be clear what we're working on then.  It's properties of
identifiers for the things that will initially be contacted in order
to set up communication flows (probably aka stack IDs).  Yes?

After that we can look at properties of identifiers used for session
control.  They may be the same identifiers, as in HIP or ILNP, but
they need not be.  OK?

---

From: Scott Brim <[email-masked]>
Date: Mon, 20 Apr 2009 15:31:58 -0400

> I like this.  How about: "... and can be terminated at any time at the  

In actual use the owner may have committed to a minimum duration.
Brian's phrasing is better imho.

>>> - unambiguous
>>
>> I'd say: must have a defined scope within which they are unique and
>> unambiguous.  The scope may be universal. [Now define 'universal'.
>> It's not so easy.]
>

Let's not assume too much about solutions.  Everything has scope.

---

From: Tony Li <[email-masked]>
Date: Tue, 21 Apr 2009 08:47:17 -0700

Hi Scott,

> Brian's phrasing is better imho.

Ok, I can live with that.

> Let's not assume too much about solutions.  Everything has scope.  

Again, the point of the discussion is to figure out what classes of 
solutions actually are appropriate.  It seems to me like supporting 
local identifiers is worthy of discussion.

I've seen one advocate for them (ILNP), where they make a handy 
opportunity for those folks who prefer privacy.  Changing your locator 
to something with local scope does provide benefits in that area, but it 
creates issues in others.  Do identifiers now come in a split namespace? 
  Here there be complexity...  ;-)  Are folks ok with this?

Tony

---

From: Scott Brim <[email-masked]>
Date: Tue, 21 Apr 2009 12:04:14 -0400

Excerpts from Tony Li on Tue, Apr 21, 2009 08:47:17AM -0700:
>>>> I'd say: must have a defined scope within which they are unique
>>>> and unambiguous.  The scope may be universal. [Now define
>>>> 'universal'.  It's not so easy.]

Oh.  Then I think we actually agree on procedure, but let's make it
explicit:

  The goal is to figure out which classes of solutions are
  appropriate, and one input to that is to look at the implications
  each solution class has on properties of identifiers.

Some of us have been saying that you can't do "properties of
identifiers" in general, you have to talk about which kinds of
identifiers, in which context.  I guess you agree.  If so, sorry, I
hadn't understood.

Yes, local identifiers are worthy of discussion.

> opportunity for those folks who prefer privacy.  Changing your
> locator  to something with local scope does provide benefits in that
> area, but it  creates issues in others.  Do identifiers now come in
> a split namespace?  Here there be complexity...  ;-)  Are folks ok
> with this?

Again, I would like the process to be explicit, otherwise we will
probably ramble around and it will be hard to agree on whether we have
reached any agreements.  Do you want to start specifically with the
class of solutions that includes ILNP, look specifically at "host"
identifiers,  and look at implications/possibilities/requirements?
That would be fine with me.

---

From: Tony Li <[email-masked]>
Date: Wed, 22 Apr 2009 08:43:00 -0700

Hi Scott,

>   each solution class has on properties of identifiers.

Agree.

> identifiers, in which context.  I guess you agree.  If so, sorry, I

No, I think it's reasonable to talk about the classes of solutions and 
the reasonable properties of the (host, interface, stack, ...) 
identifier that is bound to the locator within each class.

> Yes, local identifiers are worthy of discussion.

So I think that local identifiers are acceptable, but solutions should 
always also provide global identifiers.  The decision of which to use 
should be left to the end station/stack/user.

> That would be fine with me.

Again, I don't want this to devolve into another partisan bickering 
match.  I would much rather talk about general classes (ala Bill's 
different strategies).

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 23 Apr 2009 07:07:47 -0400

Excerpts from Tony Li on Wed, Apr 22, 2009 08:43:00AM -0700:
> No, I think it's reasonable to talk about the classes of solutions
> and  the reasonable properties of the (host, interface, stack, ...)

This demonstrates my point: You are assuming the identifier of
interest is one that is "bound to the locator", i.e. the thing that
just the locator gets you to is what you want to describe in this
exercise.  In this case one could just as easily envision having
identifiers of interest name things at a finer level of granularity,
where a locator gets you to a particular device (possibly virtual) but
initial packets must include both locator and identifier, so that when
the packet arrives at the device named by the locator, the device can
figure out which particular communication endpoint (named by the
identifier) you want to talk to.  The "identifier that is bound to the
locator" could name the device but would not be interesting to us and
would not be used in normal communications, only by device management.

I'm happy to look at properties for identifiers that are "bound to
locators" but let's not assume that each class has such things.  Also
some classes do not say anything about endpoint identifiers at all.

> So I think that local identifiers are acceptable, but solutions
> should  always also provide global identifiers.  The decision of
> which to use  should be left to the end station/stack/user.
>
>> probably ramble around and it will be hard to agree on whether we
>> have reached any agreements.  Do you want to start specifically
>> with the class of solutions that includes ILNP, look specifically
>> at "host" identifiers,  and look at
>> implications/possibilities/requirements?  That would be fine with
>> me.
>

Well, let's try it but we'll have to watch out for implicit
assumptions.

... and I beg people to come up with different names than "B.3".  I'll
never remember the mappings from the outline headings to what they
actually describe.  It's like referring to a paper by its footnote
reference, e.g. [17].

Scott

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 23 Apr 2009 18:23:02 +0300

Hi Scott and Tony,

> some classes do not say anything about endpoint identifiers at all.
I agree with Scott here.

For 3.3.2.2. Identifier variants
B2a Each host has a single identifer to which the locators are
attached. This identifier is used by the layer-4/5 and higher
protocols to compose the SID.

IMHO, the identifier should not be bound to the locator.
The reason is that you could create an Endpoint Layer  - as discussed
in the paper "Breaking Up the Transport Logjam” from
http://conferences.sigcomm.org/hotnets/2008/papers/HotNets2008proceedings.pdf
- between the network and transport layer in the stack. Then if the
identifier is used in a similar way as a HTTP cookie (RFC2965) in the
Endpoint Layer you might create a generic session state machine for
every application when the underlying locator(s) are changing. So when
a mobile client is changing its attachment point in Internet any
application session (not only HTTP) could be continued though the
locator(s) has changed - if the timers are allowing it.
Another place where you could use the "Endpoint cookie"=identifier is
in multihoming. A site has two separate service providers that are
offering two different Area Locators for the server that is using one
Local Locator. In DNS the server have two records, ALOC1:LLOC and
ALOC2:LLOC. The client is choosing ALOC1:LLOC for communication,
session is established and the identifiers (Endpoint cookies) are
exchanged but at some stage the session via ALOC1 fails. After a while
the client notice that the session has stalled but in the DNS cache
there is a second entry, ALOC2:LLOC. So the client stack decides to
try ALOC2:LLOC instead and the connection is re-established with the
help of the identifier (Endpoint cookie). Security issues arises, need
to look into that and if somebody has ideas feel free to make
proposals.

-- patte