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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bernie, Thank you so much for the review, and the valuable comments
for us to improve the draft.

We will come up with wording proposals shortly.

Many thanks,
Zhen

On Tue, Jul 25, 2017 at 9:13 AM, Bernie Volz <volz@xxxxxxxxx> wrote:
> 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
>
>




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]