Mohamed Boucadair has entered the following ballot position for draft-ietf-6lo-prefix-registration-11: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/ ---------------------------------------------------------------------- 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. # 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. ### None of the entries in that registry updates 7400. Any specific reason why are we deviating from that practice? ### 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 ### Any reason why not any of the unassigned bits in the low range is used? ## 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? ### 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. ---------------------------------------------------------------------- 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 _______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
