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.