Dear Bernie, Thank you very much for your detailed review, and for the constructive feedback provided. We have updated the draft (now, -08). This version should hopefully address your comments. Should you have further comments, please let us know. Cheers, Carles ----------------------- The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-energy-efficient/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-08 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-energy-efficient-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-energy-efficient-08 ----------------------- > Reviewer: Bernie Volz > Review result: Ready with Nits > > I am an assigned INT directorate early reviewer for > draft-ietf-lwig-energy-efficient-07. These comments were written primarily > for > the benefit of the Internet Area Directors. > > Document editors and shepherd(s) should treat these comments just like > they > would treat comments from any other IETF contributors and resolve them > along > with any other comments that have been received. For more details on the > INT > Directorate, see http://www.ietf.org/iesg/directorate.html. > > I found the document's information interesting, and it is document that is > benefical to the IETF community in understanding the impact energy savings > techniques (mostly related to radios for wireless communication) can have > on > protocols (both at lower and higher layers). It is going for Informational > status, which I think is appropriate for this document. > > All my comments are fairly minor nits. > > In section 1, "Only few efforts focused on" should likely be "Only few > efforts > have focused on"? (Add have) > > In section 1.1, I think this section can be removed as there are no uses > of the > RFC 2119 keywords. > > In section 2, there are a few technologies listed here that might use > references; some do appear later but not all. It is usually a good > question as > to where references are best added since this is overview material. Those > without any references are ITU-T G.9959 and MS/TP-BACnet. > > Also in Figure 2, it is too bad that some power value for listening (when > not > "actively" expecting a packet) isn't included since there is a claim that > this > can use more energy than transmitting, but it would also be a uJ/<time> > which > is unlike the others. Though perhaps indicating a "listening (for X ms)" > entry > could work? Anyway, not a big issue. > > In section 3, I presume everyone knows what MAC is > (draft-bormann-lwig-7228bis-01 does not define it). Also, might be good to > indicate what RDC is as it is just used (in the MAC and Radio Duty Cycling > section, so pretty obvious likely). > > Also in section 3, "take great care of the problem" is a bit strange > wording. > Perhaps "are at work on the problem"? Or something like that? And, "can > work > perfectly with them" would certainly be great, it may be a stretch of goal > - > "can work well with them" may be better? > > In section 3.2, "contributes to the packet overall delay" should be > "contributes to the packet's overall delay" ('s). > > In section 3.3, "in some services this kind of networks, such as > over-the-air" > could be "for some services, such as over-the-air". I think for is better > than > in and not sure "these kinds of networks" (instead of this kind of > networks) is > really needed? > > Also, in this section, "that can achieved when" should be "that can be > achieved > when". > > In section 3.5.1, "extended sleep modes, traffic filtering" should likely > be > "extended sleep modes, and traffic filtering". (You may or may not prefer > the > last comma in a list, but the "and" should be there). > > And, in this section, in "upper layer protocols knows such capabilities > provided" likely should be "upper layer protocols know such capabilities > are > provided". > > And, in this section, I don't think you need to define (STA) in several > places; > once (first time) should be sufficient? > > And, in this section, "by not forwarding individually addressed frames > addresses to" perhaps this should drop "individually addressed"? But > perhaps > I'm not understanding why it is needed? > > And, "Upper layer protocols would better synchronize" perhaps could be > "Upper > layer protocols would best synchronize"? Or just "Upper layer protocols > should > synchronize"? > > In section 3.5.3, perhaps insert spaces between the 6LoWPAN references to > make > the formatting more flexible? > > And, in this section, should TDMA be defined (again a fairly common term, > but > not in draft-bormann-lwig-7228bis-01. > > In section 3.5.4, I think you would want to use "connectionless" instead > of > "connection less"? > > And, in this section, "data transfer reliability significant" should be > "data > transfer reliability significantly"? > > In section 4, "So they are quite ignorant" it isn't exactly clear what > "they" > are. Replace with "So higher level protocols are quite ignorant"? > > And, "but both the sender and receiver should spend" should likely be "but > both > the sender and receive will spend"? > > In section 6.2, a reference for oneM2M (perhaps to www.onem2m.org) could > be > added? > > In section 9, the "Thank Ted Lemon, Joel Jaeggli, and efforts to initiate > this > facilities" sounds more like notes than actual text? Perhaps something > like > "Thanks to Ted Lemon and Joel Jaeglli for initiating and facilitating this > editing session."? > > In section 12.1, for the EN300 reference, there are double quotes that > probably > aren't needed (single would do)? > > Finally, thanks for writing the document! > > - Bernie Volz > > >