[Gen-art] Genart last call review of draft-ietf-roll-unaware-leaves-24

Elwyn Davies via Datatracker <noreply@ietf.org> Sun, 13 December 2020 23:23 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B54E3A0D3C; Sun, 13 Dec 2020 15:23:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Elwyn Davies via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: roll@ietf.org, draft-ietf-roll-unaware-leaves.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160790180911.7304.3594336463513549756@ietfa.amsl.com>
Reply-To: Elwyn Davies <elwynd@dial.pipex.com>
Date: Sun, 13 Dec 2020 15:23:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/k67alirECTNeefgEKului2pIBcs>
Subject: [Gen-art] Genart last call review of draft-ietf-roll-unaware-leaves-24
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 13 Dec 2020 23:23:34 -0000

Reviewer: Elwyn Davies
Review result: Almost Ready

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-roll-unaware-leaves-24
Reviewer: Elwyn Davies
Review Date: 2020-12-13
IETF LC End Date: 2020-12-09
IESG Telechat date: 2020-12-17

Summary:  The document is almost ready for publication.  As mentioned elsewhere
in reviews it is a very dense document requesting updates of several standards
and as such it is a difficult read and I would not be totally sure that
everything is consistent.  However, I did find s9 and s10 to be pretty clear. 
There are a few minor issues that need resolving IMO.
 Most are trivial  but the connection to EFFICIENT-NPDAO needs fixing - both
 these documents are in draft and specifying alterations or updates to a
 document still in draft doesn't seem sensible.  Apologies for rather late
 delivery of this review - it took longer than expected.

Major issues:

Minor issues:
s6.1, para 2: I found this paragraph difficult to parse. I note also that
nowhere in the document is the implementor told to set the F flag to 1 (there
is one place in s9.2.2 where it has to be forced to 0).  Presumably there
should be an instruction somewhere in s9.2.1 that there should be a Target
Option with the F flag set. I would suggest alternative text for this para as
follows: OLD: The new 'F' flag is set to 1 to indicate that the Target Prefix
field contains the IPv6 address of the advertising node, in which case the
length of the Target Prefix field is 128 bits regardless of the value of the
Prefix Length field. If the 'F' flag is set to 0, the Target Prefix field MUST
be aligned to the next byte boundary after the size (expressed in bits)
indicated by the Prefix Length field. Padding bits are reserved and set to 0
per section 6.7.7 of [RFC6550]. NEW: The added 'F' flag is set to 1 to indicate
that the Target Prefix field contains the IPv6 address of the advertising node
and will, accordingly,
 have the Prefix Length set to 128. The length of the Target Prefix
field will be an integral number of octets, TPL, which is the smallest
integer such that (TPL * 8) is greater than or equal to Prefix Length.
The Target Prefix is left (high bit) justified in the field and any
additional bits in the rightmost octet will be filled with padding bits.
Padding bits are reserved and set to 0 as specified in section 6.7.7 of

s6.2, position of P flag: As a matter of interest why is the flag in position 1
and not position 0 or 4?  It might be more helpful in the event of further
additional functionality being added to have 3 spare bits together if the
position is of no consequence.

s6.3, next to last para. s8 and s 12.2:  In view of the statement in s6.3:
The RPL Root MUST set the 'E' flag to 1 for all rejection and unknown status
codes. The status codes in the 1-10 range [RFC8505] are all considered
rejections. I think that IANA should be requested to add a column to the EARO
status codes registry being modified by s12.2 to add a column that identifies a
status code as a rejection or otherwise.   Some words in s8 may be appropriate.

s7:  Given that [EFFICIENT-NPDAO] is still a draft,  I think this section
should be synchronized with the  draft so that we don't end up with one or the
other new RFC updating an RFC that doesn't yet exist.

s14: Idnits notes that there is a normative reference to RFC 7102 which is
informational.  I note that this was not mentioned in the Last Call. However
RFC 7102 has already had one accepted Downref waiver and the summary of terms
is a suitable use case.

Nits/editorial comments:

General: s/byte/octet/g

Abstract:  Expand RPL on first use (currently done in s1.) Expand ND.

Abstract:  Idnits produces a spurious warning about RFC 8505...

