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

Robert Sparks <rjsparks@nostrum.com> Mon, 28 November 2016 20:22 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A3CFF129FBB; Mon, 28 Nov 2016 12:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aJRuKnet0kYQ; Mon, 28 Nov 2016 12:22:28 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 14D8B129FAB; Mon, 28 Nov 2016 12:22:28 -0800 (PST)
Received: from unnumerable.local ([]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uASKMR7A016121 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 28 Nov 2016 14:22:27 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [] claimed to be unnumerable.local
To: General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, 6lo@ietf.org, draft-ietf-6lo-dect-ule.all@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <929a4222-4df3-09ad-5f62-411932f7e30f@nostrum.com>
Date: Mon, 28 Nov 2016 14:22:26 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/mn2wDYIj28os7_QlHK4cDZJZQhQ>
Subject: [Gen-art] Gen-art LC review: draft-ietf-6lo-dect-ule-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2016 20:22:30 -0000

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


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 
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 
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 
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 
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 
Identifier of 0x06 for 6LowPAN. This document defines the behavior of that
Application Protocol".

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

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 
there's a chance that it might fail. Could the sentence be removed (you 
this in 3.2) or be replaced with a more direct statement?

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.

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

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]"?

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, 
than informative.