Hi Pascal, Thanks a lot for your useful review. We just submitted a new revision of the document hopefully addressing your points. Please find detailed answers inline.
Ciao L. From: Pascal Thubert <[email protected]<mailto:[email protected]>> Sent: Friday, July 25, 2025 12:53 PM To: [email protected]<mailto:[email protected]> Subject: [6lo] review of draft-ietf-6lo-nd-gaao-06 Dear all I made a pass on the current version of the draft and have a number of high level comments / proposals. 1) use the P field as in the registration to indicate whether the node requests an address or a prefix. In the future, the method could be extended to obtain an anycast address or a multicast address associated with a named resource. [LI] There is no need to have an explicit bit. The AAF value signal the type of request. For instance, PASA can only allocate addresses, not prefixes. To allocate prefixes a different AAF value can be used. We added some wording in the AAF term definition to makes this explicit. 2) not to overload the status in the response. The prefix length may be indicated in a currently reserved space in the GAAO [LI] Yes, we put an explicit 7-bit field in the option. 3) optionally use the address field in the request to indicate the prefix from which the address should be derived. If not provided, indicate that the address returned is implicitly used on the interface which was used to make the request [LI] Excellent point, we added this feature. Thanks. 4) return a prefix length for an address (e.g., /64) if the prefix is on link so the node may create a connected route [LI] Done with point 2. 5) in the protocol operation, be clear on what is done for all types of requests, then what is specific for address, and what is specific for a prefix. In the text sometimes the term request is associated with "address" and sometimes with "address or prefix", though in places the intent in the former case appears to be for prefixes as well.. [LI] We clarified all cases. 6) consider using a bit in the request to indicate that the router should register the address or prefix without a second round (Ratification Phase). The router would pick the missing EARO field from a default and return the complete EARO to indicate that the registration succeeded. In that case, maybe add also an "R bit" to the GAAO like the one in the EARO and rename the current R bit to avoid confusion. [LI] Actually it depends again on the AAF and the network. If the 6LR does not set the R bit it means that it implicitly registered the allocated address/prefix. In this case, if a 6LN does not want to use the implicitly registered address/prefix it can simply deregister using EARO with registration lifetime equal zero. When implicit registration is used, there is no need to append a EARO, since GAAO has basically the same content as an EARO. 7) change the term Ratification Phase to "registration phase" with a ref to RFC 8505 and the prefix registration draft. [LI] Done. I suggest we also start thinking of providing a name (like mDNS) in the request to ask the router to publish the association of the name and address. This will be useful for multicast and anycast as well. [LI] Excellent we already think about GAAO extensions 😉 I hope this helps -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
