Re: [Lwip] The LWIG Challenge

["Cao, Zhen \(CZ\)" <[e-mail]>]

Hi Hannes, 

Thanks a lot for the inputs. I agree with part your options, but not all. 	

The lwig started to work on a general document about lightweight implementation guidance, trying to cover all the topics including 6lowpan/coap/rpl/security. It turned out that the document could not be finished in a timely manner. So the group decided that first of all to work on a terminology document. This document turns to be a hub when people started to think about problems in the constrained network. 

The cellular document was indeed a memo when the authors started to work on communication protocols, the document is very useful for readers and implementers when they approach the problems. The energy efficient document that I was editing is probably too general, that's also my feeling when I was working on it. Trying to find a new way out...

For the Nordic nRF51822-mKIT and things alike, yes, I agree with you that the information about the details of configuration is really useful for the developers but I doubt we doing that in ietf. But how to generalize the problems into the IETF language is a challenge. 

Finally I would like to propose some work items for your consideration and discussion,
- Requirement document for constrained devices (sensors and gateway nodes) w.r.t. the IP layer functionalities. 
- A survey document of constrained device developers (some do that for IPv6), link layer, battery life, applications profiles and etc. 

I believe these documents will have more helpful information for developers and designers. 

Thanks for your input again.

With best regards,
zhen


> -----Original Message-----
> From: Lwip [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, July 03, 2014 4:35 PM
> To: [e-mail]
> Subject: [Lwip] The LWIG Challenge
> 
> Hi all,
> 
> I have read draft-ietf-lwig-cellular-01, draft-ietf-lwig-energy-efficient-00, and I
> have worked on the TLS document myself.
> 
> There is a common problem among all these documents: they are confusing
> because they have no clear reference point and some of the relevant and
> interesting content is not typically part of the IETF work (such as implementation,
> and hardware).
> 
> Covering the topic in a generic fashion just does not work.
> 
> What can be done to provide some useful input to the reader?
> 
> I believe at least one thing could be done is to focus on selected, well-known
> design patterns. What do I mean by that? Take a look at the DTLS profile
> document in DICE (see
> http://tools.ietf.org/html/draft-ietf-dice-profile-01#section-3) or at my
> presentation at the ACE interim meeting.
> 
> I picked one (only one) communication pattern and explained the assumptions.
> Then, from there you can give very specific advice about what to do.
> 
> Of course, energy efficiency of network communication is only one small item
> developers will care about and energy efficiency is a particularly hard topic since
> most of the relevant aspects are outside the scope of the IETF. The IETF draft
> format is probably not the right tool to convey that information either.
> 
> Just to give you an idea what practical help with regard to energy efficiency I
> would be looking for.
> 
> I have a Nordic nRF51822-mKIT board
> http://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-ene
> rgy/nRF51822-mKIT/(language)/eng-GB
> 
> What parameter settings could I pick (that have impact on energy
> consumption) using mbed (which provides the OS and the protocol stack) for a
> few common Bluetooth Smart deployment scenarios / communication patterns?
> 
> This is obviously nothing you would put in an IETF draft but I fear that this is the
> type of info people care about.
> 
> Ciao
> Hannes