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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. 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: None 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 [RFC6550]. ENDS 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 here. 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 enables/ 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 RUL./ 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 capitalization) s6.3, para 2: OLD: 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/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
