Dear Mohamed, Thanks for the comments and your time. As we already discussed in the IESG meeting My response is inline
> > # 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? > You are right. We wrote some text in the IANA Consideration section. > > > ---------------------------------------------------------------------- > 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. > <[email protected]> Since there is no known implementation there shouldn’t be any operational impact. > > # nits > > ## Title > > OLD: Fixing the C-Flag in EARO > NEW: Fixing the C-Flag in Extended Address Registration Option (EARO) > Done. But if the I-field needs to be fixed in the current document then we will revise it and let you know. > > ## Abstract > > ### I would delete “(AP-ND)” to be consistent with the title used in RFC > 8928 > > Done > ### > > OLD: updates .. by updating the position > > NEW: OLD: updates .. by changing the position > > Done > ## Section 3 > > OLD: Figure 1 below > NEW: Figure 1 > > Done > OLD: Figure 2 below > NEW: Figure 2 > > Done > ## 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. > > Done. > > > > > _______________________________________________ > 6lo mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Regards, Adnan
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
