Re: [recipe] Application layer
Bruce Nordman <bnordman@lbl.gov> Tue, 16 February 2010 07:33 UTC
Return-Path: <bnordman@lbl.gov>
X-Original-To: recipe@core3.amsl.com
Delivered-To: recipe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339F03A7171 for <recipe@core3.amsl.com>; Mon, 15 Feb 2010 23:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3h1Ki85Ii+x for <recipe@core3.amsl.com>; Mon, 15 Feb 2010 23:33:44 -0800 (PST)
Received: from ironport1.lbl.gov (ironport1.lbl.gov [128.3.41.47]) by core3.amsl.com (Postfix) with ESMTP id D73B03A7A96 for <recipe@ietf.org>; Mon, 15 Feb 2010 23:33:44 -0800 (PST)
X-Ironport-SBRS: None
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAK/ZeUtLZVjT/2dsb2JhbACbGHWxUgmMfYJigXkEgxQ
X-IronPort-AV: E=Sophos; i="4.49,482,1262592000"; d="scan'208,217"; a="127537284"
Received: from 75-101-88-211.dsl2dy.lmi.net (HELO bruce-nordmans-computer.local) ([75.101.88.211]) by ironport1.lbl.gov with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2010 23:35:16 -0800
Message-ID: <4B7A4A6C.5050209@lbl.gov>
Date: Mon, 15 Feb 2010 23:34:04 -0800
From: Bruce Nordman <bnordman@lbl.gov>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: recipe@ietf.org
References: <C2AFA516-0CBE-4326-8004-C0129AD03CDE@cs.columbia.edu>
In-Reply-To: <C2AFA516-0CBE-4326-8004-C0129AD03CDE@cs.columbia.edu>
Content-Type: multipart/alternative; boundary="------------040501090202060702050208"
Subject: Re: [recipe] Application layer
X-BeenThere: recipe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RECIPE \(Reducing Energy Consumption with Internet Protocols Exploration\)" <recipe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/recipe>
List-Post: <mailto:recipe@ietf.org>
List-Help: <mailto:recipe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2010 07:33:46 -0000
This email to cover Tom and JP's comments, and fill in some background. On 2/11/10 7:55 PM, Henning Schulzrinne wrote: > Bruce Nordman and I have been discussing whether we should re-convene a Bar BOF in Anaheim, focusing on topics beyond the usual Zigbee-vs.-IPv6 or LowPAN discussions. In particular, I think that the current stovepipe application layers (e.g., in BACS and the other control-oriented building networks) are not very helpful as a *long-term architecture*. We also might want to think about the interfaces that need to be exposed - we don't want our architecture to look like the 3GPP diagram... (If you've taken a look at the NIST interface diagram for the smart grid, this comparison is not purely theoretical, although obviously the protocols are completely different.) > > Does this sound like something of interest? > A key point in this (emphasis added above) is "*long-term architecture*" - in contrast to efforts for near-term deployment (next month or next year). My heuristic for planning horizon is to target what networks we want to have in 20 years, then work backwards to determine what has to be in place when to realize that. Zigbee Smart Energy 2.0 is probably what people should use in the near-term, and I would characterize it as "digitizing current functionalities". The Bar BOF would address a different topic - what architecture do we need/want to enable much different and better functionalities in the future. As an analogy, I think of SE 2.0 as like basic FTP - it was (and still is) useful, and emerged early on. What I have in mind is more analogous to rich web content. Sure in both cases you are transferring data, but the user experience - and necessary architecture - are enormously different. We should not have burdened FTP design with web issues, and not have tried to constrain the web by FTP. As an issue of architecture, we need to consider what will be the key layers for networking the physical world (organized around building networks), including the data model(s) and the role of people as active nodes on the network, with a need for standard interfaces. Also in play are institutional issues - does IETF play any role in this? ISOC? what other orgs? I assume most of the existing IETF (and related) work in this area as a given. The only topic I think may need updating from an architectural standpoint is discovery, to ensure that physical context is part of that. The Bar BOF I hope will focus on higher layers. The comments seem to primarily note that we should not attempt to plow ground already being addressed in other contexts. I think Henning and I would completely agree. I don't see any current process which addresses long-term needs, and it seem clear that they are quite different from those in the near-term. A "smart grid" presentation of mine is on my web page (below). --Bruce > (There is some work in the SIP Forum context, but this is not [just] about a particular protocol.) > > Henning > _______________________________________________ > recipe mailing list > recipe@ietf.org > https://www.ietf.org/mailman/listinfo/recipe > -- Bruce Nordman Lawrence Berkeley National Laboratory BNordman@LBL.gov -- 510-486-7089 eetd.lbl.gov/ea/nordman/
- Re: [recipe] Application layer Tom Herbst
- Re: [recipe] Application layer Bruce Nordman
- [recipe] Application layer Henning Schulzrinne
- Re: [recipe] Application layer Tom Herbst
- Re: [recipe] Application layer JP Vasseur
- Re: [recipe] Application layer Henning Schulzrinne
- Re: [recipe] Application layer JP Vasseur