Subject: [6lowapp] BOF Status

From: Carsten Bormann <[email-masked]>
Date: Mon, 14 Sep 2009 23:45:02 +0200

Just in case some of you have seen the "Important dates" for IETF76 (http://www.ietf.org/meeting/cutoff-dates.html 
), you may wonder what's going on with today's BOF approval deadline.

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart
has the explanation:

> Sept 14 is listed as the date ADs approve BOF requests, but that is  
> in conflict with the day we actually have scheduled discussion  
> preceding approval -- that is Sept 25.

["we" = the area directors, who are maintaining that Wiki page.]

There will be some off-list discussions (between ADs and proposed BOF  
chairs) in preparation for that date this week; Zach and I will keep  
you up to date.

In preparation for that:
If any of you have drafts in the pipeline and can already talk about  
your plans of submitting them, please do that now!

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Sep 2009 09:39:02 +0200

We used the last week to discuss the BOF proposal with our responsible
AD and with people from other standards groups.

The result is a revised BOF proposal, that already provides an outline
for the charter of the new WG.  This charter now defines a more
specific focus for the WG til the end of 2010.  I think that is good
because the IETF is much better in handling focused, specific work
items than in grand, boil-the-ocean efforts.  If we succeed, we can
always recharter to attack additional items.

A bit more background: The goal of this BOF proposal is to get a BOF
going in Hiroshima, the week of Nov 9.  The goal of the BOF is to
demonstrate that we have enough interest ("energy") and enough focus
to solve a credible problem in a defined amount of time; this will
enable us to charter a WG following the BOF.  Not all of you will be
physically present in Hiroshima; that's another reason why it is
important to hear your opinions on this mailing list.  The charter
proposal can and will change until Hiroshima, and now is the time to
influence it and to express your support.  Also, the IETF is generally
driven by Internet-Draft documents, so it would be good to hear on the
list what you will be able to contribute.

I'm looking forward to your feedback.

Gruesse, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Sep 2009 09:59:30 +0200

> I'm looking forward to your feedback.

I doubt you can leave out security.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 24 Sep 2009 10:24:15 +0200

> I doubt you can leave out security.

Probably the charter should be clearer that what's out of scope is a
generic security framework for embedded devices; I certainly don't
expect documents produced by the proposed WG to have empty Security
Considerations sections (I don't thing that is the intention though).

-- 
Ciao,
Enrico

---

From: Zach Shelby <[email-masked]>
Date: Thu, 24 Sep 2009 11:28:19 +0300

> Considerations sections (I don't thing that is the intention though).

Exactly. The security considerations for both work items should be of 
course integral parts of the WG goals. And as you say, we are not 
working on a generic security framework. Under the "what we do not work 
on" section we should add some text about that. Plus in the work items 
we should be specific that security is a part of each item.

Thanks,
Zach

> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 24 Sep 2009 11:28:17 +0200

Carsten Bormann wrote:
> 20 min  6lowapp WG charter proposal                   Zach
> 30 min  Contributions so far                          TBC
>         Several drafts are in the pipeline for submission before the
>         Hiroshima initial I-D deadline, 2009-10-19.  It would be
>         premature to make an exact list, but subjects will include:
>         -- Requirements input (Building automation, Smart energy;
>             ZigBee/HomePlug TRD)
>         -- Input from relevant large projects (e.g., SENSEI)
>         -- Solutions based on existing standards (EXI, IPFIX, SLP)
>         -- Solutions based on industry protocols
> 30 min  Open Discussion                               All

I'd suggest to swap "charter proposal" and "contributions", as I guess
the BoF will be more productive if the discussion focuses on the former
rather than the latter.

-- 
Ciao,
Enrico

---

From: David Ryan <[email-masked]>
Date: Thu, 24 Sep 2009 21:43:36 +1000

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Sep 2009 14:36:12 +0200

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

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.

> discuss the "embedded web" and "web for resource constrained devices".

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.

> that the draft submitted by Brian Frank (Chopan) is outside the scope

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.

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

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

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 24 Sep 2009 06:23:30 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: Thursday, September 24, 2009 5:36 AM
To: David Ryan
Cc: [email-masked]
Subject: Re: [6lowapp] BOF proposal: update

David,

Gruesse, Carsten

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 24 Sep 2009 06:33:57 -0700

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:[email-masked]] 
Sent: Thursday, September 24, 2009 6:24 AM
To: 'Carsten Bormann'; 'David Ryan'
Cc: [email-masked]'
Subject: RE: [6lowapp] BOF proposal: update

Hi Carsten,

A few things to note:

Don

-----Original Message-----

David,

Gruesse, Carsten

---

From: David Ryan <[email-masked]>
Date: Thu, 24 Sep 2009 23:59:59 +1000

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.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 24 Sep 2009 07:23:13 -0700

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:[email-masked]] 
Sent: Thursday, September 24, 2009 7:00 AM
To: [email-masked]
Cc: Carsten Bormann; [email-masked]
Subject: Re: [6lowapp] BOF proposal: update

Hi Don,

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

Regards,
David.

---

From: Brian Frank <[email-masked]>
Date: Mon, 28 Sep 2009 14:04:18 -0400

Couple of my thoughts to echo what some others have said:
- I believe the application protocol should be format agnostic.  I suspect
that it will be difficult to achieve consensus on data formats. I am not
sure how that might limit the scope of 6lowapp, but certainly I hope that a
debate on formats doesn't derail the transport protocol itself

- I personally believe that naming should be based on URIs; however it seems
as this is already presumed as a requirement?

