Hi Éric, Thank you as well for the review of this document.
We just submitted a new revision (-11) hopefully addressing all your concerns. You can find the xml file on the datatracker. Below and inline you can find the details about the changes we made w.r.t. to your comments [email protected]<mailto:[email protected]> Paris Research Center Huawei Technologies France S.A.S.U. From: Eric Vyncke (evyncke) <[email protected]> Sent: Wednesday, July 8, 2026 4:03 PM To: Luigi Iannone <[email protected]>; Zhe Lou <[email protected]>; Luigi IANNONE <[email protected]>; [email protected] Cc: [email protected]; Carles Gomez Montenegro <[email protected]> Subject: AD review of draft-ietf-6lo-nd-gaao-10 # Éric Vyncke, INT AD, AD review for draft-ietf-6lo-nd-gaao-10 CC @evyncke Thank you for the work put into this document. Please find below my AD review. As the responsible AD, I expect all the points below to be addressed, either by a revised I-D, or an email reply. Of course, authors and WG can reject my points, but this needs to be justified. Once all the points are addressed, I will proceed with the publication process, i.e., IETF Last Call with a specific copy to 6MAN. Special thanks to Carles Gomez for the shepherd's detailed write-up including the WG consensus and the justification of the intended status *BUT* see below. I hope that this review helps to improve the document, Regards, -éric Note: this AD reviews follows the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## Critical issues ### Update to Shepherd's write up The write-up must be refreshed about the DHCP discussion at IETF-125 and the new appendix A. About Q11, I suggest adding some words about "interoperation" as this is critical for a PS. [LI] Thanks again Carles! ### Canonical IPv6 addresses Ensure that *all* IPv6 addresses follow RFC 5952 (notably in lower case, max compression). [LI] Done. ### IANA TBD As there are more than one "TBD" value, please use "TBD1", "TBD2", ... [LI] Done ### Bytes vs. octets Some people prefer using "octets" rather than "bytes". [LI] Agreed and changed. ### Address privacy Should there be some recommendations for AAF specifications to state their status about privacy of addresses ? This could be a paragraph in the security section. [LI] Right. A recommendation has been added to the security section. ### Abstract Add a line about why DHCPv6 is not optimum for LLN. [LI] Done. ### Section 2.2 Also list the RFC for IID, NS, NA, ... [LI] Added. ### Section 2.3 Please specify whether GAAO is a AAF. [LI] Added a sentence to specify the difference. ### Section 3 `The IPv6 address assignment model within a local domain relies on randomly generated Interface Identifiers (IIDs)` is not correct as it is not always `randomly` and it is rather a layer-2 domain than the ambiguous `local domain`. [LI] Correct. The sentence has been changed. `In the latter case, additional mechanisms are required to ensure address` also has some problems: 1) AFAIK, even using DHCPv6 the nodes are required to do DAD 2) CGA & SEND are mostly history :-( and were never required. [LI] Sentence was indeed ambiguous. We rephrased to clarify. On the second point, do you prefer that CGA and SEND references are dropped? In figure 1, unsure whether the top left "STEP" is useful, please consider removing it. [LI] Removed from all such kind of figures. s/is required and proposed/is required and *defined*/ as this is a PS [LI] Changed. ### Section 4 As the R-bit is not set, it is explicit and no `it *implicitly* indicates` [LI] Fixed. About AAF and `it is RECOMMENDED` why not a MUST ? See https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ for the required guidance when the recommandation is not followed. [LI] Actually there is no strong need for this recommendation, so we did drop it. A verb/word is probably missing in `However, a 6LN MAY use a value different from 0, meaning that it is requested to use a specific known AAF` [LI] Changed (also to in relation of the previous point). In `Address/prefix lifetime SHOULD be configurable` on the requester or on the 6LR ? Also missing the required guidance per above IESG statement. [LI] Changed to a MUST actually as it is a key feature to mitigate some types of attacks. ### Section 5 `When a node bootstraps`Is this the only case ? I.e., no expiration renewal ? [LI] Actually only on unreachability detection. We added this case. ### Section 5.1 Use a "MUST" in `the AAF field SHOULD be set to zero unless by configuration ` as there is a "unless". [LI] Changed. In step 1), specify the source & destination IPv6 addresses. [LI] Is it really necessary? GAAO is an option of NS/NA messages. NS/NA messages are built as defined in 4861 and updated in 6775 and 8505, which is clearly stated at the beginning of the document. In step 2), should "on the link" be added after `If the node is a 6LR it MUST use the same AAF to generate addresses/prefixes to requesting neighbor nodes` (`6LoWPAN network` is also used in other places in the document, please ensure to use consistent wording for the same concept) [LI] 6LoWPAN network is the most suitable addition and should be consistent all over the document. ### Section 5.2 `The use of this option is done by configuration. ` on which node (6LN and/or 6LR) ? [LI] 6LRs. Good catch. Added. ### Section 5.3 Please specify that the optimisation must be done within the MTU limit as NDP messages cannot be fragmented. [LI] Added. Suggest to swap 5.3.1 and 5.3.2 to respect the chronology. [LI] Makes sense. Swapped. ### Section 5.4 s/SHOULD/MUST/ in `When the node receives this status back it SHOULD perform one of the following actions` as all cases are covered. [LI] Done. ### Section 6 Specify RFC 7400 *section 3.3*. [LI] Done. Out of curiosity, is there any reason why the M-flag is in the 2nd 32-bit rather than in the first 32-bit ? [LI] As for 7400 the remaining bits in the first 32 bits are reserved for experimental use. ### Section 7 `This section provides guidance to ` it is not about "guidance" but about "request", so, be clear. [LI] Changed. In all subsection, add informational references to the IANA registries, e.g., https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 [LI] Links to all registry groups added. The M-bit position is specified in section 6 so do not use TBD (see my other comment about "TBD") [LI] Changed. ### Section 7.4 Should "6LowPan" be added in the registry name of `"Generic Address Assignment Option".` ? [LI] Definitely a good idea. Added. The parent registry should also be named. [LI] Added. Do we really want to use FCFS in a registry with only 14 available code points ? Specification required or even standard action seem to be preferrable. [LI] Yes the number of codepoints is limited but we do not expect big demands. We changed to "RFC Required". ### Section 8 Why not "MUST" rather than "SHOULD" ? See also the IESG requirement above. [LI] Changed. ### Appendix A First, thanks for adding this useful appendix. I do not think that `While DHCPv6 is the standard ` is correct as most networks can only rely on SLAAC as some widespread OS do not support DHCPv6-IA... especially as later in the text there is `for actual Address Assignment, it is almost non-existent in the field`. So, let's be consistent ;-) [LI] We rephrased both sentences. ### Section A.1 Suggest adding whether is it multicast or unicast. [LI] Excellent idea. Done in A.2 as well. ### Section A.3 s/address several, messages need*s*/address*,* several messages need/ [LI] Thanks, fixed. More important, in DHCPv6 there are at least 2 multicast messages: SOLICIT & REQUEST, the other 2 can be unicast (rarely and obsoleted by RFC 9915) or multicast. The appendix should include DHCPv6 rapid commit as it is only 2 messages. [LI] Thanks. Added. Should RFC 9119 also be a reference in the appendix ? [LI] It is already cited in the very first paragraph of the appendix. Or do you mean elsewhere? ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Abstract s/a *new* extension/an extension/ [LI] Changed. ### Section 4 s/a*n* Neighbor Adverti/a Neighbor Adverti/ [LI] Fixed. Suggest repeating that the presence of `Address/Prefix` is solely based on the GAAO length header field. [LI] Added. ### Section 5.2 s/the 6LR is expect to/the 6LR is expect*ed* to/ [LI] fixed. ### Acknowlegments s/for helping clarifying/for helping *to clarify*/ [LI] fixed. ### Section A.2 s/GAAO does not need to be tramistted /GAAO does not need to be *transmitted*/ [LI] fixed. s/piggy*-*backed/piggybacked/ (and other places) [LI] fixed. ### Section A.3 s/specific packets need*s*/specific packets need/ [LI] fixed. I.e., suggest to use a spell-checker also on the new sections, e.g., `reesources`, `consists on a two unicast messages`, `likelyhood`, `twise` [LI] Done. There were indeed a few typos :-( ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially as this I-D uses the Kramdown file format by starting the block with `~~~ aasvg` ;-) [LI] It was already the case. HTML format looks good from our side. ### References by RFC Number I must admit that I am very bad with RFC numbers so when reading `procedures defined in [RFC8505], [RFC9685], or [RFC9926]`, it means little to me :-( when possible try to use a short name (in addition to the RFC numbers such as SLAAC, IPv6, DHCPv6, ....) [LI] Added for all RFCs at least when they are cited the first time.
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
