RE: Gen-art LC review: draft-ietf-6lo-dect-ule-08

Jens Toftgaard Petersen <jtp@rtx.dk> Thu, 15 December 2016 22:04 UTC

Return-Path: <jtp@rtx.dk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8812946E; Thu, 15 Dec 2016 14:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rtx1.onmicrosoft.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 F8avwuF9lwG1; Thu, 15 Dec 2016 14:04:50 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0079.outbound.protection.outlook.com [104.47.2.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E335A1294F4; Thu, 15 Dec 2016 14:04:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RTX1.onmicrosoft.com; s=selector1-rtx-dk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QYCHhUSK5ciJwKVe++IjvhqSa/tX7EyH2KOR26h/ut0=; b=XqT0XsbZd0uFTCTatm/BZHsGqfrdK00+2VlCyHw5eUyXTm60VnjnarTKWb49nYeF6p4Ecrfx5ZSJGPBdEplGabCcz7QvP6UYcsR3Es0Qkj1xaxO3497lcNFj3FUt5htF2MQ4NYlmpFWbdlXh+/J35eBZumiIUiarrLVnm1Qu60A=
Received: from AM5PR0401MB2595.eurprd04.prod.outlook.com (10.169.245.22) by AM5PR0401MB2594.eurprd04.prod.outlook.com (10.169.245.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Thu, 15 Dec 2016 22:04:45 +0000
Received: from AM5PR0401MB2595.eurprd04.prod.outlook.com ([10.169.245.22]) by AM5PR0401MB2595.eurprd04.prod.outlook.com ([10.169.245.22]) with mapi id 15.01.0771.014; Thu, 15 Dec 2016 22:04:45 +0000
From: Jens Toftgaard Petersen <jtp@rtx.dk>
To: Robert Sparks <rjsparks@nostrum.com>, General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-dect-ule.all@ietf.org" <draft-ietf-6lo-dect-ule.all@ietf.org>
Subject: RE: Gen-art LC review: draft-ietf-6lo-dect-ule-08
Thread-Topic: Gen-art LC review: draft-ietf-6lo-dect-ule-08
Thread-Index: AQHSSbUooaeL9oG4FkuKHK+j6xAmhqEJFb3A
Date: Thu, 15 Dec 2016 22:04:45 +0000
Message-ID: <AM5PR0401MB25957F66CB2DA4EA6C2E5218CB9D0@AM5PR0401MB2595.eurprd04.prod.outlook.com>
References: <929a4222-4df3-09ad-5f62-411932f7e30f@nostrum.com>
In-Reply-To: <929a4222-4df3-09ad-5f62-411932f7e30f@nostrum.com>
Accept-Language: da-DK, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jtp@rtx.dk;
x-originating-ip: [77.68.246.85]
x-ms-office365-filtering-correlation-id: 35735265-61c0-4003-108e-08d425366149
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0401MB2594;
x-microsoft-exchange-diagnostics: 1; AM5PR0401MB2594; 7:WVG/eYpZaZk0Qy5ml3L8pkZIMG0RQ4zbkLSRcEPKtVgDiPpL6oQYZ5/av4GK80M+WQ3KbkV7NsnLYfkeZSmDsnk4xKeiTx2nobENL/iA9gUsjyCobm09i3IXqAwOfA6AOgjW/wX0Es3C3XW6MWQttKCHjZUQnQiqs60Lb3KU+ufQXCwOIa9B8bZI0hMljte8CIq4B/281A7vKpF5rsJBDw0SORorlHHsf+PradXb7Zmx9rsXpzfn1aEWoxxaTogRvaq4XkOSM1u0Z2Kj7RYoY7CrN7jll4szrvlA3LoMSdEY7FI+zKQ+pFYb3Oq2HxwkKBdQzeTEvZfHrQPLjUg5hm/kpGmoyX8ckyFtS2wnSMV2ZktdRYoVhhk4wKHsetYQVIZUUMunlmP/N0w5QiOvX25G3Q9UOVQRU066Zll/FI9bNh0YEYi5qUyUaH4drzKiIBnodSqMJ95dtFqD6pqSyg==
x-microsoft-antispam-prvs: <AM5PR0401MB25940CBE49CA3929D6E288C5CB9D0@AM5PR0401MB2594.eurprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(6047074); SRVR:AM5PR0401MB2594; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0401MB2594;
x-forefront-prvs: 0157DEB61B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39450400003)(199003)(66654002)(189002)(13464003)(38730400001)(77096006)(5660300001)(76576001)(106356001)(229853002)(76176999)(74482002)(122556002)(68736007)(66066001)(2501003)(6506006)(25786008)(50986999)(2950100002)(54356999)(106116001)(92566002)(101416001)(9686002)(81166006)(33656002)(81156014)(8936002)(7736002)(3660700001)(2900100001)(7696004)(2906002)(8676002)(74316002)(3846002)(102836003)(6436002)(5001770100001)(305945005)(2201001)(6116002)(86362001)(189998001)(107886002)(97736004)(3280700002)(105586002)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0401MB2594; H:AM5PR0401MB2595.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: rtx.dk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rtx.dk
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 22:04:45.5691 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9a968248-e61d-46fd-b8d1-5c62247712e5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0401MB2594
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9onMt8GaUvLg_30RLrbp6isS-sM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 22:04:53 -0000

Hi Robert,

Many thanks for your review. See my comments and answers inline below.

Best regards,
  Jens

-----Original Message-----
From: Robert Sparks [mailto:rjsparks@nostrum.com] 
Sent: 28. november 2016 21:22
To: General Area Review Team <gen-art@ietf.org>rg>; ietf@ietf.org; 6lo@ietf.org; draft-ietf-6lo-dect-ule.all@ietf.org
Subject: Gen-art LC review: draft-ietf-6lo-dect-ule-08

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-6lo-dect-ule-08
Reviewer: Robert Sparks
Review Date: 28 Nov 2016
IETF LC End Date: 02 Dec 2016
IESG Telechat date: 15 Dec 2016

Summary: Ready with nits

Nits/editorial comments:

First, forgive me, but I need to grumble a little bit:

The way this document approaches standardization makes me very uncomfortable.
The language is passive and relies on inference to the point that it risks being vague. If this review were earlier in the document's life-cycle, I would strongly suggest a complete restructure focusing on explicitly specifying what the implementation is supposed to do.

But, the document has had several reviewers who didn't trip up on this point, and the working group believes it is implementable, so I'm going to set that aside and provide some concrete suggestions for removing some nits from the existing text.

In document order:

1) In section 2.1 "This draft defines 6LoPAN as one of the possible protocols to negotiate". That's not what this draft appears to do. Rather, it defines behavior once this 6LoPAN over DECT ULE has been negotiated. Some other document is defining the negotiation. I suggest replacing the sentence with "[TS102.939-1] defines this negotiation and specifies an Application Protocol Identifier of 0x06 for 6LowPAN. This document defines the behavior of that Application Protocol".

