Re: [Int-dir] Intdir early review of draft-ietf-lwig-energy-efficient-07

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Sun, 22 October 2017 11:54 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCBE1386DE; Sun, 22 Oct 2017 04:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eje-pAy4roE0; Sun, 22 Oct 2017 04:54:14 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D794138601; Sun, 22 Oct 2017 04:54:10 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v9MBs5FB046601; Sun, 22 Oct 2017 13:54:05 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 204981D53C1; Sun, 22 Oct 2017 13:54:04 +0200 (CEST)
Received: from 83.37.37.84 by webmail.entel.upc.edu with HTTP; Sun, 22 Oct 2017 13:54:01 +0200
Message-ID: <5a9c8563ee1e18ef36e3011da8d5f464.squirrel@webmail.entel.upc.edu>
In-Reply-To: <150094520677.26176.17525876529879529582@ietfa.amsl.com>
References: <150094520677.26176.17525876529879529582@ietfa.amsl.com>
Date: Sun, 22 Oct 2017 13:54:01 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Bernie Volz <volz@cisco.com>
Cc: int-dir@ietf.org, lwip@ietf.org, ietf@ietf.org, draft-ietf-lwig-energy-efficient.all@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.99.2 at dash
X-Virus-Status: Clean
X-Greylist: Delayed for 68:06:58 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sun, 22 Oct 2017 13:54:05 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/0375rIyZr0kRUVMXZ-vfSsLvEhw>
Subject: Re: [Int-dir] Intdir early review of draft-ietf-lwig-energy-efficient-07
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Oct 2017 11:54:17 -0000

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