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. == # 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
