Re: [6lowapp] BOF proposal: update

[David Ryan <[e-mail]>]

Hi Don,

Thanks for providing the details on the Smart Energy V2 work.  I had
seen these dates but did
not feel I had adequate authority to publish them here.  Obviously the
timeline looks
compressed when viewed with the Smart Energy decisions. ie BoF I-D by
2009-10-19, the BOF in
November and decisions on which standards are used in December.  It's
important people
are aware of this when preparing to submit I-Ds on this list.

In regards to Australia, information on the national program can be found at:
http://www.aemo.com.au/electricityops/smartmeter.html

Also, Melbourne (where the next ZigBee meeting is being held) has programs
already started with companies gearing up to roll out smart meters
now.  The HAN is
an important part of the Australian programs with requirements to use
ZigBee Smart Energy Profile.

Regards,
David.

On Thu, Sep 24, 2009 at 11:23 PM, Don Sturek <[e-mail]> wrote:
> 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
>
>