Med, It seems that you are correct: the ‘Address Registration Option Flags’ registry should have bits 4-5 reserved for the I-field per RFC 8505 section 9.2.
So, the IANA consideration of this draft should indeed also update these bits (or this could be done by IANA on its own ?) -éric From: Mohamed Boucadair via Datatracker <[email protected]> Date: Wednesday, 4 June 2025 at 14:05 To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Mohamed Boucadair's Discuss on draft-ietf-6lo-updating-rfc-8928-04: (with DISCUSS and COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-6lo-updating-rfc-8928-04: 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-updating-rfc-8928/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Pascal & Adnan, Thanks for the effort put into this specification. Thanks to Samier Barguil for the OPSDIR review and the authors for engaging and converging with Samier. # DISCUSS ## I-Flag CURRENT: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |r|C| P | I |R|T| TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Seems I-flag was defined in Section 4.1 of RFC 8505 which has the following: CURRENT: I: 2-bit integer. A value of 0 indicates that the Opaque field carries an abstract index that is used to decide in which routing topology the address is expected to be injected. In that case, the Opaque field is passed to a routing process with the indication that it carries topology information, and the value of 0 indicates default. All other values of "I" are reserved and MUST NOT be used. R: The Registering Node sets the R flag to request reachability services for the Registered Address from a Routing Registrar. T: 1-bit flag. Set if the next octet is used as a TID. While IANA section of RFC 8505 has the following: The initial contents of the registry are shown in Table 2. +-------------+--------------+------------+ | ARO Status | Description | Reference | +-------------+--------------+------------+ | 0-5 | Unassigned | | | | | | | 6 | R Flag | RFC 8505 | | | | | | 7 | T Flag | RFC 8505 | +-------------+--------------+------------+ Table 2: New Address Registration Option Flags I don’t see that flag in thee IANA registry. Maybe I'm looking in the wrong place. Should that be fixed as well? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # OPS Implications The introduction says: CURRENT: This specification updates [RFC8928] by repositioning the C-flag as bit 1 of the EARO flags field, thereby preventing conflicts. Are there known implementations/deployments? What are the implications of this change? Please consider adding those in an Operational considerations Section. # nits ## Title OLD: Fixing the C-Flag in EARO NEW: Fixing the C-Flag in Extended Address Registration Option (EARO) ## Abstract ### I would delete “(AP-ND)” to be consistent with the title used in RFC 8928 ### OLD: updates .. by updating the position NEW: OLD: updates .. by changing the position ## Section 3 OLD: Figure 1 below NEW: Figure 1 OLD: Figure 2 below NEW: Figure 2 ## Section 5.1 The IANA action is sufficient in its own, no need to be redundant. I would delete the following: This specification updates the location of the C-flag introduced in [RFC8928] to position it as bit 1 in the EARO flags field. Cheers, Med
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
