Submitted. On Thu, Jun 26, 2025 at 2:08 PM Eric Vyncke (evyncke) <[email protected]> wrote:
> 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. > > > <[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] > To unsubscribe send an email to [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
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