-- The draft header indicates that this document updates RFC8505, but the
abstract doesn't seem to directly say this. It does mention RFC8505 though, so
this could be OK.

The abstract says

This specification updates RFC6550, RFC6775, and RFC8505,

which is fine by me.  I will report this to the  Tools team.

s1, s2.2, s2.3: The term defined in [USEofRPLinfo] is RPL-Unaware-Leaf rather
than RPL-Unaware Leaf: s/RPL-Unaware Leaf/RPL-Unaware Leaf/ (3 places). 
Similarly s/RPL-Aware Leaf/RPL-Aware-Leaf/ (1 place) and s/RPL-Aware
Node/RPL-Aware-node/ (2 places).

s2.3, para 3:
> The term RPL-Aware Node (RAN) is introduced to refer to a node that is either
an RAL or a RPL Router. This term is already defined in [USEofRPLinfo] with,  I
understand, the same meaning. s3, para 1: s/detailed/summarized/ - the formal
details are in [USEofRPLinfo].

s3, para 3: Add MOP to glossary.

s3. para 4: s/to transport a RPL Packet Information (RPI) [RFC6550]./to
transport the RPL Packet Information (RPI) [RFC6550]option./

s3, para 4: '... except for the very special case above,' - I am not totally
sure what part of the section is being referred to by this.  Do you mean the
case referred to in the  previous sentence?  Please make this clearer.

s3, para 5: The jargon term 'going down' is used here without definition.  It
is sort of inherited from [USEofRPLinfo] (Section 8.3.1) but is not properly
defined there either.  Please improve and explain this jargon.

s3, para 5:  Might be sensible to add SRH to the glossary instead of expanding

s3, last para: s/forwarding/forwarding it/

s4.1, para 3: It would be helpful to add 6LBR to the glossary.

s4.2.2: s/ (more in Section 5.1)/; this requirement is fully explained in
Section 5.1/

s4.2.3. title: Suggest expanding the acronym.

s4.2.3, para 2: s/The use of ROVR field enable/The use of the ROVR field

s4.3, para 1: s/8.2.6/Section 8.2.6/

s4.3, para 1: To avoid any future inconsistency the notional value of
RETRANS_TIMER should not be mentioned here: s/a duration longer than the 
RETRANS_TIMER [RFC4861] of 1 second /a duration longer than the default value
of the RetransTimer (RETRANS_TIMER) [RFC4861] /

s4.3, para1:  I would suggest using the conventional term: s/Turn Around Trip
delay/round trip delay/

s4.3, last para: Suggest adding a forward ref to s9.1 for Figure 7.

s4.3.1. last para: s/and set the/and sets the/

s4.3.1, last para: s/, more in Section 9.2./; this is fully explained in
Section 9.2./

s5, title:  s/RPL-Unware Leaf/RPL-Unware-Leaf/

s5, para 1: A document cannot provide anything! s/This document provides RPL
routing for a RUL./This document describes how RPL routing can be extended to a

s5.3, title:  Expand HbH - it isn't used anywhere else.

s6: s/more in/see/ (5 places)

s6.1, Flags specification: s/4 bits/3 bits/

s6.2, title and para 2: s/New Flag/Additional Flag/ (with appropriate

s6.3, para 2:
This specification enables to carry the 6LoWPAN ND Status values in RPL DAO and
DCO messages, NEW: This specification adds a capability to allow the carriage
of 6LoWPAN ND Status values in RPL DAO and DCO messages, ENDS

s9: A pointer back to s4.3 might be useful regarding the proxy operation.

s9.2:  By convention, there should be a brief description of the purpose and
subsections before starting s9.2.1.  The RFC Editor doesn't like empty sections

s9.2.1, para after item 6: s/else it MUST leave the Opaque field to
zero./otherwise it MUST leave the Opaque field as zero.

s9.2., para 4: s/mean/means/

s9.2.2, para after Figure 9: s/that it stops providing/that it is ceasing to
provide/; s/that it stops serving/that it is ceasing to serve/

s9.2.3, item 1:  This would be a useful point to mention that the Target IPv6
address is marked by the F Flag being 1.

s9.2.3, para after item 4: s/Else/Otherwise/

s11, para 3: s/Req5.1 in Appendix/Req-5.1 in Appendix B.5/