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

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

Hi Cullen,

I don't have a lot to add to what you wrote below except on the question of
what other application protocols to suggest:
1)  We (the Smart Energy team) would like to use something that is
mainstream and extensible.  We could resort to a proprietary binary protocol
to address our near term needs but it would be a shame to do this
2)  We would like to start with assumption we can use a simplified version
of RESTfull HTTP with the following backup plans:		
      a.  Providing some alternative to TCP if we find we cannot use that
due to code size or performance on wireless mesh links (see my earlier note)
	b.  Providing some backup to HTTP text if we find the number of
packets generated causes congestion/throughput issues.

We welcome other suggestions like XMPP and SIP but we did look at those and
ruled them out for reasons like:
1)  Verboseness (using text string exchanges for devices with very small
transmit/receive packet sizes)
2)  Session management overhead

Don



-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]] 
Sent: Saturday, October 31, 2009 10:30 AM
To: Don Sturek
Cc: [e-mail]; Zach Shelby; Carsten Bormann; Lisa Dusseault
Subject: Re: Proposed charter for 6LoWAPP BOF


On Oct 29, 2009, at 8:37 , Don Sturek wrote:

> Hi Cullen,
>
> Overall, the proposed charter looks interesting.
>
> On the Commissioning methods, I think making the "Duckling" mode  
> mandatory as indicated in the text below should not be decided in  
> the charter.

Fair enough. Let me start a separate thread on this.

>  Unless this commissioning method has undergone some form of  
> security review, it could well be something we (at least in Smart  
> Energy) cannot use.

Agree, but even worse. The IETF is not going to publish any of this as  
an RFC until it has had reasonable security review so I certainly  
don't want anything that would be a significant innovation in security  
or is broken from a security point of view.

> It would be a shame to waste code space for something like this.
>
> While we (again Smart Energy) are looking at a RESTfull HTTP  
> architecture, it would be good to point out that this is only one  
> option.  It would be nice to see if other popular communication  
> solutions can work as well.

Yep - several other people have told me this too. What other popular  
protocols should we consider?

>
> One more thng:   The discussion below indicates two level of  
> communication:   PEPs and CoAps.   I would hope we could avoid  
> this.  It would be nice to address and communicate with CoAp devices  
> as you would with any other device on the internet whether a PEP was  
> present or not.  I would not want to have the group focused on this  
> type of gateway approach.

Agree - I was trying to make it clear any computer on the internet  
could talk CoAp directly to Device but failed to express that. Could  
you suggest some text to make that clear?

>
> Overall though this was a good start for the charter.
>
> Don
>