Adnan and Pascal, Please submit a revised I-D incorporating all the changes below as they were ack’ed by Med. I also strongly suggest adding the text suggested by Med about the operational considerations about absence of known RFC 8928 deployment. This would probably allow Med to clear his DISCUSS.
About the other issue, the “I” field in EARO, let’s keep this out of this document, but I will request IANA to fix the registry: I do not think we need a formal document as it is already in RFC 8505 (albeit not in the IANA section), i.e., there is already “IETF review” (I will put Med and 6LO WG in copy of my request to IANA). Regards, -éric From: [email protected] <[email protected]> Date: Tuesday, 10 June 2025 at 19:25 To: Adnan Rashid <[email protected]>, Pascal Thubert <[email protected]>, Eric Vyncke (evyncke) <[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: [6lo] Mohamed Boucadair's Discuss on draft-ietf-6lo-updating-rfc-8928-04: (with DISCUSS and COMMENT) Hi Adnan, Thanks for the follow-up. Please see inline. Cheers, Med De : Adnan Rashid <[email protected]> Envoyé : mardi 10 juin 2025 18:31 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Pascal Thubert <[email protected]>; Eric Vyncke (evyncke) <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: [6lo] Mohamed Boucadair's Discuss on draft-ietf-6lo-updating-rfc-8928-04: (with DISCUSS and COMMENT) 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. [Med] ACK. Thanks. ---------------------------------------------------------------------- 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. <mailto:[email protected]> Since there is no known implementation there shouldn’t be any operational impact. [Med] Please say so explicitly in that section. For example, you can add the following: NEW: X. Operational Considerations The updates introduced in this document are not backward compatible. However, given that there are no known implementations or deployments of [RFC 8928], this document do not require any transition plan. # 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. [Med] Agree. ## Abstract ### I would delete “(AP-ND)” to be consistent with the title used in RFC 8928 Done [Med] ACK ### OLD: updates .. by updating the position NEW: OLD: updates .. by changing the position Done [Med] ACK ## Section 3 OLD: Figure 1 below NEW: Figure 1 Done [Med] ACK OLD: Figure 2 below NEW: Figure 2 Done [Med] ACK ## 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. [Med] ACK _______________________________________________ 6lo mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Regards, Adnan ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
