Re: [6lowapp] BOF proposal: update

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

Hi David,

Thanks for the input on the Australia smart metering programs.

Here is the motivation for the schedule:
1)   Many regulated US utilities have approved rate cases for smart metering
that require deployments now.  For those not familiar with regulated US
utilities, here is the process:
	a.   Utility must file with their public utility commission (PUC)
requesting rate hikes for particular purchasing and services.  If the PUC
approves, the utility bills the customer to raise the requested revenue then
is obligated to deploy the solution
	b.   Many of these requests happened several years ago and resulted
in the Smart Energy V1 solution.  That solution did not gain enough backing
from all utilities to be a standard (or de-facto standard).
      c.   The smart metering deployments, many cases, were to address the
fact that not enough generating capacity was being built.  The recession
helped reduce electric usage but there is a growing gap in what can be
provided versus peak demand.  On average, it is 10 years from start to
commissioning to get a new plant online.  Smart metering is really a MUST
for utilities in this situation (there is a good report from Cap Gemini
outlining this issue)
	d.   Energy self sufficiency (wind power, solar power, plug in
electric vehicles, distributed storage) require deployment of smart meters.
	e.   With the US stimulus, NIST became involved (through the US
Congress) to identify (or enable establishment of) standards for Smart Grid
(hence the report I forwarded)
	f.   Now with the standards targets in place and the schedule
drivers in place, here we are!


>From our perspective (Smart Energy V2), we think there are a few key missing
standards for product deployment in 2011:
1)  Embedded web services.   The proposals on compressed HTTP and Argot are
quite important.   The IEC standards listed in the NIST report are generally
large static data models (in UML).   We are planning to view the data
exchange as XML which should be general enough for use by many additional
higher level services and can be compressed with tokenized XML solutions
(like EXI which would be out of scope for IETF).
2)  Service Discovery.   Need a way for small devices to discover
complementary services available in their surroundings.  I am in the process
of writing something up as an enhancement to SLP (I did find the embedded
SLP but that didn't appear to solve the problem)
3)  Security.  Need security services which work (both in terms of data
exchange and processing) for small footprint devices like those found in the
HAN.  See also the section in the NIST report on Cyber security.  This
"small footprint" security needs to also integrate with IETF security as
deployed in larger systems today.

The above I would list as the immediate needs.  I would expect the solutions
deployed in the future to look quite a bit different as new standards emerge
and are deployed.

Don


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

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