Le lun. 20 janv. 2025 à 11:13, Mohamed Boucadair via Datatracker <noreply@xxxxxxxx> a écrit :
Reviewer: Mohamed Boucadair
Review result: Has Issues
Hi Authors,
Thank you for taking care of the main comments raised in my review of -10.
Thanks also to the Chairs for handling the LSes to IEEE/3GPP. I made a quick
search to see if there was any follow-up from these SDOs, but it seems no
feedback was received.
The statement that was introduced at the end of Section 1 is clear enough about
the scope of this document and motivates why OPS practices are not included.
This scope is reasonable, as already indicated in the first review. Thanks for
clarifying the scope and also the intended use of this document.
The authors made an effort to update many parts of the text to avoid stale
information. However, there are still some few parts that I think needs further
refresh. For example, I would simply delete
"[I-D.thubert-bier-replication-elimination] leverages" in Section 5.2.1.2.1 as
this individual I-D was never updated since 2018 or adopted in BIER (?). I
understand that the intent here is to provide an example of the gap mentioned
in the previous paragraph, but I'm afraid listing this old individual spec is
not helpful. BTW, this is already mentioned in RFC9030 (main ref in 5.2.1):
=
A.1.3. Using BIER in a 6TiSCH Network
BIER could also be used in the context of the DetNet service layer.
"BIER-TE extensions for Packet Replication and Elimination Function
(PREF) and OAM" [TE-PREF] leverages BIER Traffic Engineering (TE) to
control the DetNet Replication and Elimination activities in the data
plane, and to provide traceability on links where replication and
loss happen, in a manner that is abstract to the forwarding
information.
==
Makes sense, I removed that section. On the one hand it could have provided ideas to future engineering so it's a loss, but on the other hand progress in IPPM ensures that this sort of thinking survives.
[Med] Thanks for accommodating. I think that the provision we have in RFC9030 is sufficient to have that record.
# The split between Normative/Informative References is not trivial
For example,
CURRENT:
Moreover,
ISA100.11a introduces IPv6 [RFC8200] capabilities with a Link-Local
Address for the join process and a global unicast addres for later
ISA100.11a is listed as Informative, while [RFC8200] is listed as normative.
Please double check the classification of your references.
The ref to IPv6 is needed for beyond ISA100.11a, e.g., for RFC 9030. Yet, I agree with you that the reader does not needs to understand that spec deeply to process this document and I moved IPv6 to informative per my reading of your suggestion.
[Med] Thanks for making the change. I trust that you will check the other entries (IEEE Std 802.11 and so on) and move to normative those that are needed to understand this doc.
I consider this comment closed from my side.
# Downrefs
I see RFCs 8557 and 9030 listed as normative, while these are not listed in
https://datatracker.ietf.org/doc/downref.
The IETF LC
(https://mailarchive.ietf.org/arch/msg/detnet/eXSpZd4CSJ-FyAMkCAcdaQhDE8I/)
does not list these. I guess this is rooted in that idnits does not catch this
as well.
This spec is informational, so I'm not clear why this should be a downref.
[Med] That’s exactly the point of a downref. Please check rfc3967, fwiw.
My reading of normative in informational docs is that the normative ref is a necessary read to fully understand this doc.
Wrong? If so, Whose action is that? Chairs?
[Med] I guess this is for Roman.
# Nits
There are some other nits that need to be fixed. For example,
(1)
CURRENT:
Those technologies were selected as part of the WG
formation and listed in the WG charter.
I guess you meant the concluded RAW WG, not DETNET. I would be explicit here.
(2)
CURRENT:
As PIEEE 802.11bn is still in early stages of development
I guess you meant "P802.11bn" (https://standards.ieee.org/ieee/802.11bn/11393/).
change all typo. Many thanks for the catch!
(3)
OLD: Address for the join process and a global unicast addres for later
NEW: Address for the join process and a global unicast address for later
(4)
OLD:
. Most RAW technologies integrate some authentication or encryption
mechanisms that were defined outside the IETF.
NEW:
Most RAW technologies integrate some authentication or encryption
mechanisms that were defined outside the IETF.
Hope this helps.
A lot more than just help. Ab Fab review! MAny thanks Mohamed :)
Cheers,
Med
