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. > # 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. > > ### 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. > > ### 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? > ### Any reason why not any of the unassigned bits in the low range is used? > David’s point. RFC 7400 makes those bits experimental. > ## 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. 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 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 ? 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 > > >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
