Dear Med: Sorry for being slow here.
There were significant changes to look at and parallel discussions. I published 12 with my state of the discussion below Diff: draft-ietf-6lo-prefix-registration-11.txt - draft-ietf-6lo-prefix-registration-12.txt <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-prefix-registration-11&url2=draft-ietf-6lo-prefix-registration-12&difftype=--html> Please let me know if you feel we need more. Please see below for the details: Le lun. 2 juin 2025 à 11:45, <[email protected]> a écrit : > 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.* > I looked at it and found that I wouldn't want that text to be somewhere at the end. It would be a waste. On the other hand, a lot of this text falls effectively in operational considerations. Suggestion to rename all the sections and more the subsections in the new "Operational Considerations" section per your other recommendation. 12. Operational Considerations . . . . . . . . . . . . . . . . . 18 12.1. Partially Upgraded Networks . . . . . . . . . . . . . . 19 12.2. Application to RPL-Based Route-Over LLNs . . . . . . . . 19 12.3. Application to a Shared Link . . . . . . . . . . . . . . 21 12.4. Application to a Hub Link with Stub Spokes . . . . . . . 22 What do you think? > > > > > # 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.* > > > done > > ### 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.* > This conflicts with the discussion with Ketan We are leaning towards a picture as follows: 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 = 1 | Experimental |X|A|D|L|B|P|E|G| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Unassigned | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: New Capability Bit in the 6CIO Would that work, or should we create a common thread to reach an agreement? > > > ### 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.* > Fixed in the current version of the figure above. > > > ## 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.* > Neat idea. A bit late though, meaning we have many docs already, past RFCs that called this "reserved" and draft-ietf-6lo-updating-rfc-8928-04 <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-updating-rfc-8928-04> that we'd need to synchronize.Doable, for the latter, but not the formers. > > > C is an oversight from RFC 8928 that we are fixing with > draft-ietf-6lo-updating-rfc-8928-04 > <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-updating-rfc-8928-04#name-updating-rfc-8928> > > *[Med] Thanks for the clarification about. But what about I-flag?* > I is a 2bit integer defined in RFC 8505. We decided to summarize it all in draft-ietf-6lo-updating-rfc-8928-04 <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-updating-rfc-8928-04#name-updating-rfc-8928>, which you just reviewed (thanks for that :) ! ) > > > 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.* > done > > > Pascal > > > > > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Consistency with Your Own Terminology on Amend/Extend > > For example, > > OLD: 4. Updating RFC 4861 > NEW: 4. Amending RFC 4861 > > done. > # 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. > > I removed the update tag for RFC 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”? > > I added text " This specification Extends the EARO and EDAR messages to enable the registration of prefixes and Amends the Registration operation in the case of a prefix, in particular from the standpoint of the 6LR, e.g., to enable the Registration of overlapping prefixes. " and renamed section 7.4 to " 7.4. Amending the Registration Operation " > > # 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? > > Added section " 12.1. Partially Upgraded Networks . . . . . . . . . . ." > # 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. > > done, thanks! > > ### Large routing domain > > replaced "large" with "another" > > 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. > > Yes > # Introduction > > ### Stimulated > > CURRENT: > * Unicast host to router operations stimulated by the host and its > applications. > > What does "stimulated” mean here? Do we mean “triggered”? > > Yes > > ### (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. > > This was about the above mentioned nodes, thus the 'the' . I fixed a little bit to get: " [RFC6775] changes the classical IPv6 ND model to proactively establish the Neighbor Cache Entry (NCE) associated to the unicast address of a 6LoWPAN Node (6LN) in the 6LoWPAN Router(s) (6LRs) that serve it. To that effect, [RFC6775] defines a new Address Registration Option (ARO) that is placed in unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LN and the 6LRs. " > > 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. > > done > There are other instances in the document that I think should be fixed as > well. > > Trust the RFC editor on this! > > Cheers, > Med > > > ___________________ > > A great many thanks, 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. > > -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
