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 <mohamed.boucad...@orange.com> 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 <adnanrashi...@gmail.com> > *Envoyé :* mercredi 11 juin 2025 14:02 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > *Cc :* Pascal Thubert <pascal.thub...@gmail.com>; Eric Vyncke (evyncke) < > evyn...@cisco.com>; The IESG <i...@ietf.org>; > draft-ietf-6lo-updating-rfc-8...@ietf.org; 6lo-cha...@ietf.org; > 6lo@ietf.org; carles.go...@upc.edu > *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 <mohamed.boucad...@orange.com> wrote: > > Hi Adnan, > > > > Thanks for the follow-up. > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Adnan Rashid <adnanrashi...@gmail.com> > *Envoyé :* mardi 10 juin 2025 18:31 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Pascal > Thubert <pascal.thub...@gmail.com>; Eric Vyncke (evyncke) < > evyn...@cisco.com> > *Cc :* The IESG <i...@ietf.org>; draft-ietf-6lo-updating-rfc-8...@ietf.org; > 6lo-cha...@ietf.org; 6lo@ietf.org; carles.go...@upc.edu > *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. > > > <pascal.thub...@gmail.com> > > 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 -- 6lo@ietf.org > To unsubscribe send an email to 6lo-le...@ietf.org > > > > > -- > > 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
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
