Dear all, I have updated the shepherd writeup as per Éric's points below.
Cheers, Carles (as document's shepherd) On Wed, 8 Jul 2026 at 16:03, Eric Vyncke (evyncke) <[email protected]> wrote: > # É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]
