Subject: Re: Intdir early review of draft-ietf-lwig-energy-efficient-07

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Sun, 22 Oct 2017 13:54:01 +0200

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
>
>
>