Original text:
(queuing, policing, shaping) are supported using the underlying link / sub-net specific mechanisms.  Service protections (packet replication and packet elimination functions) are not provided at the <del> DetNet layer end to end due the lack of a unified end to end </del>  sequencing information that would be available for intermediate nodes.  However, such service protection can be provided on a per underlying L2 link and sub-network basis. interconnected by a TSN sub-network, being the primary focus of this document. <del> DetNet routers ensure that detnet service requirements are met per </del>  hop by allocating local resources, both receive and transmit, and by mapping the service requirements of each flow to appropriate sub- network mechanisms.  Such mappings are sub-network technology The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 Working Group have defined (and are defining) a number of amendments to IEEE8021Q that provide zero congestion loss and bounded latency in <del> bridged networks.  Furthermore IEEE8021CB defines frame replication </del>  and elimination functions for reliability that should prove both compatible with and useful to DetNet networks.  All these functions have to identify flows that require TSN treatment. TSN capabilities of the TSN sub-network are made available for IP <del> (DetNet) flows via the protocol interworking function defined in IEEE8021CB.  For example, applied on the TSN edge port it can convert an ingress unicast IP (DetNet) flow to use a specific Layer-2 multicast destination MAC address and a VLAN, in order to direct the packet through a specific path inside the bridged network.  A similar interworking function pair at the other end of the TSN sub-network would restore the packet to its original Layer-2 destination MAC address and VLAN. </del>  Placement of TSN functions depends on the TSN capabilities of nodes. IP (DetNet) Nodes may or may not support TSN functions.  For a given <del> TSN Stream (i.e., DetNet flow) an IP (DetNet) node is treated as a Talker or a Listener inside the TSN sub-network. </del>  4.1. Mapping of a DetNet IP flow to a TSN Stream is provided via the combination of a passive and an active stream identification function <del> that operate at the frame level.  The passive stream identification function is used to catch the 6-tuple of a DetNet IP flow and the active stream identification function is used to modify the Ethernet header according to ID of the mapped TSN Stream. IEEE8021CB defines an IP Stream identification function that can be used as a passive function for IP DetNet flows using UDP or TCP. IEEEP8021CBdb defines a Mask-and-Match Stream identification function that can be used as a passive function for any IP DetNet flows. IEEE8021CB defines an Active Destination MAC and VLAN Stream identification function, what can replace some Ethernet header fields namely (1) the destination MAC-address, (2) the VLAN-ID and (3) priority parameters with alternate values.  Replacement is provided for the frame passed down the stack from the upper layers or up the stack from the lower layers. </del>  Active Destination MAC and VLAN Stream identification can be used within a Talker to set flow identity or a Listener to recover the 4.2. This section covers required behavior of a TSN-aware DetNet node <del> using a TSN sub-network. </del>  From the TSN sub-network perspective DetNet IP nodes are treated as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. A TSN-aware IP (DetNet) node implementations MUST support the Sequencing function and the Sequence encode/decode function as <del> defined in IEEE8021CB if FRER is used inside the TSN sub-network. </del>  The Sequence encode/decode function MUST support the Redundancy tag (R-TAG) format as per Clause 7.8 of IEEE8021CB. A TSN-aware IP (DetNet) node implementations MUST support the Stream splitting function and the Individual recovery function as defined in <del> IEEE8021CB when the node is a replication or elimination point for FRER. </del>  4.3. TSN Streams supporting DetNet flows may use Frame Replication and <del> Elimination for Redundancy (FRER) as defined in IEEE8021CB based on the loss service requirements of the TSN Stream, which is derived from the DetNet service requirements of the DetNet mapped flow.  The specific operation of FRER is not modified by the use of DetNet and follows IEEE8021CB. </del>  FRER function and the provided service recovery is available only within the TSN sub-network as the TSN Stream-ID and the TSN sequence perspective there is no practical difference based on the origin of flow mapping related information (management plane or control plane).  TSN-aware IP DetNet nodes are member of both the DetNet domain and the TSN sub-network.  Within the TSN sub-network the TSN-aware IP (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific ones.  DetNet flow ID and flow related parameters/requirements must be converted to a TSN Stream ID and stream related parameters/ requirements.  Note that, as the TSN sub-network is just a portion of <del> the end2end DetNet path (i.e., single hop from IP perspective), some parameters (e.g., delay) may differ significantly.  Other parameters (like bandwidth) also may have to be tuned due to the L2 </del>  encapsulation used within the TSN sub-network. In some case it may be challenging to determine some TSN Stream 6. <del> The security considerations of DetNet in general are discussed in RFC8655 and I-D.ietf-detnet-security.  DetNet IP data plane specific considerations are summarized in I-D.ietf-detnet-ip.  Encryption may provided by an underlying sub-net using MACSec IEEE802.1AE-2018 for DetNet IP over TSN flows. </del>  7.

Reviewer comments:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)

