Bonjour Pascal, Thanks for the follow-up.
Please see inline. Cheers, Med De : Pascal Thubert <[email protected]> Envoyé : lundi 26 mai 2025 16:36 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-6lo-prefix-registration-11: (with DISCUSS and COMMENT) Dear Mohamed Many thanks for your kind review. I'd like to address the DISCUSS first and the rest separately to be faster on that part. Please see below : ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Bonjour Pascal, Thanks for the effort put into this specification with many "surgical" changes that manipulate various pieces. Special thanks for Section 3. Note that some of these considerations (e.g., those discussing pre-requisites) are better moved to an operational considerations section. Good point I'll see how I can do that. [Med] Thanks. # DISCUSS ## Consistency with 7400 and IANA registration CURRENT: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 1 | Reserved |X|A|D|L|B|P|E|G| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: New Capability Bit in the 6CIO New Option Field: *F:* 1-bit flag, set to 1 to indicate "Registration for prefixes Supported" ### Per https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#sixlowpan-capability-bits, the request should indicate a bit position. Yes. And actually we had that discussion with David (IANA) upon his early review. Position 16 that you find in the figure is requested in section 13.2. [Med] ACK. ### None of the entries in that registry updates 7400. Any specific reason why are we deviating from that practice? I understand that you suggest to remove rfc 7400 from the draft heading. I'm good with that. [Med] Thanks. ### The fields indicated as "Reserved" in Figure are marked as unassigned (not reserved) in RFC7400: "Bits marked by underscores in Figure 5 are unassigned and available for future assignment.". Some consistency is needed here vs. 7400 The behavior described in section 3.4 of rfc 7400 is that of reserved fields (set to 0 and ignore upon receiving). I can remove the ´reserved' in the picture and inherit the _ from rfc 7400 if that's ok? [Med] Yes, please. Removing the figure would be even better, IMO. ### Any reason why not any of the unassigned bits in the low range is used? David's point. RFC 7400 makes those bits experimental. [Med] Thanks. ## New EARO Prefix Length Field and F flag CURRENT: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |F|Prefix Length| Opaque | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |r|C| P | I |R|T| TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ROVR ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: EARO Option Format for Use in NS Messages New and updated Option Fields: ### Only PRT are defined in https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-adress-registration-option-flags. Where the flags are defined? R is unassigned. [Med] I guess you meant "r" as R has already a meaning. BTW, you may rename "r" to "u" to indicate this is unassigned and avoid confusing with R flag. C is an oversight from RFC 8928 that we are fixing with https://datatracker.ietf.org/doc/html/draft-ietf-6lo-updating-rfc-8928-02 [Med] Thanks for the clarification about. But what about I-flag? Both RFCs should be in the same cluster and have consecutive numbers. ### RFC8505 says "MUST be set to 0 in NS messages". How a legacy receiver will handle this updated EARO option? Will it be ignored? Rejected? Please consider adding some considerations to the backward compatibility section. Of course, adding a pointer to where this is already described would be sufficient. Thanks. That is the point of using RFC 7400 above. The receiver has indicated that it supports the extension else the sender does not use it. Should I clarify that ? A new section seems overkill. What would you suggest ? [Med] I suggest that you rename your current "Backward Compatibility" Section to "Operational Considerations" and then enrich it with the clarification you provided above. Thanks. Pascal ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Consistency with Your Own Terminology on Amend/Extend For example, OLD: 4. Updating RFC 4861 NEW: 4. Amending RFC 4861 # Section 5: CURRENT: 5. Extending RFC 7400 This is about associating a meaning with an unassigned value in a registry managed by IANA, not updating 7400. The document says "[RFC7400] was already extended by [RFC8505]" but it does so without updating 7400. # Section 7.1: Update 8505 The values are handled in an IANA registry: https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values. Nothing is updated in 8505. Also, this field is defined in rfc9685, not 8505. Why is this subsection provided under "Update 8505"? # Section 12 Consider adding some deployment considerations. For example, how the various extensions are expected to be added to a network that is composed of nodes compliant with existing RFCs? # NITS ## Abstract ### nits, expand acronyms, etc. OLD: This document updates IPv6 Neighbor Discovery RFC4861 and the 6LoWPAN extensions (RFC8505, RFC8928, RFC8929, RFC7400) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows to request neighbor router(s) to redistribute the prefix in a larger routing domain regardless of the routing protocol used in the larger domain. This document extends RPL (RFC6550, RFC6553, RFC9010) to enable the 6LR to inject the registered prefix in RPL. NEW: This document updates IPv6 Neighbor Discovery (RFC 4861) and the 6LoWPAN extensions (RFC 8505, RFC 8928, RFC 8929, and RFC 7400) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows to request neighbor router(s) to redistribute the prefix in a larger routing domain regardless of the routing protocol used in that domain. This document extends Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550, RFC 6553, and RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL. ### Large routing domain What does that mean? Do we really need to mention that for injecting routes? I would avoid that as this is a distraction at this stage. # Introduction ### Stimulated CURRENT: * Unicast host to router operations stimulated by the host and its applications. What does "stimulated" mean here? Do we mean "triggered"? ### (nits) There are many instance of 6LN/6LR Consider making these changes: OLD: unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LN and the 6LR. NEW: unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between a 6LN and a 6LR. OLD: [RFC9010] to enable the 6LR to inject the anycast and multicast addresses in RPL. Similarly, this specification extends [RFC8505] and [RFC9010] to add the capability for the 6LN to register unicast prefixes as opposed to addresses, and to signal in a routing-protocol-independent fashion to the 6LR that it is expected to redistribute the prefixes. NEW: [RFC9010] to enable a 6LR to inject the anycast and multicast addresses in RPL. Similarly, this specification extends [RFC8505] and [RFC9010] to add the capability for a 6LN to register unicast prefixes as opposed to addresses, and to signal in a routing-protocol-independent fashion to a 6LR that it is expected to redistribute the prefixes. There are other instances in the document that I think should be fixed as well. Cheers, Med ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
