From nobody Mon Aug 28 21:00:11 2017
Return-Path: <zhencao.ietf@gmail.com>
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 8B6F61321AC; Mon, 28 Aug 2017 20:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4FSdspV3FVRt; Mon, 28 Aug 2017 20:59:50 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 29F541321A0; Mon, 28 Aug 2017 20:59:47 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id q189so6491597vke.4; Mon, 28 Aug 2017 20:59:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8+jZNW0UBMWaemdrpcX1K2qEmPDoGOvQlpIK0DjZAFo=; b=LCpHYeRaNvFs1oXrqS34SeH0YCFhW2EZeckfbhN82pNEyZlCdHSueR7gVDhyqKazNw H2GW4TgF7rDVzyrzXkRLCX9bDl8LTBH6nYhxO2x/qUNkKEcr1Pumqmp9P4EOP22lPPaR Bm87mxAh6OG3Jn+OMB+4UnuOypZX4iHVRol1Qwv1huJQXuhrBsydr7s6R0P53x3/OkqC K8hQQD7fxsmW/uKnRX74CSdToJqpHdSDH+5pw5U7Rs+Nr8G5r1JB9/ojKsNN7PHllA3n PWKy95qst+8+LrDeSXvQlqe9t40yYrRu8T2ZOLm4IXhAYapAATAcYjoLW/U0mL1gQgRj fdIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8+jZNW0UBMWaemdrpcX1K2qEmPDoGOvQlpIK0DjZAFo=; b=LEmGPiGv1eeAupHhvdwXR62jTYYPzkt/2CqcyuOCC1Hzxapt6NgkyE3E4oRY5Vg0xi yRSfqHWlaW60d4vGYkwBExJVSUfgT80xNXpv1OWOA1rRQfJS43YwzYLjcTx3Dp5VAnXS b+9URolL7bWYqp8kQPTqXmgWBE8r3vQGrixHNcKZihX81J4Yqd1dl3VnF3sxKcWK10Mc Bb66HH60G3TE9oTid5BigfpUH41Gj+d7hWIiKeNNcES7wo1a2EFJ65BSR2Z7Eve/q4qe lP+OO2mThVWtuyHL2mH6x620rVR2RIii/3ASi+opmNoUkud8qWUAwofx1GtTVQmyhp8i pX/A==
X-Gm-Message-State: AHYfb5ih4azlTK6V9RuK2MNsQhmD5Rv3QnOFDNoQ62VcvJM3DVFBABQ6 XSps/y7dEIrndhjhol+lZJJU7Pb7fw==
X-Received: by 10.31.134.7 with SMTP id i7mr1676447vkd.76.1503979186182; Mon, 28 Aug 2017 20:59:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.41.161 with HTTP; Mon, 28 Aug 2017 20:59:45 -0700 (PDT)
In-Reply-To: <150094520677.26176.17525876529879529582@ietfa.amsl.com>
References: <150094520677.26176.17525876529879529582@ietfa.amsl.com>
From: Zhen Cao <zhencao.ietf@gmail.com>
Date: Tue, 29 Aug 2017 11:59:45 +0800
Message-ID: <CAFxP68z-+dfGipj9xFGMJHCk+km+i3iocK+tGD0BF-TVv6nD9w@mail.gmail.com>
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
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/nxeJlNth5Ha4rqPQo_WHFT6UqGo>
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: Tue, 29 Aug 2017 03:59:52 -0000

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@cisco.com> 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
>
>