Thanks for the consideration of my observations. Be well, G/
Sent from Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Pascal Thubert <[email protected]> Sent: Friday, June 6, 2025 6:21:55 PM To: Gunter van de Velde (Nokia) <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Gunter Van de Velde's No Objection on draft-ietf-6lo-prefix-registration-12: (with COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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]<mailto:[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]
