Hey Luigi,
Apologies for the delay in my response. Thanks for the summary of changes
based on my comments. The -05 version appears to address all of my concerns.
Regards,
Brian
> On Jun 23, 2025, at 9:56 AM, Luigi IANNONE <luigi.iann...@huawei.com> wrote:
>
> 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 <nore...@ietf.org>
>> Sent: Monday, March 31, 2025 4:45 PM
>> To: int-...@ietf.org
>> Cc: 6lo@ietf.org; draft-ietf-6lo-nd-gaao....@ietf.org
>> 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 -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org
