Hi Brian, Thanks a lot for your review of the GAAO document. We just submitted a new revision that hopefully addresses all your concerns. Please see inline.
> -----Original Message----- > From: Brian Haberman via Datatracker <[email protected]> > Sent: Monday, March 31, 2025 4:45 PM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Intdir early review of draft-ietf-6lo-nd-gaao-03 > > 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? > [LI] We did put 2119/8174 rules in Section 6 when defining the option. We actually updated that section to add more 2119/8174 language. However, we revised as well Section 7 and added 2119/8174 language where we consider it necessary. > 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? [LI] Excellent point. ROVR work as defined in 8505 and extended in 8928 with the Crypto ID. What was missing is the C flag that actually signals the use of 8928. We updated the document accordingly. > > 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? [LI] The document mostly refers to RFC 8505. We added text about the lifetime. > > 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? [LI] Because the 6LN may later switch to a 6LR role and has to run the AAF as well. This is how you build the topology. The trivial approach is to set AAF to zero and take what is sent back, but we thought that to be more generic, leave the possibility to ask for a specific AAF. We modified the text to recommend using 0. 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. [LI] That is true. We modified the text in Section 8 to inform about such risk. > > 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). [LI] The F bit is requested in https://datatracker.ietf.org/doc/html/draft-ietf-6lo-prefix-registration-07 But you are right. It is not yet allocated and should not be there. We did delete it. > > 6. The document defines the GAAO acronym, but then consistently uses > "GAA Option" instead of the acronym. [LI] You are tight. We aligned the text to only use GAAO. > > 7. s/picky-bagged/piggy-backed [LI] Thanks. Fixed. > > 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)? [LI] The same point has been raised by Joel in his GENART review. We added text in Section 7.2 on how to handle this case. Thanks again for the review. Ciao L. > _______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
