Re-, I’m neutral on that one as the IANA registry is authoritative here. Leave it to you and Éric to decide when a tag on 8505 is suitable.
Thank you. Cheers, Med De : Adnan Rashid <[email protected]> Envoyé : mercredi 11 juin 2025 15:05 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : Pascal Thubert <[email protected]>; Eric Vyncke (evyncke) <[email protected]>; 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) By adding this table, I would like to add the following line This table also updates the Section 9.2<https://datatracker.ietf.org/doc/html/rfc8505#section-9.2>. "Address Registration Option I-Field" in RFC8505. Because this table is missing in RFC8505. What do you think? On Wed, Jun 11, 2025 at 2:22 PM <[email protected]<mailto:[email protected]>> wrote: Hi Adnan, Thanks for implementing the changes. Please find below two comments: # You may consider rewording the abstract as follows (fix some nits, be self-contained, etc.): OLD: This document updates RFC 8928 by changing the position for the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA. It also requests IANA to add a 2-bit integer for the I-field in the "Address Registration Option Flags" registry under ICMPv6 Parameters, as defined in RFC 8505. NEW: This document updates “Address-Protected Neighbor Discovery for Low-Power and Lossy Networks” (RFC 8928) by changing the position of the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA. The document also registers the I-Field, initially defined in “Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery” (RFC 8505), in the "Address Registration Option Flags" registry under the “ICMPv6 Parameters” registry group. # Please add this table to Section 6.2: NEW: +-------------+--------------+------------+ | Bit Number | Description | Reference | +-------------+--------------+------------+ | 4-5 | I-Field | [RFC8505] | +-------------+--------------+------------+ Table 2: I-Field ARO Fags You may also indicate that the values taken by the I-Field are defined in https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-adress-registration-option-flags. Cheers, Med De : Adnan Rashid <[email protected]<mailto:[email protected]>> Envoyé : mercredi 11 juin 2025 14:02 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>> Cc : Pascal Thubert <[email protected]<mailto:[email protected]>>; Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : Re: [6lo] Mohamed Boucadair's Discuss on draft-ietf-6lo-updating-rfc-8928-04: (with DISCUSS and COMMENT) CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. Hi Med, Thanks for acting as a reliable protocol. I like it. 😁 I added the Operational Consideration section as you suggested. Could you please see all the changes advised by the IESG? See the attached file Four things I changed mainly, 1- Draft name changed 2- Abstract changed 3- Added OP Consideration section 4- Added I-Field subsection in IANA Section If you agree then I will push the updated draft on the IETF. On Tue, Jun 10, 2025 at 7:25 PM <[email protected]<mailto:[email protected]>> wrote: Hi Adnan, Thanks for the follow-up. Please see inline. Cheers, Med De : Adnan Rashid <[email protected]<mailto:[email protected]>> Envoyé : mardi 10 juin 2025 18:31 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; Pascal Thubert <[email protected]<mailto:[email protected]>>; Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Cc : The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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. -- 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. -- 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]