[Jens]: Very good comment and suggested wording. Is implemented in revision -09

2) The "not recommended" in the last sentence of 2.3 looks like it should be a
2119 keyword (NOT RECOMMENDED). Similarly, the "shall" in the last sentence of the first paragraph of 2.4 looks like it should be a SHALL (consider using MUST instead).

[Jens]: I agree. Is implemented in revision -09

3) At the mention of LOWPAN_IPHC in the second paragraph of 2.4, consider referencing RFC6282. It's not clear what the sentence is really trying to convey, though. "all the requirements" is very vague - can you point to a specific requirement list somewhere? "It is expected" implies that you believe there's a chance that it might fail. Could the sentence be removed (you cover this in 3.2) or be replaced with a more direct statement?

[Jens]: Agreed, is covered in section 3.2. Will be removed in revision -09

4) In the first section of 3.1 you have "The PP MUST be pageable".
Interestingly, the word "pageable" does not yet appear anywhere in the RFC series. Please add a reference into the ETSI docs that will lead the reader to a definition.

[Jens]: I don't think we have definition of the term we can refer to. Will change to an explanatory wording in revision -09.

5) In the last paragraph of 3.2 (before 3.2.1), third sentence, you introduce using the multi-link subnet approach. Please either add a reference to
RFC4903
here, or point forward to section 3.3.

[Jens]: A reference to RF4903 added in revision -09

6) In section 3.2.1, third paragraph, you say addresses are derived "similar to the guidance of [RFC4291]. I don't believe that is sufficient. Perhaps you should say "following the guidance in Appendix A of [RFC4291]"?

[Jens]: Yes, your suggestion is more accurate. Will be done revision -09.

7) The last paragraph of 3.3 says "The FPs operation role in such scenario are rather like Backbone Routers (6BBR) than 6LBR, as per [I-D.ietf-6lo-backbone-router]." Is this trying to _specify_ the behavior of the FP in this scenario? If not, it's unclear what the sentence is trying to accomplish. If so, then the sentence should be "The FPs in such a scenario behave as Backbone Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]." And that reference should be normative, rather than informative.

[Jens]: I agree the wording is bit vague, but I believe we cannot refer to work in progress [I-D.ietf-6lo-backbone-router] in a normative way. I will tightening the wording revision -09