Re: [rrg] RRG to hibernation

Tony Li <tony.li@tony.li> Wed, 05 December 2012 17:11 UTC

Return-Path: <tony.li@tony.li>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29EE21F883B for <rrg@ietfa.amsl.com>; Wed, 5 Dec 2012 09:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.437
X-Spam-Level:
X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSCL0TmZN0X6 for <rrg@ietfa.amsl.com>; Wed, 5 Dec 2012 09:11:19 -0800 (PST)
Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5E71021F8835 for <rrg@irtf.org>; Wed, 5 Dec 2012 09:11:19 -0800 (PST)
Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Xq661k00416AWCUAFtBKAG; Wed, 05 Dec 2012 17:11:19 +0000
Received: from dhcp-10-155-40-143.cisco.com ([128.107.239.234]) by omta06.emeryville.ca.mail.comcast.net with comcast id Xt941k008547xYo8St961P; Wed, 05 Dec 2012 17:09:17 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <0d9601cdd2c2$57d22290$077667b0$@huitema.net>
Date: Wed, 05 Dec 2012 09:09:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li>
References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <CAFgODJcP1zvwRJukJdnqjSR-78XAMB1nSxL32gjUQB+NqpgESg@mail.gmail.com> <50A18F75.8060001@joelhalpern.com> <CAFgODJcDAzaYPrWFEJhgeCjnN_M9tdd+pdHTiccd=Dz=1mYrLg@mail.gmail.com> <EC8FD781-E416-4AE6-BA99-F74FE2DDA14D@tony.li> <CAFgODJfMBJBxNJ_M1_L=K0f2DpbZvzOBUgLZ6sT+-y+JevGeSg@mail.gmail.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> <F502F124-32EC-40B9-9C3F-4E2DF5337B62@tony.li> <0d9601cdd2c2$57d22290$077667b0$@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.1499)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354727479; bh=D8MKMjFRUTTalVqf2a7YkV90J9A25nshGKPwXpW3a6U=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=L4s8fIRwBZ5Boa+etKs/6Vw3qY848GyiKSBA+8JO6cqyZGMUX9Ex4b3bPavmPuV7E pexuxlcR6tWSbgFhorU3OnImlrc4y4o2y0ALqppoy3jMJNLlD0gUDQd3Qii6Mzw91j PmzoOIaoL71HTdOT1WwHlbRmd4rc6UXqQjU8b0nNi0qPnXBIk8qVphpu6BJGCyIqYp bHzm8A9/eg3VF9fgwHvi/2BQ6PXirGst73JjP3iRpxstdWVkNexmQ0tUtPhqSzGGhE y6VWvrpjAd9dahG8vdboK/F0towBQEb5yuFGv0zBVbb2j04hE35RZnQYjE9cxdQb8s q1iCD4FOJXEAA==
Cc: rrg@irtf.org
Subject: Re: [rrg] RRG to hibernation
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2012 17:11:19 -0000

On Dec 5, 2012, at 12:27 AM, Christian Huitema <huitema@huitema.net> wrote:

>> Hi Scott,
>> 
>> Doesn't that strike you as a layering violation?  Shouldn't a stack shield
>> applications from having to create these mechanisms?
> 
> Not really. Applications do have their own concept of identity, for very
> good reasons -- think of the difference between managing corporate data,
> your personal email, and an online game. They also have their own specific
> "time line" -- anywhere between instant to forever. It is quite hard to
> develop a "one size fits all" solution. Otherwise, "the market" probably
> would have created one.


Yes, entirely reasonable.  When an application is going to be mobile across stacks, then another mechanism is necessary.  However, for the mobility of the stack itself, that support should be intrinsic.

Should apps have to know that the infrastructure has changed and that the active interface now has a different L3 name?

Tony