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

[[e-mail]]

Hello,

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
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

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

*Summary:*

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

*Comments:*

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.

*Nits:*
------
Overall
---
- 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.
  NEW
      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
option/
- 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/
------


Regards,

Julien



_________________________________________________________________________________________________________________________

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.