Hi Éric, Sure, we can discuss it during the 6lo session.
Ciao L. [email protected]<mailto:[email protected]> Paris Research Center Huawei Technologies France S.A.S.U. From: Eric Vyncke (evyncke) <[email protected]> Sent: Friday, July 17, 2026 1:47 PM To: Luigi IANNONE <[email protected]>; [email protected] Cc: Luigi Iannone <[email protected]>; [email protected]; 6lo <[email protected]> Subject: Re: AD review of draft-ietf-6lo-path-aware-semantic-addressing-14 Hello Luigi, If time permits, then this would be a good topic to discuss at the 6LO session at IETF-126 next week. Basically, my preference for 'experimental' is based on: 1. Drastic changes (routing, NDP) without actual testing 1. Sorry again, but the current state of the specification is rather light (per my AD review) 1. Finally, I think that this will be an easier approval by the IESG, i.e., I won't be the only one finding that experimental status is the right one 1. 'Experimental' does not mean that the technology and the ideas are not smart or not valid 😉 And many people outside the IETF see "RFC" and do not look further... Regards -éric From: Luigi IANNONE <[email protected]<mailto:[email protected]>> Date: Friday, 17 July 2026 at 11:50 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>; Luigi Iannone <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; 6lo <[email protected]<mailto:[email protected]>> Subject: RE: AD review of draft-ietf-6lo-path-aware-semantic-addressing-14 Hello, As an additional point, this is what we were preparing as reply for this specific point: 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. Still working on the rest of the review ;-) Ciao L. [email protected]<mailto:[email protected]> Paris Research Center Huawei Technologies France S.A.S.U. From: Carles Gomez Montenegro <[email protected]<mailto:[email protected]>> Sent: Thursday, July 16, 2026 9:37 AM To: Luigi IANNONE <[email protected]<mailto:[email protected]>> Cc: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>; Luigi Iannone <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; 6lo <[email protected]<mailto:[email protected]>> Subject: Re: AD review of draft-ietf-6lo-path-aware-semantic-addressing-14 Hi Éric, Thanks for your review! On the intended status, the point of whether the draft should be experimental had been brought up some time ago by Joel Halpern during an early review. The authors then provided some motivation for the "standards track" intented status [1]. Subsequently, Joel seemed to be satisfied with the explanations given. I understand that PASA has some academic nature or interest, and lack of real-world (*) implementations also contribute towards "Experimental". On the other hand, some recent 6lo documents (e.g., RFC 9926) have been published as "Standards Track" without known implementations at the time of publication, and perhaps the "Standards Track" status may help attract more implementations (a posteriori, though). Just my two cents on this point, where as you can see, I don't have a very strong opinion. I guess we can discuss further on the list or in the 6lo session at IETF 126. In any case, when I update the shepherd writeup, it will reflect the outcome of the discussion. Cheers, Carles (as document shepherd) [1] https://mailarchive.ietf.org/arch/msg/6lo/InbIldiRQjKnkvYxut6aCWae_PM/ (*) There is simulation code for PASA. On Wed, 15 Jul 2026 at 11:22, Luigi IANNONE <[email protected]<mailto:[email protected]>> wrote: Hi Éric, Just forwarding you review to the right set of authors 😉 Thanks for the review. We will work on your comments. Ciao L. [email protected]<mailto:[email protected]> Paris Research Center Huawei Technologies France S.A.S.U. From: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Sent: Monday, July 13, 2026 2:52 PM To: Luigi Iannone <[email protected]<mailto:[email protected]>>; Zhe Lou <[email protected]<mailto:[email protected]>>; Adnan Rashid <[email protected]<mailto:[email protected]>> Cc: 6lo <[email protected]<mailto:[email protected]>>; Carles Gomez Montenegro <[email protected]<mailto:[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). ### 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. ### Abstract s/These specifications describe the PASA architecture/*This document specifies* the PASA architecture/ as it is a PS. ### Section 1 Please provide references for `stemming initiatives like Industry 4.0, Smart Grid, and Smart City,` Consider introducing LLN acronym earlier (one sentence before). ### Section 3 Suggest to introduce the notion of PASA tree else the notion of 'child' or 'leaf' comes out of the blue. A figure similar to Figure 5 would probably help. ### Section 4 s/it *will reduce* the overall energy/it *reduces* the overall energy/ ### 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. Expand PLC (and possible add an informative reference) ### Section 4.2 Expand and add a reference to MCU. 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. ### Section 4.3 Also add informative references to `AI/DI/RS232/RS485/single pair Ethernet`. ### Section 4.4 Thanks for the PASA discussion in this sub-section. s/as described in details/as *specified* in details/ Unsure though whether PLC could be used on a shop floor due to electromagnetic interference... ### 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. 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. `performs packet decompression` and add the obvious forwaring to the rest of the network and combine with the next sentence. Unsure whether the sentence `However, an IP-in-IP header,...` is useful as it is somehow ambiguous where it applies. Suggest removing it. Cannot redefine the terms defined in section 3. I cannot understand `no new multicast requirements are introduced` please rephrase. What is `IPv6 ND Registrars` also add a normative reference. PASA AAF or PASA TAAF in `calculated using the PASA AAF` ? 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 ? Should BCP14 ("MUST", "SHOULD") be used in the paragraph `According to [I-D.ietf-6lo-nd-gaao] and [RFC8505] ... previously obtained address` ? `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/ ? 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. ### Section 6 Add "Per GAAO" in the `The basic rules for the AAF`. 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? ### Section 6.1 Should there be something like "i.e., using an IID of ::1" in `MUST use the single bit address '1'` ? s/brother/sibling/ ### Section 6.2 Please add an informative reference to `IEEE 802.15.5 ` `TAAF grows linearly ` ? I would have assumed log2() ### 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 ### Section 7.1 In this section (and others), I would expect more BCP14 uppercase terms to be crisp in a PS. What is a `*local* PASA endpoint`? s/In the proposed TAAF algorithm/In the *specified* TAAF algorithm/ s/whose address has length 1/whose address has length 1 *bit*/ s/The length operation/The length *function*/ 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) After `following sequence of actions`, there is no need to add `go to next step`. Should step 4 be before step 2 ? Where is `PrefixOf() operation` defined ? `Calculate which child is the next hop address` how ? and which address ? s/TAAF proposed/TAAF *specified*/ `send an ICMPv6 "` must follow the rules of RFC 4443 Figure 7 would benefit to appear earlier in the text. Is `inner-domain` the same as "PASA domain" ? (I guess so, but let's be clear) ### Section 8 Should the packet format appear before the forwarding specification ? `Page 1` as it does not mean physical sheet page, it is worth having some words about this term. s/rouge node/ro*gu*e node/ some authors have lived for too long (?) in a French-speaking country ;-) ### Section 8.2 I wonder why size = N+1 ? Is there any hidden reasoning ? s/The length N equals Size plus 1/The Size equals N minus 1/ ### Section 8.3 What is `statefully compressed`? s/In compact notation/In *RFC 5952 representation*/ ### Section 9 Add an normative reference to 802.15.4. Unsure why there is a reference to a non-IETF non-IPv6 Zigbee. Add reference to `6CIO`. ### Section 10 s/and it has address configuration/*if* it has address configuration/ `send a Neighbor Solicitation` to which IPv6 address and from which IPv6 address? `indicate its role as indicated in Section 9.` but I cannot find the specification in this I-D section 9. What is meant by `delegated` in this context? ### Section 11.1 Add a normative reference to https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type ### Section 14 Use all lowercase in `2001:db8::2B/64` 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. ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Abstract s/*IP packet* stateless forwarding/*stateless* IP packet forwarding/ ? ### Section 1 s/those type of deployments/those type*s* of deployments/ ### Section 4 s/reliable links*'* connectivity/reliable links connectivity/ ? genitive case is only for living things AFAIK. ### Section 4.2 (and possible others) `Usually` is often followed by a ','. ### Section 11 s/This section provides guidance /This section provides *requests*/ ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics.
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
