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:[email protected]] On Behalf Of Hannes Tschofenig > Sent: Thursday, July 03, 2014 4:35 PM > To: [email protected] > 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 _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
