Original text:
interconnect TSN nodes/network segments.  DetNet MPLS data plane is defined in I-D.ietf-detnet-mpls. 2. 2.1. 2.2. <del> [Editor's note: text to be cleaned up]. </del> The following abbreviations are used in this document: Attachment Circuit. also support the imposition and disposition of the required DetNet encapsulation.  These are functionally similar to pseudowire (PW) Terminating Provider Edge (T-PE) nodes which use MPLS-TE LSPs.  In <del> this example they understand and support IEEE 802.1 TSN and are able to map TSN Streams into DetNet flows.  The specific of this operation are discussed later in this document. </del>  In this example, edge nodes provide a service proxy function that "associates" the DetNet flows and native flows (i.e., TSN Streams) at <del> the edge of the DetNet domain.  This ensures that the DN Flow is properly served at the Edge node (and inside the domain). </del>  fig_8021_detnet illustrates how DetNet can provide services for IEEE 802.1 TSN end systems, CE1 and CE2, over a DetNet enabled MPLS 5.2. The Service Proxy function maps between App-flows and DetNet flows. <del> It MUST support the TSN Stream identification functions and the related managed objects as defined in IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets. </del>  Implementations of this document SHALL use management and control information to map a TSN Stream to a DetNet flow.  N:1 mapping <del> (aggregating TSN Streams in a single DetNet flow) SHALL be supported. The management or control function that provisions flow mapping SHALL ensure that adequate resources are allocated and configured to provide proper service requirements of the mapped flows. </del>  Due to the (intentional) similarities of the DetNet PREOF and TSN FRER functions service protection function interworking is possible from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking is out-of-scope in this document and left for further study.  5.3. In the design of I-D.ietf-detnet-mpls an MPLS service label (the 6. <del> [Editor's note: This section covers management/control plane related implications of creation, mapping, removal of DetNet flow IDs, their related parameters and, when needed, the configuration of PREOF.] </del> TSN Stream(s) to DetNet flow mapping related information are required only for the service proxy function of MPLS (DetNet) Edge nodes. From the Data Plane perspective there is no practical difference Therefore management and control plane design is an important aspect of scenarios, where mapping between DetNet and TSN is required.  In order to use a DetNet network to interconnect TSN segments, TSN specific information must be converted to DetNet domain specific ones.  TSN Stream ID(s) and stream(s) related parameters/requirements must be converted to a DetNet flow-ID and flow related parameters/ <del> requirements.  Note that, as the DetNet network is just a portion of the end2end TSN path (i.e., single hop from Ethernet perspective), some parameters (e.g., delay) may differ significantly.  Other parameters (like bandwidth) also may have to be tuned due to the MPLS encapsulation used within the DetNet network. </del>  In some case it may be challenging to determine some egress node related information.  For example, it may be not trivial to locate 7. <del> The security considerations of DetNet in general are discussed in I- D.ietf-detnet-architecture and I-D.ietf-detnet-security.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet- mpls.  Encryption may provided within the TSN network using MACSec IEEE802.1AE-2018. </del>  8.

Reviewer comments:
Work In progress - Wanted to get the figure changes out for review. Need to check if the overly wording is complete. There was a lot of inter working text - I have commented out.

Revised text:
interconnect TSN nodes/network segments.  DetNet MPLS data plane is defined in I-D.ietf-detnet-mpls. 2. 2.1. 2.2.  The following abbreviations are used in this document: Attachment Circuit. also support the imposition and disposition of the required DetNet encapsulation.  These are functionally similar to pseudowire (PW) Terminating Provider Edge (T-PE) nodes which use MPLS-TE LSPs.  In  <ins> this example TSN Streams are simple applicaions over DetNet flows. The specific of this operation are discussed later in this document. </ins> In this example, edge nodes provide a service proxy function that "associates" the DetNet flows and native flows (i.e., TSN Streams) at  <ins> the edge of the DetNet domain.  TSN streams are treated as App-flows for DetNet.  The whole DetNet domain behaves as a TSN relay node for the TSN streams.  The service proxy behaves as a port of that TSN relay node. </ins> fig_8021_detnet illustrates how DetNet can provide services for IEEE 802.1 TSN end systems, CE1 and CE2, over a DetNet enabled MPLS 5.2. The Service Proxy function maps between App-flows and DetNet flows.  <ins> The DetNet Edge Node TSN function MUST support the TSN Stream identification functions and the related managed objects as defined in IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets.  The Service Proxy presents TSN Streams as an App-flow to a DetNet Flow. </ins> Implementations of this document SHALL use management and control information to map a TSN Stream to a DetNet flow.  N:1 mapping  <ins> (aggregating multiple TSN Streams in a single DetNet flow) SHALL be supported.  The management or control function that provisions flow mapping SHALL ensure that adequate resources are allocated and configured to provide proper service requirements of the mapped flows. </ins> Due to the (intentional) similarities of the DetNet PREOF and TSN FRER functions service protection function interworking is possible from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking is out-of-scope in this document and left for further study. <ins> A MPLS DetNet flow is configured to carry any number of TSN flows. The DetNet flow specific bandwidth profile SHOULD match the required bandwidth of the App-flow aggregate. </ins> 5.3. In the design of I-D.ietf-detnet-mpls an MPLS service label (the 6.  TSN Stream(s) to DetNet flow mapping related information are required only for the service proxy function of MPLS (DetNet) Edge nodes. From the Data Plane perspective there is no practical difference Therefore management and control plane design is an important aspect of scenarios, where mapping between DetNet and TSN is required. <ins> Note that, as the DetNet network is just a portion of the end to end TSN path (i.e., single hop from Ethernet perspective), some parameters (e.g., delay) may differ significantly.  Since there is no interworking function the bandwidth of DetNet network is assumed to be set large enough to handle all TSN Flows it will support.  At the egress of the Detnet Domain the MPLS headers are stripped and the TSN flow continues on as a normal TSN flow. </ins> In order to use a DetNet network to interconnect TSN segments, TSN specific information must be converted to DetNet domain specific ones.  TSN Stream ID(s) and stream(s) related parameters/requirements must be converted to a DetNet flow-ID and flow related parameters/  <ins> requirements. </ins> In some case it may be challenging to determine some egress node related information.  For example, it may be not trivial to locate 7.  <ins> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in I-D.ietf-detnet-architecture.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet-mpls.  The primary considerations for the data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network.  Application flows can be protected through whatever means is provided by the underlying technology.  For example, encryption may be used, such as that provided by IPSec RFC4301 for IP flows and/or by an underlying sub-net using MACSec IEEE802.1AE-2018 for IP over Ethernet (Layer-2) flows. </ins> 8.