Re: [6lowapp] BOF proposal: update
David Ryan <oobles@gmail.com> Thu, 24 September 2009 11:42 UTC
Return-Path: <oobles@gmail.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id A13CF28C0E2 for <6lowapp@core3.amsl.com>;
Thu, 24 Sep 2009 04:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
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 66z835AZeOuF for
<6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 04:42:34 -0700 (PDT)
Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com
[209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 46A4628C0D8 for
<6lowapp@ietf.org>; Thu, 24 Sep 2009 04:42:34 -0700 (PDT)
Received: by ewy28 with SMTP id 28so2167722ewy.42 for <6lowapp@ietf.org>;
Thu, 24 Sep 2009 04:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding;
bh=/MqqIW3nE6wSGElst8E9G+ltsXbUfL5vhK1csvDRPUk=;
b=AGgViWPi/l6Jm5s8ZxRUT8K+yWPOt50AJkpC5xx1+7ohKneNIhn6TRP/DXDf+yWobL
yuGsAUfOiO+znOAaLi8CrAbGmLzvixrPL/Og5jaCA7TSIVZiBP2tll034NKWvitwyqW2
B9Q30Ol7BDLdVDrft+9zmmRheoW9XmI1hKBIk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
b=JJ6K4JhMhxNpjRSa2mh3k1LubR4XXpzsjhBjBA44NVxeQe5E6IhVDtrXyT5O19OfWN
eOAoF5fcK5tAP6mdyAJI+6y4hlUI8RtQFCtoAFMAJczvDjKzVny2rYY+rM/rdQhrl1oj
a+n+5tiEGuw+ouomjDkYsnw1SElx0jZ+dYSA4=
MIME-Version: 1.0
Received: by 10.210.154.20 with SMTP id b20mr7431044ebe.29.1253792617624;
Thu, 24 Sep 2009 04:43:37 -0700 (PDT)
In-Reply-To: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org>
References: <D9BF98E0-72D4-49BA-9542-3264EE96F8E8@tzi.org>
<334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org>
Date: Thu, 24 Sep 2009 21:43:36 +1000
Message-ID: <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com>
From: David Ryan <oobles@gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] BOF proposal: update
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks
<6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>,
<mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>,
<mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2009 11:42:35 -0000
Hi Carsten, I have a few clarification questions in regards to the BOF proposal. I'll quote the relevant sections and add my remarks/questions. > In particular the Smart Energy v2.0 (collaboration of NIST, UCA > international, ZigBee and the IEC) is in urgent need of both > application protocol and application commissioning solutions. This mentions the urgent need for Smart Energy v2.0. The timeframe for the working group is to submit protocol specifications by Q3 and Q4 2010. Have the timeframes for Smart Energy been published? I'm concerned that decisions will already be made by Smart Energy and this group will simply have to fall inline with decisions already made. If this group is to influence the Smart Energy decision, I think it would be appropriate for them to publish their timeline? Also, it might be fair to add HomePlug to the Smart Energy v2.0 list as that group has also been involved. > The goal of 6lowapp is to produce application protocol and > application commissioning solutions suitable for providing us the web > for resource constrained devices The initial paragraph discusses "application protocols" for the "Wireless Embedded Internet", while other sections discuss the "embedded web" and "web for resource constrained devices". Is there a difference? > This working group will not work on new content formats > or encodings, nor the compression or adaptation of HTTP. (to be expanded) I realise there is a comment that this needs "to be expanded", so I apologise for jumping the gun. If the aim is to build the "embedded web" and not adapt HTTP, does this suggest that the draft submitted by Brian Frank (Chopan) is outside the scope of the working group? This seems to be contradictory with the opening paragraph. Finding appropriate application protocols seems to be more correct and casts a wide net to find a good solution. I'd also like to ask the rational for discarding the concept of new content formats or encodings? Assuming that a new format or encoding has benefits as defined by the "Problem Statement and Objectives", shouldn't it be within the scope to review and debate the merits of such encodings? To be open and clear to everyone on the list, I plan on submitting a draft which incorporates what many will consider a new encoding. The issue of data formats is also mentioned here: > Data formats will be considered > in the working group as general requirements and considerations in the > other technical work, but no new standardization is needed. Once again, isn't this a premature to set the scope of the solution before the requirements have been devised. > 6lowapp will cooperate with external organizations on work item > requirements and standards interoperability. These include the W3C > and OASIS on data formats Reading between the lines on this I get the feeling that the choice of using the W3C EXI encoding has already been made. Is there a set list of applicable data formats? If there are, once again, I believe this prematurely defines the solution. > I think that is good > because the IETF is much better in handling focused, specific work > items than in grand, boil-the-ocean efforts. I understand the need here to focus the working group on a specific problem. However, I also think it is very important to not under-estimate the importance of this working group. If the output of this working group is to form the basis for Smart Energy, it will form the corner stone of the "Internet of Things" for years to come. Smart Energy is just the first of many application protocols that will be defined by standards groups. I'm sure everyone will agree that for this reason it is important to get this right and not rush into a pre-defined solution without evaluating a range of possible solutions. Regards, David.
- [6lowapp] BOF Status Carsten Bormann
- [6lowapp] BOF proposal: update Carsten Bormann
- Re: [6lowapp] BOF proposal: update Juergen Schoenwaelder
- Re: [6lowapp] BOF proposal: update Enrico Marocco
- Re: [6lowapp] BOF proposal: update Zach Shelby
- Re: [6lowapp] BOF proposal: update Enrico Marocco
- Re: [6lowapp] BOF proposal: update David Ryan
- Re: [6lowapp] BOF proposal: update Carsten Bormann
- Re: [6lowapp] BOF proposal: update Don Sturek
- [6lowapp] UPDATED: BOF proposal: update Don Sturek
- Re: [6lowapp] BOF proposal: update David Ryan
- Re: [6lowapp] BOF proposal: update Don Sturek
- Re: [6lowapp] BOF proposal: update Brian Frank
- Re: [6lowapp] BOF proposal: update Sam Roberts
- Re: [6lowapp] BOF proposal: update Don Sturek
- Re: [6lowapp] BOF proposal: update Zach Shelby
- Re: [6lowapp] BOF proposal: update Zach Shelby
- Re: [6lowapp] BOF proposal: update Zach Shelby