Dear Gunter Good to hear from you and many thanks for your review : )
I applied the changes you proposed to github as Gunter Van de Velde's No Objection on draft-ietf-6lo-prefix-registrat… · pthubert/6lo-prefix-registration@daa0417 <https://github.com/pthubert/6lo-prefix-registration/commit/daa041798e1fc5990a804be449e84d03b2a0bb47> Let us see below: Le mer. 4 juin 2025 à 17:42, Gunter Van de Velde via Datatracker < [email protected]> a écrit : > Gunter Van de Velde has entered the following ballot position for > draft-ietf-6lo-prefix-registration-12: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Gunter Van de Velde, RTG AD, comments for > draft-ietf-6lo-prefix-registration-12 > > # The line numbers used are rendered from IETF idnits tool: > > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6lo-prefix-registration-12.txt > > # Many thanks for this write up. It is a non-trivial update touching many > parts > in various specifications. It represents a significant amount of detailed > work. > > # when running idnits there disclaimer message is observed. I didn't see > this > addressed in the shepherd writeup. > > " > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If > you > have contacted all the original authors and they are all willing to > grant > the BCP78 rights to the IETF Trust, then this is fine, and you can > ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > https://trustee.ietf.org/license-info for more information.) > " > > Could be the updating RFC 4861 thingy. the updates RFC 4861 tag will be going with my next publication, which will include the changes in Github · pthubert/6lo-prefix-registration@dde1a90 <https://github.com/pthubert/6lo-prefix-registration/commit/dde1a903729546131610c7e18a838b2a3460e4e3> > # section 4 suggests amending RFC4861, section 5 suggest extending > RFC7400. But > section 6 describes "Updating RFC6550". How is Updating any different from > ammending or extending? Maybe that should be clarified in the section where > amending/Extending is described? (note that other sections use Updating > keyword) > Based on the other IESG reviews, the proposed change in Github · pthubert/6lo-prefix-registration@dde1a90 <https://github.com/pthubert/6lo-prefix-registration/commit/dde1a903729546131610c7e18a838b2a3460e4e3> is to use only updates (instead of Amends) and do not consider and Extends as an update. The way RFC 4861 is used also changes so it is not updated. > > # the text uses often the "*" to make a keyword appear *bold* in markdown. > When > reading that in text only it reads odd. Is that the intent? many tables are > exposed to this idnit > Thhat was a suggestion I followed. It is novcer in the new formats but quite ugly in text form if you ask me. We'll see what the RFC editor prefers. > > # Detailed Review > # =============== > > 234 *Amends/Amended by:* This tag pair is used with an amending > RFC that > 235 changes the amended RFC. This could include bug fixes, > 236 behavior changes etc. This is intended to specify > mandatory > 237 changes to the protocol. The goal of this tag pair is to > 238 signal to anyone looking to implement the amended RFC > that > 239 they MUST also implement the amending RFC. > 240 *Extends/Extended by:* This tag pair is used with an extending > RFC > 241 that defines an optional addition to the extended RFC. > This > 242 can be used by documents that use existing extension > points or > 243 clarifications that do not change existing protocol > behavior. > 244 This signals to implementers and protocol designers that > there > 245 are changes to the extended RFC that they need to > consider but > 246 not necessarily implement. > > GV> I found this not easy to fully understand. I tried to reword this. Does > this reworked definition work for you? > Sorry for your effort below Gunter. I removed all this altogether. Seems that the idea of updating the update tag went out of fashion. > > " > Amends / Amended by: > This tag pair is used when an RFC formally modifies the protocol behavior > defined in another RFC. Such modifications may include corrections, > updates to > normative behavior, or other substantive changes. The presence of this tag > pair > indicates that the amending RFC introduces mandatory changes to the amended > RFC. Implementers of the amended RFC MUST also implement the corresponding > changes described in the amending RFC. > > Extends / Extended by: > This tag pair is used when an RFC introduces an optional extension or > clarification to another RFC, without altering its existing normative > behavior. > Such extensions may utilize defined extension points or provide additional > informational content. The presence of this tag pair indicates that there > are > supplementary specifications or enhancements to consider. Implementation > of the > extending RFC is OPTIONAL, but protocol designers and implementers SHOULD > be > aware of its existence when working with the extended RFC. " > > 302 SND: Subnet Neighbor Discovery (protocol) > > GV> idnit observation. The other entries in this list have "*" to make the > keyword bold, but this SND keyword does accidently not have this > > Fixed > 324 otherwise therein, the behavior of the 6LBR that acts as RPL > Root, of > > GV> The "6LBR" seems forgotten within the terminology list > Fixed > > 473 [RFC9685] defines a 2-bits P-Field with values from 0 to 2, and > 474 reserves value 3. This specification defines value 3 for the > 475 P-Field, and uses it to signal that the Registered Address is a > 476 prefix. When the P-Field is set to 3, the receiver installs a > route > 477 to the prefix via the sender's address used as source address > in the > 478 NS(EARO) registration message. > 479 > 480 This specification assigns the value of 3, resulting in the > complete > 481 table as follows: > > GV> What about the following? (i sneaked in a normative MUST): > > " > [RFC9685] defines a 2-bit P-Field with values 0 through 2 and reserves the > value 3 for future use. This specification defines the semantics of P-Field > value 3. > > When the P-Field is set to 3, it indicates that the Registered Address > represents a prefix rather than a single address. Upon receiving an > NS(EARO) > message with the P-Field set to 3, the receiver MUST install a route to the > indicated prefix via the source address of the NS(EARO) message. > > This specification assigns the value 3 to the P-Field, resulting in the > following complete set of defined values: " > > Neat and adopted > 548 New and updated Option Fields: > 549 > 550 *F:* 1-bit flag; set to 1 to indicate that the sender expects > other > 551 routers to forward packets to self when the packets are > sourced > 552 within the registered prefix. > 553 > 554 *Prefix Length:* 7-bit integer; this field contains a prefix > length > 555 expressed in bits if the P-Field is set to 3 and the EARO is > 556 placed in an NS message. In that case the value MUST be > between > 557 16 and 120, both included. The field contains a Status if > the > 558 EARO is placed in an NA message regardless of the setting of > the P > 559 flag. In all other cases it is reserved, so it MUST be set > to 0 > 560 by the sender and ignored by the receiver. > 561 > 562 *r (reserved):* 1-bit reserved field; it MUST be set to zero > by the > 563 sender and MUST be ignored by the receiver. > > GV> What about: > > " > New and Updated Option Fields > > F (Forwarding Flag): > A 1-bit flag. When set to 1, it indicates that the sender expects other > routers > to forward packets to the sender when those packets are sourced from > within the > registered prefix. > > Prefix Length: > A 7-bit unsigned integer. When the P-Field is set to 3 and the EARO is > included > in a Neighbor Solicitation (NS) message, this field MUST contain a prefix > length expressed in bits, with a value between 16 and 120 inclusive. When > the > EARO is included in a Neighbor Advertisement (NA) message, this field MUST > carry a Status value, regardless of the setting of the P-Field. In all > other > cases, this field is reserved; it MUST be set to zero by the sender and > MUST be > ignored by the receiver. > > r (Reserved): > A 1-bit reserved field. It MUST be set to zero by the sender and MUST be > ignored by the receiver. " > > Neat and adopted > 598 New and updated Option Fields: > 589 > 600 *Reserved:* 6-bit field; reserved, MUST be set to 0 and > ignored by > 601 the receiver > 602 > 603 *Prefix:* 15 bytes field; carries up to 120 bits of prefix, > and MUST > 604 be padded with zeros. The padding MUST be overwritten with > zeros > 605 when the prefix is being used by the receiver. > 606 > 607 *r:* 1-bit field; reserved, MUST be set to 0 and ignored by the > 608 receiver > 609 > 610 *Prefix Length:* 7-bit integer; signals the length of the > prefix, in > 611 bits. The value MUST be at least 16 and at most 120. > > GV> What about: > > " > New and Updated Option Fields > > Reserved: > A 6-bit field reserved for future use. It MUST be set to zero by the > sender and > MUST be ignored by the receiver. > > Prefix: > A 15-byte field that carries up to 120 bits of the prefix. If the prefix is > shorter than 120 bits, the remaining bits MUST be padded with zeros. The > receiver MUST treat the padding as zeroed and MUST overwrite any unused > bits > with zeros before using the prefix. > > r (Reserved): > A 1-bit field reserved for future use. It MUST be set to zero by the > sender and > MUST be ignored by the receiver. > > Prefix Length: > A 7-bit unsigned integer indicating the length of the prefix in bits. The > value > MUST be in the inclusive range of 16 to 120. " > > Also very neat and adopted. > Many thanks for this document, > Gunter Van de Velde, > Routing AD > Many thanks to you Gunter! Pascal -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
