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.
<mailto: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<mailto:6lo@ietf.org>
To unsubscribe send an email to 6lo-le...@ietf.org<mailto: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.
_______________________________________________
6lo mailing list -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org
