Re: [rrg] RRG to hibernation

Scott Brim <> Mon, 10 December 2012 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EE9121F8E6C for <>; Mon, 10 Dec 2012 05:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 63vhDWwrtvl7 for <>; Mon, 10 Dec 2012 05:01:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 12EB421F8E6E for <>; Mon, 10 Dec 2012 05:01:37 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 1AC1326803A; Mon, 10 Dec 2012 08:01:35 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eZuOv3TL9u71; Mon, 10 Dec 2012 08:01:34 -0500 (EST)
Received: from swbi2mbp.local ( []) by (Postfix) with ESMTPSA id 791F8268038; Mon, 10 Dec 2012 08:01:34 -0500 (EST)
Message-ID: <>
Date: Mon, 10 Dec 2012 08:01:35 -0500
From: Scott Brim <>
Organization: Internet2
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Tony Li <>
References: <> <> <> <> <> <> <> <09cc01cdc173$71323cd0$5396b670$> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rrg] RRG to hibernation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Dec 2012 13:01:38 -0000

On 12/04/12 14:16, Tony Li allegedly wrote:
> On Dec 4, 2012, at 10:20 AM, Scott Brim <> wrote:
>> I don't know who "they" is but applications that want to be robust
>> across network changes have their own identity-related functions.  They
>> have done their own loc/id split, for the identities that matter to them
>> (app/session level), and use it to sustain sessions.  They don't care
>> about or need what this list is talking about.
> Hi Scott,
> Doesn't that strike you as a layering violation?  Shouldn't a stack shield applications from having to create these mechanisms?
> Regards,
> Tony

(sorry for the delay)

First of all I'm talking about general Internet use, not special cases
like data centers.  In those cases it makes plenty of sense to treat all
higher layer functions in a block and use lower layer identification

Identification is not limited to a particular layer or activity --
identities are used at multiple layers and in higher layers there can be
multiple independent identities (and identification functions).  There
is variation in what is being identified, how authentication and
authorization are done, what happens during events, lifetime, etc.
There was a time when everything used lower layer tuples for
identification and that _was_ a layer violation.  Now they have figured
out that they have to have their own mechanisms in order to be free of

Could they all use the same mechanisms provided by lower layers?  The
variation in requirements says no.  Higher layer functions often need
independence in how they behave - the end-to-end argument applies up the
stack, not just in the network infrastructure.  Not only is there
variation in how identity is used already, we want to ensure that
freedom for flexibility and robustness (just as we do elsewhere in the
architecture).  In particular, nowadays some "sessions" can leap between
lower layer entities, independently of each other, while some remain and
all maintain identities. Higher layer functions related to identity
simply cannot depend on lower layers to provide it - they are now decoupled.