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]>
Envoyé : mercredi 11 juin 2025 14:02
À : 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)
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.
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]
