Reviewer: Brian Haberman Review result: On the Right Track I am an assigned INT directorate reviewer for draft-ietf-6lo-nd-gaao. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/
These comments are part of a requested, early review... There are some fundamental aspects of this document that should be addressed by the WG. Happy to chat about these comments if clarifications are needed. 1. Section 7 is very loose in its terminology around error checking received messages. I would expect to see concrete rules using 2119/8174 keywords. For example, in section 7.1, what checks does a receiving 6LR do to ensure that the received NS is valid? What validation checks does the 6LN perform on the received NA? 2. RFC 8505 uses the code suffix field for signaling the type of ROVR contained in the NDP messages. How do 6LRs supporting this document discern the same level of information? 3. It seems like the discussion of address lifetimes in this draft does not capture the same level of detail as discussions in other documents (e.g., RFC 4862). What limits/checks should nodes enforce on the lifetime field? 4. Introductory text states that the AAF needs to be the same across the entire LLN, yet a 6LN can request an AAF? It seems like the request should just be for an address (or prefix) and the 6LR receiving the request uses the AAF in use across the LLN. Why would a 6LN care about what AAF is used? Additionally, the handling of a rejected request due to an unsupported AAF (Section 8) seems contradictory to the goal of reducing resource consumption. More justification needed as to why a 6LN should be able to request a specific AAF. 5. Section 9 should not include the 'F' bit in the description of the modified 6CIO. The 'F' bit is not currently allocated by IANA (and its current location seems to contradict what IANA says about the first 8 bits of the field). 6. The document defines the GAAO acronym, but then consistently uses "GAA Option" instead of the acronym. 7. s/picky-bagged/piggy-backed 8. RFC 8505 describes the process for doing address registration. If the 6LR requires the 6LN to perform the confirmation step in section 7.2, what constraints need to be put on the initiation of that registration process (e.g., how long should the 6LR wait for the 6LN to send a registration)? _______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
