I’d rather we ask IANA with this draft so we are clean… Mes we owe you one! Remind me in Madrid :)
A bientôt; Pascal > Le 5 juin 2025 à 15:27, Eric Vyncke (evyncke) <[email protected]> a écrit : > > > 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]
