# É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. ### Canonical IPv6 addresses Ensure that *all* IPv6 addresses follow RFC 5952 (notably in lower case, max compression). ### IANA TBD As there are more than one "TBD" value, please use "TBD1", "TBD2", ... ### Bytes vs. octets Some people prefer using "octets" rather than "bytes". ### 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. ### Abstract Add a line about why DHCPv6 is not optimum for LLN. ### Section 2.2 Also list the RFC for IID, NS, NA, ... ### Section 2.3 Please specify whether GAAO is a AAF. ### 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`. `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. In figure 1, unsure whether the top left "STEP" is useful, please consider removing it. s/is required and proposed/is required and *defined*/ as this is a PS ### Section 4 As the R-bit is not set, it is explicit and no `it *implicitly* indicates` 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. 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` In `Address/prefix lifetime SHOULD be configurable` on the requester or on the 6LR ? Also missing the required guidance per above IESG statement. ### Section 5 `When a node bootstraps`Is this the only case ? I.e., no expiration renewal ? ### Section 5.1 Use a "MUST" in `the AAF field SHOULD be set to zero unless by configuration ` as there is a "unless". In step 1), specify the source & destination IPv6 addresses. 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) ### Section 5.2 `The use of this option is done by configuration. ` on which node (6LN and/or 6LR) ? ### Section 5.3 Please specify that the optimisation must be done within the MTU limit as NDP messages cannot be fragmented. Suggest to swap 5.3.1 and 5.3.2 to respect the chronology. ### 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. ### Section 6 Specify RFC 7400 *section 3.3*. Out of curiosity, is there any reason why the M-flag is in the 2nd 32-bit rather than in the first 32-bit ? ### Section 7 `This section provides guidance to ` it is not about "guidance" but about "request", so, be clear. 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 The M-bit position is specified in section 6 so do not use TBD (see my other comment about "TBD") ### Section 7.4 Should "6LowPan" be added in the registry name of `"Generic Address Assignment Option".` ? The parent registry should also be named. 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. ### Section 8 Why not "MUST" rather than "SHOULD" ? See also the IESG requirement above. ### 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 ;-) ### Section A.1 Suggest adding whether is it multicast or unicast. ### Section A.3 s/address several, messages need*s*/address*,* several messages need/ 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. Should RFC 9119 also be a reference in the appendix ? ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Abstract s/a *new* extension/an extension/ ### Section 4 s/a*n* Neighbor Adverti/a Neighbor Adverti/ Suggest repeating that the presence of `Address/Prefix` is solely based on the GAAO length header field. ### Section 5.2 s/the 6LR is expect to/the 6LR is expect*ed* to/ ### Acknowlegments s/for helping clarifying/for helping *to clarify*/ ### Section A.2 s/GAAO does not need to be tramistted /GAAO does not need to be *transmitted*/ s/piggy*-*backed/piggybacked/ (and other places) ### Section A.3 s/specific packets need*s*/specific packets need/ I.e., suggest to use a spell-checker also on the new sections, e.g., `reesources`, `consists on a two unicast messages`, `likelyhood`, `twise` ### 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` ;-) ### 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, ....)
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