Revised text:
(queuing, policing, shaping) are supported using the underlying link / sub-net specific mechanisms.  Service protections (packet replication and packet elimination functions) are not provided at the  <ins> DetNet layer end-to-end due the lack of a unified end-to-end </ins> sequencing information that would be available for intermediate nodes.  However, such service protection can be provided on a per underlying L2 link and sub-network basis. interconnected by a TSN sub-network, being the primary focus of this document.  <ins> DetNet routers ensure that DetNet service requirements are met per </ins> hop by allocating local resources, both receive and transmit, and by mapping the service requirements of each flow to appropriate sub- network mechanisms.  Such mappings are sub-network technology The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 Working Group have defined (and are defining) a number of amendments to IEEE8021Q that provide zero congestion loss and bounded latency in  <ins> bridged networks.  Furthermore, IEEE8021CB defines frame replication </ins> and elimination functions for reliability that should prove both compatible with and useful to DetNet networks.  All these functions have to identify flows that require TSN treatment. TSN capabilities of the TSN sub-network are made available for IP  <ins> (DetNet) flows via the protocol interworking function desribed in Annex C.5 of IEEE8021CB.  For example, applied on the TSN edge port it can convert an ingress unicast IP (DetNet) flow to use a specific Layer-2 multicast destination MAC address and a VLAN, in order to direct the packet through a specific path inside the bridged network. A similar interworking function pair at the other end of the TSN sub- network would restore the packet to its original Layer-2 destination MAC address and VLAN. </ins> Placement of TSN functions depends on the TSN capabilities of nodes. IP (DetNet) Nodes may or may not support TSN functions.  For a given  <ins> TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is treated as a Talker or a Listener inside the TSN sub-network. </ins> 4.1. Mapping of a DetNet IP flow to a TSN Stream is provided via the combination of a passive and an active stream identification function  <ins> that operate at the frame level (Layer-2).  The passive stream identification function is used to catch the 6-tuple of a DetNet IP flow and the active stream identification function is used to modify the Ethernet header according to the ID of the mapped TSN Stream. Clause 6.7 of IEEE8021CB defines an IP Stream identification function that can be used as a passive function for IP DetNet flows using UDP or TCP.  Clause 6.8 of IEEEP8021CBdb defines a Mask-and-Match Stream identification function that can be used as a passive function for any IP DetNet flows. Clause 6.6 of IEEE8021CB defines an Active Destination MAC and VLAN Stream identification function, what can replace some Ethernet header fields namely (1) the destination MAC-address, (2) the VLAN-ID and (3) priority parameters with alternate values.  Replacement is provided for the frame passed down the stack from the upper layers or up the stack from the lower layers. </ins> Active Destination MAC and VLAN Stream identification can be used within a Talker to set flow identity or a Listener to recover the 4.2. This section covers required behavior of a TSN-aware DetNet node  <ins> using a TSN sub-network.  The implementation of TSN packet processing functions MUST be compliant with the relevant IEEE 802.1 standards. </ins> From the TSN sub-network perspective DetNet IP nodes are treated as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. A TSN-aware IP (DetNet) node implementations MUST support the Sequencing function and the Sequence encode/decode function as  <ins> defined in Clause 7.4 and 7.6 of IEEE8021CB if FRER is used inside the TSN sub-network. </ins> The Sequence encode/decode function MUST support the Redundancy tag (R-TAG) format as per Clause 7.8 of IEEE8021CB. A TSN-aware IP (DetNet) node implementations MUST support the Stream splitting function and the Individual recovery function as defined in  <ins> Clause 7.7 and 7.5 of IEEE8021CB when the node is a replication or elimination point for FRER. </ins> 4.3. TSN Streams supporting DetNet flows may use Frame Replication and  <ins> Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE8021CB based on the loss service requirements of the TSN Stream, which is derived from the DetNet service requirements of the DetNet mapped flow.  The specific operation of FRER is not modified by the use of DetNet and follows IEEE8021CB. </ins> FRER function and the provided service recovery is available only within the TSN sub-network as the TSN Stream-ID and the TSN sequence perspective there is no practical difference based on the origin of flow mapping related information (management plane or control plane). <ins> The following summarizes the set of information that is needed to configure DetNet IP over TSN: DetNet IP related configuration information according to the DetNet role of the DetNet IP node, as per I-D.ietf-detnet-ip. TSN related configuration information according to the TSN role of the DetNet IP node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. Mapping between DetNet IP flow(s) (as flow identification defined in I-D.ietf-detnet-ip, it is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields) and TSN Stream(s) (as stream identification information defined in IEEE8021CB and IEEEP8021CBdb).  Note, that managed objects for TSN Stream identification can be found in IEEEP8021CBcv. This information MUST be provisioned per DetNet flow. </ins> TSN-aware IP DetNet nodes are member of both the DetNet domain and the TSN sub-network.  Within the TSN sub-network the TSN-aware IP (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific ones.  DetNet flow ID and flow related parameters/requirements must be converted to a TSN Stream ID and stream related parameters/ requirements.  Note that, as the TSN sub-network is just a portion of  <ins> the end-to-end DetNet path (i.e., single hop from IP perspective), some parameters (e.g., delay) may differ significantly.  Other parameters (like bandwidth) also may have to be tuned due to the L2 </ins> encapsulation used within the TSN sub-network. In some case it may be challenging to determine some TSN Stream 6.  <ins> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  DetNet IP data plane specific considerations are summarized in I-D.ietf-detnet-ip.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/ TSN services are provided by a sub-network may supply information that can be used in a variety of security attacks.  The ability to modify information exchanges between connected DetNet nodes may result in bogus operations.  Therefore, it is important that the interface between DetNet nodes and TSN sub-network are subject to authorization, authentication, and encryption. The TSN sub-network operates at Layer-2 so various security mechanisms defined by IEEE can be used to secure the connection between the DetNet nodes (e.g., encryption may be provided using MACSec IEEE802.1AE-2018). </ins> 7.