I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-detnet-security-12 Reviewer: Russ Housley Review Date: 2020-10-19 IETF LC End Date: 2020-10-27 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: Abstract: Latency is discussed in the Abstract, but jitter does not come up until much later in the document. Section 1: Latency is discussed in the Introduction, but jitter does not come up until much later in the document. Section 4 says: "the DiffServ draft Security discussions". A reference is clearly missing. Looking at the list of documents associated with the DetNet WG, it is not clear what this is supposed to point to. Section 7.2 says: "hash-based Message Authentication Code (MAC)". Any MAC is useful here, not just hash-based ones. Please drop "hash-based". Minor Concerns: Section 5.1 says: "otherwise independent DetNet network domains are connected", but "domain" is not defined. I am guessing that a "domain" is a DetNet that has one administrator, but I am not sure. Also, I am not sure this detail is even relevant to the point of the paragraph. Maybe "otherwise independent DetNet networks are connected" would be adequate. Section 5.2.6 introduces the term "L3/L4 headers", and it is not really defined. Further this is not used outside of this section. I suggest that the section be reworded to avoid a new term that is not needed elsewhere. Section 6, Figure 2: It is unclear to me how block chain fits with the other things listed in this table. Does this list come from another document? If so, please provide that reference. Section 7.3 refers to "IPsec or MACsec". Please add references for both IPsec and MACsec. Section 7.5.1 refers to "TLS and IKE". Please add references for both TLS and IKE. Section 7.7 refers to "TSN". Please add references for TSN. Section 8.1.23 talks about "misbehaving component". I think it should be expanded to talk about more than one misbehaving component, and it should be clear whether the misbehavior can come from an adjacent component or it can be many hops away. Section 9 says: "... not a transport protocol (e.g., neither TCP nor UDP, etc.) ...". The real point here is that the identifier for the actual transport protocol that is being used is encrypted. Listing possible identifier values makes it harder to figure this out. Section 13: Please provide the same information in the same format for each of the contributors. Nits: Throughout: s/DetNet network/DetNet/ Abstract says: "This document also addresses DetNet security considerations specific to the IP and MPLS data plane technologies thereby complementing the Security Considerations sections of the various DetNet Data Plane (and other) DetNet documents." The last part of this sentence does not make sense to me; it has too many DetNets. Section 1 says: A general introduction to the DetNet architecture can be found in [RFC8655] and it is also recommended to be familiar with the DetNet Data Plane [I-D.ietf-detnet-data-plane-framework] and Flow Information Model [I-D.ietf-detnet-flow-information-model]. To avoid confusion with "recommended", I suggest: Readers can find a general introduction to the DetNet architecture in [RFC8655], the DetNet Data Plane in [I-D.ietf-detnet-data-plane-framework], and the Flow Information Model in [I-D.ietf-detnet-flow-information-model]. Section 1: s/of each packet's data'/of the data in each packet/ Section 3.1: s/BW/bandwidth/ Section 4: s/Security sections/Security Considerations sections/ Section 5.1: s/DetNet networking islands/DetNet islands/ Section 5.2.5.2: /"new"/new/ Section 5.3, Figure 1: Please fix the header of the table. Section 6: s/in the table below/in Figure 2/ Section 6.8: please spell out "time sync". Section 7.5: s/end-to- end encryption/end-to-end encryption/ Section 9: s/Layer-2/Layer 2/ IDnits reports: -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Suggestions: Throughout: Avoid possessive to aid readers whose first language is not English. For example, I suggest changing "component's data plane" to "data plane of the component". As another example, please change "flow's budget" to "budget for the flow". As yet another example, please change "the DetNet's handling of IT traffic" to "the handling of IT traffic in the DetNet". As a final example, please change "that network's data plane" to "the network data plane". There are many more uses of possessive, and I hope you will consider each one. Throughout: The authors use "this memo" and "this document". Please pick one and use it everywhere.