Subject: Re: [rrg] moving towards recommendation: the current plan

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Dec 2009 10:47:21 -0500 (EST)

> From: Scott Brim <[email-masked]>

    > Do you think routing and addressing requires a session ID in every
    > packet? If not, let the upper layers find their own solutions

In a clean, carefully integrated architecture I might agree with you
(although robustness arguments, which often involve redundancy, might
disagree). In something that's evolving over time, starting from something
that's already got some 'bags on the side', there might be a certain value
in carrying around the semi-duplicate info. But it is of course impossible
to say specifically without examining the costs and benefits of a
particular proposed design.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Dec 2009 10:57:31 -0500

My own reaction to this question is similar.
I can imagine an architecture and set of tools where the responsibility 
for the identification was either dynamic or an upper layer responsibility.
However, I think that we may be better off, in trying to get to a better 
state, if the network / routing / lower layers provides a useful stable 
identifier.
One example is that this provides a hook on which to hang the various 
kinds of security mechanisms, so that security is not tied to the 
locators.  (security tied to the locator seems to be a problem that we 
gave ourselves by not having anything else for it to be based on.)
Similarly, it seems to me that having such an identifier simplifies many 
of the problems of adding and subtracting locators from a site.  While 
one can structure all the changes in terms of old-set->new-set, it seems 
much more robust to think in terms of an identifier aquiring new locator 
information.  This identification would seem to also be useful 
eventually in terms of policy management (which often loives at these 
layers), and related issues.

Yours,
Joel

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