- just to echo what David said, I read the BOF to say that adaption of HTTP
(as proposed by myself) is off the table.  But I think the intent was just
that we must define some subset of REST functionality can be implemented
efficiently?

- sleeping nodes are mentioned a couple times already, but I'd just like to
re-iterate that I believe sleeping nodes are perhaps the most important
problem space for 6lowapp (or least a peer to the problem space of
computing/memory/bandwidth constraints)

Brian

---

From: Sam Roberts <[email-masked]>
Date: Mon, 28 Sep 2009 12:28:48 -0700

> debate on formats doesn't derail the transport protocol itself

I share the hope that format discussions won't bog things down.

Perhaps I misunderstand what you mean by "format agnostic", won't
non-specification of such an important aspect prevent independantly
developed implementations of the protocol from interoperating?

> as this is already presumed as a requirement?

Have I missed discussion of this, or has rehosting the zigbee
application support layer and cluster library on top of IPv6 over
802.15.4 already been discussed and/or discarded as a possibility?

A profile supporting RESTful URI based request/response could exit at
a zigbee endpoint.

Cheers,
Sam

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 28 Sep 2009 13:32:00 -0700

Hi Sam,

The plan in ZigBee Smart Energy V2 is not to rehost the current ZigBee Smart
Energy application messaging overtop the IP stack.  Work is currently
underway to extend the IEC TC57 CIM for the Smart Energy V2 use cases.  The
CIM is a static data model using UML.

The message exchange will be defined as XML (probably) or possibly ASN.1 (at
least, some standard self describing protocol).  Since we have very small
packet sizes using IEEE 802.15.4, we need to use some standard encoding
method (like tokenized XML method, which I think is out of scope of IETF)
and some efficient embedded web services delivery (which I think should be
in scope for IETF).   We also need a service discovery method which aligns
with the use of the encoding method we use (XML or ASN.1 or ??).

I agree with the statement that the 6LowAPP application protocol should be
format agnostic.  It would be good to see that various encodings are
supported and that the XML encoding/embedded web services/binary service
discovery defined by 6LowAPP could be transparently used in conjunction with
full XML (or other self describing protocol)/current web services
protocols/full XML based service discovery for those devices holding the
schema and willing to expand/compress for communication with small footprint
devices.

I think we have most of the communications layers defined to support this,
now needing the application support.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sam Roberts
Sent: Monday, September 28, 2009 12:29 PM
To: [email-masked]
Subject: Re: [6lowapp] BOF proposal: update

Cheers,
Sam

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Sep 2009 23:42:22 +0200

Brian,

Brian Frank wrote:
> - I believe the application protocol should be format agnostic.  I 
> suspect that it will be difficult to achieve consensus on data formats. 
> I am not sure how that might limit the scope of 6lowapp, but certainly I 
> hope that a debate on formats doesn't derail the transport protocol itself

I totally agree, and this is one important thing we try to make clear in 
the charter. The application protocol must support common MIME types and 
encodings, and be easily extensible. For example, your proposal in 
Section 2.5 of draft-frank-6lowapp-chopan-00 is one very good way of 
doing it.

> - I personally believe that naming should be based on URIs; however it 
> seems as this is already presumed as a requirement? 

Yes, definitely. As URIs are string based and often quite long, we 
should also figure out a way to compress them as well.

> - just to echo what David said, I read the BOF to say that adaption of 
> HTTP (as proposed by myself) is off the table.  But I think the intent 
> was just that we must define some subset of REST functionality can be 
> implemented efficiently?

Exactly! Just drop the word HTTP from draft-frank-6lowapp-chopan-00 and 
that is a good start. The core REST functionality is exactly what we 
need to enable the embedded web.

> 
> - sleeping nodes are mentioned a couple times already, but I'd just like 
> to re-iterate that I believe sleeping nodes are perhaps the most 
> important problem space for 6lowapp (or least a peer to the problem 
> space of computing/memory/bandwidth constraints)

Yes. One other thing we need to mention is that peer-to-peer 
interactions between nodes is also important. A client-server only 
approach won't do here. In building automation P2P is a big MUST. There 
is a building automation requirements ID being written right now - which 
will surely point that out well.

- Zach

> Brian
> 
> 
> On Thu, Sep 24, 2009 at 3:39 AM, Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Sep 2009 23:55:54 +0200

Hi,

> developed implementations of the protocol from interoperating?

By format agnostic, we only mean that the protocol must have a content 
type/encoding identifier. The same philosophy is used by HTTP. Here our 
challenge is to represent that with 1-2 bytes. Once you have that, 
application developers may use any kind of content-type over this 
protocol, including e.g. text/xml, text/plain, rdf+xml, 
application/octet-stream using any content-encoding such as x-exi.

> 802.15.4 already been discussed and/or discarded as a possibility?

The current indication from ZigBee/IP and Smart Energy is that they will 
use a web based approach. The ZigBee application layer is not being used 
in Smart Energy 2.0 at all, which is currently the only profile being 
developed for "ZigBee/IP". I would say this is something we should 
consider in the future (a later re-chartering) if we see there is a need 
  from the other organizations involved. For this charter the goal is to 
stick to the most urgent tasks.

> A profile supporting RESTful URI based request/response could exit at

Sure, I think you could definitely make them interact, and this would be 
an interesting draft!

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Sep 2009 23:58:53 +0200

Don,

> with the use of the encoding method we use (XML or ASN.1 or ??).

These are all covered by existing MIME content-types and standard 
content-encodings. In 6lowapp we just need to be sure to support a large 
enough range of these for current and future use.

> schema and willing to expand/compress for communication with small footprint

This is a definite must.

> seems

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND