Re: [6lowapp] Proposed charter for 6LoWAPP BOF

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

Hi Carsten,

It would be good to avoid PEPs as much as possible.   These devices are
controversial in cost constrained deployments since they imply a standalone
box someplace (that the customer does not get benefit from functionally) or
some translation which eventually is outdated.

We were hoping to scope a useful, mainstream subset of existing protocols.
This is why we plan to start with HTTP (obviously not a full implementation
but whatever meaningful legal subset we can use) along with a RESTful
message exchange.  At least this is what we are going to start with, in
terms of interoperability testing.

Clearly the story does not stop here.  Ideally we would like to see as many
mainstream services as practical/possible deployed on these small devices
(hopefully without proxy).

Don
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Carsten Bormann
Sent: Friday, October 30, 2009 12:34 AM
To: Jonathan Hui
Cc: Don Sturek; [e-mail]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Jonathan,

I believe we have enough requirements documents.

Application requirements are documented e.g. in the ZigBee/Homeplug  
MRD.  The ROLL documents also contain a lot of information about  
application requirements.  These have been focused on routing  
requirements in their later versions (and a lot of information that is  
useful to us has been removed), but people have already started  
resurrecting the earlier documents and retargeting them for 6lowapp.

Now, application *protocol* requirements. Well, there are general  
technical requirements of constrained nodes/networks; I think we know  
these (both the ROLL documents and the 6LoWPAN documents contain  
some).  I'd say beyond those there are no "requirements" for a  
protocol, unless you have an architecture.  E.g., if you don't know  
whether PEPs (or gateways) are part of the architecture, you don't  
know whether you are designing for 100 % end-to-end usage or for usage  
that can get help from a PEP where required.  That's why  
"requirements" and architecture are one milestone in the charter  
proposal.

I understand that to build a bridge, you first write a requirements  
document (how many cars per hour?), and then design the bridge.  This  
works well because bridges are a lot like each other, so you know what  
questions to ask (in essence, there is a well-known architecture for  
bridges).  That kind of engineering is what engineers are mostly  
taught to do and what "feels right" to many, even though it is often  
not the way successful information/communication technologies work is  
done.  In a design activity like the one we are undertaking,  
requirements (really: objectives) and solutions evolve in parallel.   
That's why it would not only be *slow* to spend a year on requirements  
first, but also be *wrong* fundamentally.

Back to the application requirements: I do agree we should focus on a  
small number of specific areas of application, at least for making  
sure we have thought through some specific examples for each in  
detail.  I think it would be useful if we called them out explicitly  
in the charter.  Right now I'm seeing a lot of interest in 6lowapp  
from Energy (SE V2 etc.) and building automation (which may or may not  
include home automation).  The charter does identify light switches,  
temp sensors, power meters, HVAC systems, and door locks as specific  
items that we will look at; so maybe we should be a bit more specific  
and identify the communication relationships we are addressing (and  
add light fixtures, plug-in vehicles and washing machines in the  
process).

Gruesse, Carsten

PS.: I wrote more on the rationale for trying not to get stuck in a  
requirements mire in
http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html

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