[6lowapp] UPDATED: BOF proposal: update

["Don Sturek" <[e-mail]>]

As soon as I sent this, NIST published their initial roadmap document for
Smart Grid.  IP and the IETF play a significant role in this work.  Here is
a link to the document:
http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf 

Given IEEE 802.15.4 is a popular communications solution for the premise
equipment, 6lowapp plays a key role in realizing this vision.

Don


-----Original Message-----
From: Don Sturek [mailto:[e-mail]] 
Sent: Thursday, September 24, 2009 6:24 AM
To: 'Carsten Bormann'; 'David Ryan'
Cc: '[e-mail]'
Subject: RE: [6lowapp] BOF proposal: update

Hi Carsten,

Just a note on the timelines we are working to for the Smart Energy V2 work
(includes work being done now in ZigBee and also HomePlug):
1)   Specification drafts complete (including details on which standards,
RFCs and I-Ds we use) - December 2009
2)   Interop testing January 2010 - June 2010
3)   Certification testing for first set of platforms/products - July 2010 -
October 2010
4)   Initial products deployed - Summer 2011

A few things to note:
1)  Just as all internet features were not defined in one initial
deployment, the same is true here.   This is the start of deployment.
2)  Not all deployments will look the same.   We are designing to
accommodate the lowest common denominator (IEEE 802.15.4) but we need to
also consider devices with more processing capability and "Ethernet like"
transfer capability.  Whatever we build should enable full HTML/HTTP/XML in
addition to compressed versions (meaning, new encodings need to also make
their way into those standards if they are used)
3)  For those interested, US NIST is publishing their Smart Grid roadmap
(http://www.nist.gov/smartgrid/).  This will give a bit better sense of
where the larger effort is focused.  There is a process now between NIST,
the utilities and the stakeholders listed in the NIST reports to align on
standards choices.  As you can see, IETF plays a major role.
4)  This is an international effort.  ESMIG (http://www.esmig.eu/).
Australia has many smart metering initiatives underway (don't have a link
yet but our next member meeting is in 2 weeks in Melbourne so will update
the group then).

Don



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Carsten Bormann
Sent: Thursday, September 24, 2009 5:36 AM
To: David Ryan
Cc: [e-mail]
Subject: Re: [6lowapp] BOF proposal: update

David,

thanks your for your input.

I'll leave the discussion of Smart Energy timelines to Don for now.
Let me just point out that in other places where we had to work with  
organizations with "impossible" timelines, we were able to do the  
finishing in parallel.  E.g., consider the way ISA100 has now  
published ISA100.11a, while we are in parallel in the process of  
preparing for WGLC of 6lowpan-hc.
For 6lowapp, the organizations making use of our results may not have  
to sit on their hands till Q3/Q4 2010.
And we *do* need some time for that finishing.
(I'm open to suggestions we can be faster than that, but the  
milestones sound right to my gut feeling.)

> Also, it might be fair to add HomePlug to the Smart Energy v2.0 list
> as that group has also
> been involved.

It actually does say on the agenda; we neglected to put that up in the  
charter outline text as well.  Fixed in the current working draft.

>> 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?

Wireless Embedded Internet is a more general term, just as Internet is  
more general than Web (at least if you count the networked  
applications with the networking itself).
The proposal is indeed to use the lessons of the Web to empower the  
Wireless Embedded Internet.
We can work on reducing the number of terms here.

>> 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?

Indeed, this is a little terse.  I think Brian's work is very good  
input.
The point here is that simply compressing HTTP (as in GZIP or  
something slightly better) does not cut it -- if the embedded node  
still has to process all the complexity of HTTP that is a problem.  If  
your definition of "compressing" includes coming up with a simplified  
subset that still solves the important problems, the wording of this  
exclusion may sound wrong.

> 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?

I think the 6lowapp application protocol needs to be format agnostic,  
just as MIME types have made HTTP format agnostic.

Re standardizing another format/encoding:
I have heard a lot of hesitation going into that from individuals  
interested in this work.
The problem is not that there are too few formats.
The issue is what are the right properties of the formats for  
different areas of application.
Yes, some people like EXI in this regard, but it may not be our job to  
choose -- maybe just to elucidate.

> 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.

I still think your draft may be good input to the requirements work  
(the "problem statement and objectives" deliverable).
But we cannot take on standardization (i.e., a fourth deliverable) in  
this crowded space unless we have carved out a very specific set of  
requirements not covered yet. We won't manage that in time before the  
BOF, so it would be a mistake to include such a deliverable in the  
charter.

(And thank you for the kind words on how important that new WG will be  
-- I do agree that this is an important point in time to step forward  
and act.)

Gruesse, Carsten

_______________________________________________
6lowapp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowapp