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.