Telechat Review of draft-ietf-raw-technologies-13
review-ietf-raw-technologies-13-opsdir-telechat-boucadair-2025-01-20-00

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.
==

# 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.

# 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.

# 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/).

(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.

Cheers,
Med