[RTG-DIR] RtgDir Review: draft-ietf-roll-unaware-leaves-23

julien.meuric@orange.com Thu, 17 December 2020 16:08 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B29393A0A26; Thu, 17 Dec 2020 08:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.213
X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 17e2d3QVqiXT; Thu, 17 Dec 2020 08:08:41 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C140B3A0A21; Thu, 17 Dec 2020 08:08:40 -0800 (PST)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4CxcP24Jn5z5wHG; Thu, 17 Dec 2020 17:08:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608221318; bh=xzs8ETDNpDiOslf2ARBi2sHIBWr7jqfQjjIes/Cgpxs=; h=From:Subject:To:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=q8w368aDhreSE+u83jpR+1w92ATDSXLWTX2jKzq7DS0vqXzI64LZ7BY2z3jqi997L 9UsaTzHV1CcVLGmFhVz9Asew+xDW/wxFrYoCqAQNWZmski0HJB3e+gmUdqN38nX02Y HBP468rYVjUSeVf7pDp3MXfhnBqchbxWlyw1g1RPpZ5swqTQhoSqbLrZlI18RdAWga p0mdFZZlHHdBfu5MKbJCQKw/LCSn9mRjdJax/ktIjf/t5+yJBT5BAVKW6bCE8rXRCf vaT0F9/IQiH8ZbEO7fjq/lb0FiuETY/9HQvwt1lE7n1glC2CSi5E453OtoY4PKJUIG /YJNvJvBGiJqQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4CxcP23MbyzyR4; Thu, 17 Dec 2020 17:08:38 +0100 (CET)
Received: from [] ( by exchange-eme6.itn.ftgroup ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 17 Dec 2020 17:08:38 +0100
From: <julien.meuric@orange.com>
Organization: Orange
To: "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, <roll@ietf.org>, <draft-ietf-roll-unaware-leaves@ietf.org>
Message-ID: <27211_1608221318_5FDB8286_27211_31_2_5764bbfa-dbd4-46a4-1fe1-00f4d75268a5@orange.com>
Date: Thu, 17 Dec 2020 17:08:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ZUXd5z17osA2YrhWcjrWlPVnNe0>
Subject: [RTG-DIR] RtgDir Review: draft-ietf-roll-unaware-leaves-23
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 16:08:43 -0000


I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-roll-unaware-leaves-23
Reviewer: Julien Meuric
Review Date: 2020-12-17
IETF LC End Date: 2020-12-09
Intended Status: Standards Track


I have some minor concerns about this document that I think should be
resolved before publication.


I am not an LLN expert, but I find the I-D convenient to read thanks to
the appropriate (but numerous) references. I just feel that a few
sections deserve some clarification to improve readability and that flag
number selection doesn't really follow the expected process.

*Major Issues:*

No major issues found.

*Minor Issues:*

- Sorry if ask questions on implicit contexts that are obvious to LLN
people, but I am confused in section 3 with that "6LR that acts as a
border Router for external routes": does it advertise towards the RPL
domain? Does it talk to a peer 6LR that is also a RPL Router? Is that
particular router necessarily the RPL Root?

- The text in section 6.2, as well as figures 3 and 4, use the F and P
flags as if the bit numbers were defined, though their number is only
"suggested" in the IANA section. If no early allocation process
happened, it is inappropriate to assume the to-be-allocated bit number
in the body of the document.

- Section 6.3 reduces an 8-bit field to a 6 bit value. It would be worth
mentioning that it sounds reasonable because the associated registry
relies on standards action for registration and only values up to 10 are
currently allocated.
Furthermore, is there an update of that 6-bit space split to map the
previous ranges? If the answer lies in the IANA section, then a few
words would be welcome in section 6.

- RPL-[An]aware, RAL and RUL are preceded most of the times by "a" [OK
if pronounced "riple", "ral", "rul"], but sometimes by "an" ["are
pi..."]: please pick one and be consistent.
- Any reason why "Host", "Hop" and "Router" are often written with a
capital H/R?
- RFC 2119 keywords SHOULD be used more often for an IETF standard
track, it sometimes feels that the text is written to circumvent them.
E.g., section 4.2.1 uses a wording based on "requires... if and only
if..."; section 4.3 describes a behavior without any normative keyword;
section 5.1 says "needs to", "is expected not to", "is suggested to"; etc.

Section 1.
- The phrase "terminate packets" feels odd: is "terminate paths" intended?
- s/expectations/requirements/
- The term "change" is used several times in the section summary though
it is a bit loose: depending on the situation, "modify" or "extend"
would be more specific (the former may impact existing implementations,
the latter does not).
-  OLD
      Section 8 presents the changes made to [RFC6775] and [RFC8505];
      The range of the ND status codes is reduced down to 64 values, and
      the remaining bits in the original status field are now reserved.
      Section 8 presents how [RFC6775] and [RFC8505] are used; the
      range of the ND status codes is narrowed down to 64 values, and
      the unused bits are reserved.

Section 2.
- s/Neighbor solicitation/Neighbor Solicitation/
- s/Information solicitation (DIS)/Information Solicitation (DIS)/

Section 3.
- s/The RPL Root tunnels the packets/The RPL Root tunnels data packets/ 
[unless we're talking about control packet]
- s/forwards the original (inner) packet/forwards original (inner) packets/

Section 4.
- s/Neighbor solicitation (NS)/Neighbor Solicitation (NS)/
- s/6LN functionality in [RFC8505]/6LN functionality from [RFC8505]/
- Section 4.2.3 summarizes the main use case of the ROVR though its use
here is a bit different: why not focus the paragraph on the latest
sentence and bring a correct topic balance into the section?

Section 5.
- s/with a CIO/with a 6CIO/
- s/the Root terminates the IP-in-IP tunnel at the parent 6LR/the
IP-in-IP tunnel from the Root terminates at the parent 6LR/

Section 6.
- s/between the 6LR and the RPL Root/between the RPL Root and the 6LR/
- s/encodes it in one of these reserved flags of the RPL DODAG
configuration option/allocates a new one in the RPL DODAG configuration
- s/values zero (0) to six (6)/values from zero (0) to six (6)/

Section 7.
- The section title should point to the draft title ("Efficient Route
Invalidation") rather than the draft name which will be replaced by an
RFC number at publication time.
- s/hop by hop/hop-by-hop/

Section 8.
- Spacing inconsistency on the section title.

Section 9.
- In section 9.2.2, the capital T is missing on "the" for steps 4 and 5.
- s/Lifetime. e.g./Lifetime. E.g./
- s/6LoWPAN ND related reasons/6LoWPAN ND-related reasons/
- s/An error injecting the route/An error when injecting the route/
- In section 9.2.3, the capital T is missing on "the" for steps 2 and 3.

Section 11.
- s/supporting th extension/supporting the extension/

Section 12.
- s/doesn't/does not/




Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.