Hi Éric, Thank you again for the thorough review. We just submitted revision -15 updated to address your comments. You can direct replies to the issues you raised inline.
Let us know your feedback on this latest version. L. p.s. We submitted the xml source on the datatracker. [email protected]<mailto:[email protected]> Paris Research Center Huawei Technologies France S.A.S.U. From: Eric Vyncke (evyncke) <[email protected]> Sent: Monday, July 13, 2026 2:52 PM To: Luigi Iannone <[email protected]>; Zhe Lou <[email protected]>; Adnan Rashid <[email protected]> Cc: 6lo <[email protected]>; Carles Gomez Montenegro <[email protected]> Subject: [6lo] AD review of draft-ietf-6lo-path-aware-semantic-addressing-14 # Éric Vyncke, INT AD, AD review for draft-ietf-6lo-path-aware-semantic-addressing-14 CC @evyncke Thank you for the work put into this document. Please find below my AD review, especially about the intended publication status. 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. Special thanks to Carles Gomez for the shepherd's detailed write-up including the WG consensus but see below about the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric Note: this AD review 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 ### Shepherd's write-up The Q11 answer should probably include the word 'interoperation' as this is key for being a PS. ### Analogy with BIER I wonder whether drawing some similarities with BIER would be useful as its RFCs are already published (experimental though I think). [LI] We are not sure introducing similarities with BIER would be helpful. Wouldn't this generate confusion? Similarities are not evident and we are not sure how many people participating in 6lo are familiar with BIER. Is this really a critical issue? ### Intended publication status Should the I-D rather be 'experimental' ? I.e., AFAIK there are no implementations and the specification has room for improvements (sorry to be blunt), see below. [LI] Good question raised also by Joel Halpern in his RTGDIR review: https://mailarchive.ietf.org/arch/msg/rtg-dir/sYejmbANXjgepFvt57Q5tLiY5bw/ As we explained at that time, yes the status is debatable but current practice in IoT is to use PS unless is really really a complete different architecture: https://mailarchive.ietf.org/arch/msg/rtg-dir/rUfuYwyfhdKXAbNYCq_PiXXDvAU/ Joel acknowledged the different practice in IoT and is OK with the PS: https://mailarchive.ietf.org/arch/msg/rtg-dir/VjuK-4r2kq8mS82S2JF_18PrHZs/ Let us know if you still consider the documents should change intended status. ### Abstract s/These specifications describe the PASA architecture/*This document specifies* the PASA architecture/ as it is a PS. [LI] Done. ### Section 1 Please provide references for `stemming initiatives like Industry 4.0, Smart Grid, and Smart City, [LI] Done. ` Consider introducing LLN acronym earlier (one sentence before). [LI] Added to the first sentence of the section. ### Section 3 Suggest to introduce the notion of PASA tree else the notion of 'child' or 'leaf' comes out of the blue. [LI] Moved upward. A figure similar to Figure 5 would probably help. [LI] There is actually a reference to Section 6, a figure in the definition of terms would be awkward in our opinion. ### Section 4 s/it *will reduce* the overall energy/it *reduces* the overall energy/ [LI] Chqnged. ### Section 4.1 and others While there are nice IoT descriptions, why are PASA suitable or even why PASA is recommended ? I fear that this is more distracting than being useful. [LI] Rephrased to avoid the term recommended and clarify when and why PASA is a good fit. Early discussions in the WG about PASA where exactly about when and why PASA is useful, hence the effort on describing the use cases extensively. If considered distracting we can move the section as an appendix. What do you think? Expand PLC (and possible add an informative reference) [LI] Done. ### Section 4.2 Expand and add a reference to MCU. [LI] Added. Unsure whether PLC is really a 6LO thing and more over most of smart home are more 802.15.4 (Matter, which is 6LO). Suggest either scrapping this use case or rewriting it. [LI] It has been partially re-written to motivate its presence. It can be moved altogether as an appendix with the other use cases as suggested above. ### Section 4.3 Also add informative references to `AI/DI/RS232/RS485/single pair Ethernet`. [LI] Added. ### Section 4.4 Thanks for the PASA discussion in this sub-section. s/as described in details/as *specified* in details/ [LI] Thanks. Changed. Unsure though whether PLC could be used on a shop floor due to electromagnetic interference... [LI] We are unsure about this comment. The use of power line communication is motivated by avoiding electromagnetic interference. Yet, we replaced "shop floors' with "industrial premises". ### Section 5 s/Path-Aware Semantic Addressing (PASA) is an efficient topology-based/PASA is a topology-based/ acronym already expanded and this is a spec, so, let's try to avoid 'marketing' terms or then justify them. [LI] Changed. Use PASA TAAF rather then PASA in `Each PASA node is aware of its own IPv6 address, constructed by an IPv6 prefix and the PASA itself` of course introduce the TAAF acronym as well. [LI] Used TAAF. Acronym has been already define in Section 3. `performs packet decompression` and add the obvious forwaring to the rest of the network and combine with the next sentence. [LI] The suggestion is a bit fuzzy. We assume the comment is about the fact that it is the header (not the packet) that is decompressed and we changed accordingly. Unsure whether the sentence `However, an IP-in-IP header,...` is useful as it is somehow ambiguous where it applies. Suggest removing it. [LI] Dropped. Cannot redefine the terms defined in section 3. [LI] Actually terms are not redefined. The section describe how the three nodes operate. We changed the text to be more explicit. I cannot understand `no new multicast requirements are introduced` please rephrase. [LI] Rephrase to clearly state that PASA does not need multicast communication. What is `IPv6 ND Registrars` also add a normative reference. [LI] It is actually Routing Registrars define in RFC8505. Changed and added reference. PASA AAF or PASA TAAF in `calculated using the PASA AAF` ? [LI] Is TAAF. Good catch. Changed. Somehow obvious but also unclear as the paragraph talks about routers and now there is `other 6LR neighbors`. The terms 'router' and '6LR' should be used consistenly, possibly only using 6LR everywhere ? [LI] We did uniform to use PASA Router and PASA Host everywhere to better highlight that they need to support the PASA specifications. Should BCP14 ("MUST", "SHOULD") be used in the paragraph `According to [I-D.ietf-6lo-nd-gaao] and [RFC8505] ... previously obtained address` ? [LI] The two document are both normative and include the MUST. `The overall design objective is centered on reducing the size of ... PASA reduces the amount of information synchronization messages` this paragraph could appear earlier in the section and s/amount of information synchronization messages/amount of routing messages/ ? [LI] Actually a great idea. We move it to the very beginning of the section. The informative reference CHING21 appears to be behind a paywall :-( I.e., the comparison wrt RPL should be expanded and more justified in this I-D. [LI] Changed with a link to an open access. ### Section 6 Add "Per GAAO" in the `The basic rules for the AAF`. [LI] Done. Like in other places in the document, I find considering IPv6 as strings (concatenation, quoted literals, ...) rather weird. While I understand the authors' motivation, may I suggest to use the terminology section to introduce this use? [LI] We did find awkward to such operation in the definition of terms. But we added some text right before section 6.1 introducing the use of bit strings. ### Section 6.1 Should there be something like "i.e., using an IID of ::1" in `MUST use the single bit address '1'` ? [LI] Good idea. Added. Thanks. s/brother/sibling/ [LI] Changed. ### Section 6.2 Please add an informative reference to `IEEE 802.15.5 ` [LI] Added. `TAAF grows linearly ` ? I would have assumed log2() [LI] Linearly as we add 1 bit per each sibling. ### Section 7 This section would benefit from a deep rewrite... * adding some graphics about the packet transformation (not really translation IMHO) would be really useful * `IPv6 suffix` ? unsure what it is (OK I understand but not officially specified as IPv6 prefix is... is it the IID ?) * never heard of `quadruplets` before and I would expect to be 4 and not 2 octets, please add in the terminilogy section * `that can contain the address` is impossible; should it rather be "can represent" ? * `PASA-6LoRH header according to [RFC8138]` unsure whether the RFC specifies a `PASA-6LoRH` ;-) * s/The following details/The following *sections specify*/ * who is the "we" in `Here we will use` ? The authors ? The 6LO WG ? The IETF ? Please avoid ambiguities [LI] We actually almost completely removed the paragraph. Text about root behavior has been moved to section 7.2 as it belongs to that scenario. Part has been dropped as was a duplicate of section 6.2. Hope that this fixes the issue. ### Section 7.1 In this section (and others), I would expect more BCP14 uppercase terms to be crisp in a PS. [LI] Modified when necessary. What is a `*local* PASA endpoint`? [LI] Changed to "endpoint in the PASA domain" s/In the proposed TAAF algorithm/In the *specified* TAAF algorithm/ [LI] Changed. s/whose address has length 1/whose address has length 1 *bit*/ [LI] Changed. s/The length operation/The length *function*/ [LI] Changed. About `current node's address (abbreviated to CA)`... why 'current' as PASA addresses are assumed to be stable, moreover "CA" is really overloaded at the IETF, finally it assumes that the node has only one address (is it always the case) [LI] Hard to find unused acronyms ;-) We change to "NOA" as for Node's Own Address After `following sequence of actions`, there is no need to add `go to next step`. [LI] True. While pedantic we prefer to keep them to avoid misinterpretation. Should step 4 be before step 2 ? [LI] In principle the steps can be inverted, however, since the first action done on PASA addresses is to search for the first bit set to 1, hence the length, we thought comes for free and it is easy to compare it right away. Where is `PrefixOf() operation` defined ? [LI] Added explicit definition and adjusted the text. `Calculate which child is the next hop address` how ? and which address ? [LI] Changed. We now use directly the PrefixOf() function. s/TAAF proposed/TAAF *specified*/ [LI] Changed. `send an ICMPv6 "` must follow the rules of RFC 4443 [LI] Added. (also in the security considerations section) Figure 7 would benefit to appear earlier in the text. [LI] It is positioned right after the corresponding algorithm. Any specific suggestion? Is `inner-domain` the same as "PASA domain" ? (I guess so, but let's be clear) [LI] Changed. ### Section 8 Should the packet format appear before the forwarding specification ? [LI] We think that having the address assignment and forwarding procedure close together (section 6 and 7) provide a better continuity in the text. `Page 1` as it does not mean physical sheet page, it is worth having some words about this term. [LI] Done. s/rouge node/ro*gu*e node/ some authors have lived for too long (?) in a French-speaking country ;-) [LI] C'est vrai. :-) Fixed. ### Section 8.2 I wonder why size = N+1 ? Is there any hidden reasoning ? [LI] It is Size = N - 1 as you define below. It is explained in the definition. We need at least 1 octet for the address and max 8 octets(64 bits). With only have 3 bits, 0 to 7, translating to 1 to 8. We added an example of content. s/The length N equals Size plus 1/The Size equals N minus 1/ [LI] Changed. ### Section 8.3 What is `statefully compressed`? [LI] Changed. s/In compact notation/In *RFC 5952 representation*/ [LI] Changed. ### Section 9 Add an normative reference to 802.15.4.[LI] [LI] That is the ZigBee reference. We moved it closer to the citation. Unsure why there is a reference to a non-IETF non-IPv6 Zigbee. [LI] This question is unclear. There is no such a claim in the draft. Add reference to `6CIO`. [LI] There are already reference to RFC7400. ### Section 10 s/and it has address configuration/*if* it has address configuration/ [LI] Changed. `send a Neighbor Solicitation` to which IPv6 address and from which IPv6 address? [LI] According to RFC8505. `indicate its role as indicated in Section 9.` but I cannot find the specification in this I-D section 9. [LI] Is the section with title "Nodes role indication". It states which configuration of bits to be used in the 6CIO to indicate the role of the node. What is meant by `delegated` in this context? [LI] Changed. There is no delegation in PASA. ### Section 11.1 Add a normative reference to https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type [LI] Done. ### Section 14 Use all lowercase in `2001:db8::2B/64` [LI] Changed. Please follow https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ when using `RECOMMENDED` (semantically equivalent to "SHOULD"). I.e., perhaps words about losing the PASA benefits. [LI] Done. ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Abstract s/*IP packet* stateless forwarding/*stateless* IP packet forwarding/ ? [LI] Changed. ### Section 1 s/those type of deployments/those type*s* of deployments/ [LI] Done. ### Section 4 s/reliable links*'* connectivity/reliable links connectivity/ ? genitive case is only for living things AFAIK. [LI] Changed. ### Section 4.2 (and possible others) `Usually` is often followed by a ','. [LI] Changed. ### Section 11 s/This section provides guidance /This section provides *requests*/ [LI] Changed. ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. [LI] It is already the case. Did you have any issue in generating SVG graphics with our source xml?
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
