These requirements are satisfied by the DetNet over MPLS Encapsulation described in I-D.ietf-detnet-mpls and they are partly <del> satisfied by the DetNet IP data plane defined in I-D.ietf-detnet-ip </del>  2. Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing I-D.ietf-6man-segment-routing-header. <del> S-Labels, d-CW and zero or more F-Labels are used as defined in I- D.ietf-detnet-mpls and are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it too is not modified. </del>  4. member flows, and each member flow will require the provisioning of their own UDP and IP header information.  The headers for each outgoing packet MUST be formatted according to the configuration <del> information and as defined in RFC7510, with one exception.  Note that the UDP Source Port value MUST be set to uniquely identify the DetNet flow.  The packet MUST then be handed as a DetNet IP packet, per I- D.ietf-detnet-ip.  This includes QoS related traffic treatment. To support receive processing an implementation MUST also support the provisioning of received UDP and IP header information.  The provisioned information MUST be used to identify incoming app-flows based on the combination of S-Label and incoming encapsulation header information.  Normal receive processing as defined in I-D.ietf- detnet-mpls, including PEF and POF, can then take place. </del>  5. The following summarizes the set of information that is needed to configure DetNet MPLS over UDP/IP: <del> Label information (S-label or F-label) to be mapped to UDP/IP flow.  Note that a single S-Label can map to multiple sets of UPD/ IP information when PREOF is used. </del>  IPv4 or IPv6 source address field. IPv4 or IPv6 destination address field. <del> IPv4 Type of Service or IPv6 Traffic Class Fields. </del>  UDP Source Port. UDP Destination Port. This information MUST be provisioned per DetNet flow via <del> configuration, e.g., via the controller or management plane. </del>  It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific <del> resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and </del>  individual flows. 6.

IESG review comments resolved in this version
MPLSoUDP
MPLSoUDP: all 01-27 changes done.
can be merged once comments integrater, per Jan 27th meeting

These requirements are satisfied by the DetNet over MPLS Encapsulation described in I-D.ietf-detnet-mpls and they are partly  <ins> satisfied (i.e., IP flows can be identified however no DetNet sequence number is carried) by the DetNet IP data plane defined in I- D.ietf-detnet-ip </ins> 2. Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing I-D.ietf-6man-segment-routing-header.  <ins> S-Labels, A-Labels (when present), d-CW and zero or more F-Labels are used as defined in I-D.ietf-detnet-mpls and are not modified by this document. </ins> 4. member flows, and each member flow will require the provisioning of their own UDP and IP header information.  The headers for each outgoing packet MUST be formatted according to the configuration  <ins> information and as defined in RFC7510, and the UDP Source Port value MUST be set to uniquely identify the DetNet flow.  The packet MUST then be handled as a DetNet IP packet, per I-D.ietf-detnet-ip.  This includes QoS related traffic treatment. To support the receive processing defined in this document, an implementation MUST also support the provisioning of received UDP and IP header information.  The provisioned information MUST be used to identify incoming app-flows based on the combination of S-Label and incoming encapsulation header information.  Normal receive processing as defined in I-D.ietf-detnet-mpls, including PEF and POF, can then take place. </ins> 5. The following summarizes the set of information that is needed to configure DetNet MPLS over UDP/IP:  <ins> Label information (A-labels, S-labels and F-labels) to be mapped to UDP/IP flow.  Note that for example, a single S-Label can map to multiple sets of UDP/IP information when PREOF is used. </ins> IPv4 or IPv6 source address field. IPv4 or IPv6 destination address field.  <ins> DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class Fields. </ins> UDP Source Port. UDP Destination Port. This information MUST be provisioned per DetNet flow via  <ins> configuration, e.g., via the controller RFC8655 or management plane. </ins> It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific  <ins> resources needed to provide the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and </ins> individual flows. 6.


This document uses the terminology established in the DetNet architecture RFC8655 and the the DetNet Data Plane Framework I- D.ietf-detnet-data-plane-framework.  The reader is assumed to be <del> familiar with these documents and any terminology defined therein. </del>  The following terminology is introduced in this document: necessary ensure that in high speed networks the sequence number space does not wrap whilst packets are in flight. <del> The LSP used to forward the DetNet packet may be of any type (MPLS- LDP, MPLS-TE, MPLS-TP RFC5921, or MPLS-SR I-D.ietf-spring-segment- routing-mpls).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters.  Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service. </del>  4.2. A DetNet control word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in fig_detnet_cw MUST be present in all DetNet packets containing app- <del> flow data. </del>  the Associated Channel mechanism, and to the DetNet work on OAM for more information DetNet OAM.  4.4. The ability to aggregate individual flows, and their associated 6. <del> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  This section considers exclusively security considerations which are specific to the DetNet MPLS data plane. </del>  Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are

Fixing the comments received during the IESG review.
MPLS document
MPLS: All 01-27 changes updated
Done

This document uses the terminology established in the DetNet architecture RFC8655 and the the DetNet Data Plane Framework I- D.ietf-detnet-data-plane-framework.  The reader is assumed to be  <ins> familiar with these documents, any terminology defined therein and basic MPLS related terminologies in RFC3031. </ins> The following terminology is introduced in this document: necessary ensure that in high speed networks the sequence number space does not wrap whilst packets are in flight.  <ins> The LSP used to forward the DetNet packet is not restricted regarding any method used for establishing that LSP (for example, MPLS-LDP, MPLS-TE, MPLS-TP RFC5921, MPLS-SR RFC8660, etc.).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters.  Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service. </ins> 4.2. A DetNet control word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in fig_detnet_cw MUST be present in all DetNet packets containing app-  <ins> flow data.  This format of the d-CW was created in order (1) to allow larger S/N space to avoid S/N rollover frequency in some applications and (2) to allow non-skip zero S/N what simplifies implementation. </ins> the Associated Channel mechanism, and to the DetNet work on OAM for more information DetNet OAM. <ins> Additional considerations on DetNet-specific OAM are subjects for further study. </ins> 4.4. The ability to aggregate individual flows, and their associated 6.  <ins> General security considerations are described in RFC8655. Additionally, security considerations and a threat analysis are described in I-D.ietf-detnet-security.  This section considers exclusively security considerations which are specific to the DetNet MPLS data plane. </ins> Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are


<del> An unsigned value implementing the DetNet sequence number. </del>  A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet app-flow.  The following sequence

IESG review comment resolutions in this version: DONE Sabrina Tanamal, IANA, (03-12), OK Michael Tüxen, (03-15), Ready with Issues: Seq.Num.Space Shwetha Bhandari, (03-13), Ready TO BE DISCUSSED: Security section Watson Ladd, SecDir, (03-11), Not Ready Uri Blumenthal, (03-13), Security Deborah, (04-09), decrease authors to 6 !!!
reviewed in April 22 meeting

<ins> An unsigned value implementing the DetNet sequence number.  The sequence number space is a circular one. </ins> A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet app-flow.  The following sequence


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

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

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


TSN capabilities of the TSN sub-network are made available for MPLS (DetNet) flows via the protocol interworking function defined in <del> IEEE8021CB.  For example, applied on the TSN edge port it can convert an ingress unicast MPLS (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. MPLS (DetNet) Nodes may or may not support TSN functions.  For a the active stream identification function is used to modify the Ethernet header according to the ID of the mapped TSN Stream. <del> IEEEP8021CBdb defines a Mask-and-Match Stream identification function that can be used as a passive function for MPLS DetNet flows. </del>  <del> 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 MPLS (DetNet) <del> node using a TSN sub-network. </del>  From the TSN sub-network perspective MPLS (DetNet) nodes are treated as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. A TSN-aware MPLS (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 MPLS (DetNet) node implementations MUST support the Stream splitting function and the Individual recovery function as <del> defined in 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 MPLS DetNet nodes are member of both the DetNet domain and the TSN sub-network.  Within the TSN sub-network the TSN-aware MPLS (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 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.

TSN capabilities of the TSN sub-network are made available for MPLS (DetNet) flows via the protocol interworking function defined in  <ins> Annex C.5 of IEEE8021CB.  For example, applied on the TSN edge port it can convert an ingress unicast MPLS (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. MPLS (DetNet) Nodes may or may not support TSN functions.  For a the active stream identification function is used to modify the Ethernet header according to the ID of the mapped TSN Stream.  <ins> Clause 6.8 of IEEEP8021CBdb defines a Mask-and-Match Stream identification function that can be used as a passive function for MPLS DetNet flows. </ins>  <ins> 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 MPLS (DetNet)  <ins> node 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 MPLS (DetNet) nodes are treated as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. A TSN-aware MPLS (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 MPLS (DetNet) node implementations MUST support the Stream splitting function and the Individual recovery function as  <ins> defined in 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 MPLS over TSN: DetNet MPLS related configuration information according to the DetNet role of the DetNet MPLS node, as per I-D.ietf-detnet-mpls. TSN related configuration information according to the TSN role of the DetNet MPLS node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. Mapping between DetNet MPLS flow(s) (label information: A-labels, S-labels and F-labels as defined in I-D.ietf-detnet-mpls) and TSN Stream(s) (as stream identification information defined in 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 MPLS DetNet nodes are member of both the DetNet domain and the TSN sub-network.  Within the TSN sub-network the TSN-aware MPLS (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 6.  <ins> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet-mpls.  This section considers exclusively security considerations which are specific to the DetNet MPLS 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.


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 TSN Streams are simple applicaions over DetNet flows. </del>  The specific of this operation are discussed later in this document. In this example, edge nodes provide a service proxy function that 4.2. <del> The basic encapsulation approach is to treat a TSN Stream as an app- </del>  flow from the DetNet MPLS perspective.  The corresponding example shown in fig_tsn_mpls_ex. bridged networks.  IEEE8021CB defines packet replication and elimination functions for a TSN network.  TSN specific functions are executed on the data received by the DetNet Edge Node from the connected CE before forwarded to connected CE(s) or presentation to the DetNet Service Proxy function for DetNet PW by a PE before it is output on the Attachment Circuit(s) (AC). <del> TSN specific function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) RFC3985 block.  This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, overwriting or adding VLAN tags, etc.).  Depending on the TSN role of the Edge Node in the end-to-end TSN service selected TSN functions must be supported. </del>  When a PE receives a packet from a CE, on a given AC with DetNet <del> service, it MUST first check via Stream Identification whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream-ID specific TSN functions MUST be executed (e.g., ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </del>  If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected CE(s) flooding the PE MUST drop the packet. When a TSN entity of the PE receives a packet from the DetNet Service <del> Proxy, it MUST first check via Stream Identification whether the packet belongs to a configured TSN Stream.  If no Stream ID is matched then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions MUST be executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </del>  If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected The Service Proxy function maps between App-flows and DetNet flows. The DetNet Edge Node TSN entity MUST support the TSN Stream identification functions and the related managed objects as defined <del> 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. </del>  When a DetNet Service Proxy receives a packet from the TSN Entity it MUST check whether such an App-flow is present in its mapping table. based on the origin of flow mapping related information (management plane or control plane).  MPLS DetNet Edge nodes are member of both the DetNet domain and the connected TSN network.  From the TSN network perspective the MPLS (DetNet) Edge node has a "TSN relay node" role, so TSN specific Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are <del> described in RFC8655.  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. </del>  8.

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 applications over DetNet flows. </ins> The specific of this operation are discussed later in this document. In this example, edge nodes provide a service proxy function that 4.2.  <ins> The basic encapsulation approach is to treat a TSN Stream as an App- </ins> flow from the DetNet MPLS perspective.  The corresponding example shown in fig_tsn_mpls_ex. bridged networks.  IEEE8021CB defines packet replication and elimination functions for a TSN network. <ins> The implementation of TSN entity (i.e., TSN packet processing functions) MUST be compliant with the relevant IEEE 802.1 standards. </ins> TSN specific functions are executed on the data received by the DetNet Edge Node from the connected CE before forwarded to connected CE(s) or presentation to the DetNet Service Proxy function for DetNet PW by a PE before it is output on the Attachment Circuit(s) (AC).  <ins> TSN packet processing function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) RFC3985 block.  This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, overwriting or adding VLAN tags, etc.).  Depending on the TSN role of the Edge Node in the end-to-end TSN service selected TSN functions are supported. </ins> When a PE receives a packet from a CE, on a given AC with DetNet  <ins> service, it MUST first check via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream-ID specific TSN functions MUST be executed (e.g., ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </ins> If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected CE(s) flooding the PE MUST drop the packet. When a TSN entity of the PE receives a packet from the DetNet Service  <ins> Proxy, it MUST first check via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream.  If no Stream ID is matched then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions MUST be executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.). Source MAC lookup MAY also be used for local MAC address learning. </ins> If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected The Service Proxy function maps between App-flows and DetNet flows. The DetNet Edge Node TSN entity MUST support the TSN Stream identification functions and the related managed objects as defined  <ins> in Clause 6. and Clause 9. of 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> When a DetNet Service Proxy receives a packet from the TSN Entity it MUST check whether such an App-flow is present in its mapping table. 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 TSN over DetNet MPLS: TSN related configuration information according to the TSN role of the DetNet MPLS node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. DetNet MPLS related configuration information according to the DetNet role of the DetNet MPLS node, as per I-D.ietf-detnet-mpls. App-Flow identification information to map received TSN Stream(s) to the DetNet flow.  Parameters fo TSN stream identification are defined in IEEE8021CB and IEEEP8021CBdb. This information MUST be provisioned per DetNet flow. </ins> MPLS DetNet Edge nodes are member of both the DetNet domain and the connected TSN network.  From the TSN network perspective the MPLS (DetNet) Edge node has a "TSN relay node" role, so TSN specific Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are  <ins> described in RFC8655. DetNet MPLS data plane specific considerations are summarized and described in I-D.ietf-detnet-mpls including any application flow types.  This document focuses on the scenario where TSN Streams are the application flows for DetNet and it is already covered by those DetNet MPLS data plane security considerations. </ins> 8.


(PWMCW) defined in RFC4385.  An aggregation label (A-Label) is a special case of S-Label used for aggregation. <del> A node operating on a DetNet flow in the Detnet service sub- layer,uses the local context associated with that S-Label, provided by a received F-Label, to determine what local DetNet operation(s) are applied to that packet.  An S-Label may be taken from the platform label space RFC3031, making it unique, enabling DetNet flow </del>  identification regardless of which input interface or LSP the packet arrives on. be statically or dynamically configured.  Additionally the DetNet- aware forwarder does duplicate frame elimination based on the flow identification and the sequence number combination.  The packet <del> replication is also done within the DetNet-aware forwarder.  During elimination and the replication process the sequence number of the DetNet member flow MUST be preserved and copied to the egress DetNet member flow. </del>  The internal design of a relay node is out of scope of this document. However the reader's attention is drawn to the need to make any PREOF state available to the packet processor(s) dealing with packets to which the PREOF functions must be applied, and to maintain that state <del> is such as way that it is available to the packet processor operation </del>  on the next packet in the DetNet flow (which may be a duplicate, a late packet, or the next packet in sequence. <del> 4.5.2. A DetNet Relay node operates in the DetNet forwarding sub-layer . For DetNet using MPLS this processing is performed on the F-Label. This processing is done within an extended forwarder function. Whether an ingress DetNet member flow receives DetNet specific processing depends on how the forwarding is programmed.  Some relay nodes may be DetNet service aware, while others may be unmodified LSRs that only understand how to switch MPLS-TE LSPs. It is also possible to treat the relay node as a transit node, see FAG.  Again, this is entirely up to how the forwarding has been programmed. </del> 4.6. 4.6.1.

Thanks for Don's fine tuning.
NAME cam you review and merge if you're good with the changes.

(PWMCW) defined in RFC4385.  An aggregation label (A-Label) is a special case of S-Label used for aggregation.  <ins> A node operating on a DetNet flow in the Detnet service sub-layer, uses the local context associated with that S-Label, provided by a received F-Label, to determine what local DetNet operation(s) are applied to that packet.  An S-Label may be taken from the platform label space RFC3031, making it unique, enabling DetNet flow </ins> identification regardless of which input interface or LSP the packet arrives on. be statically or dynamically configured.  Additionally the DetNet- aware forwarder does duplicate frame elimination based on the flow identification and the sequence number combination.  The packet  <ins> replication is also done within the DetNet-aware forwarder. 4.5.2. A DetNet Relay node operates in the DetNet forwarding sub-layer and service sub-layer.  For DetNet using MPLS forwarding related processing is performed on the F-Label.  This processing is done within an extended forwarder function.  Whether an ingress DetNet member flow receives DetNet specific processing depends on how the forwarding is programmed.  Some relay nodes may be DetNet service aware for certain DetNet services, while for other DetNet services these nodes may perform as unmodified LSRs that only understand how to switch MPLS-TE LSPs, i.e., as a transit nodes, see FAG.  Again, this is entirely up to how the forwarding has been programmed. During the elimination and replication process the sequence number of the ingress DetNet member flow MUST be preserved and copied to the corresponding egress DetNet member flow.  Specifically, a relay node sends the same sequence number in an outgoing packet of a DetNet member flow that is received in the corresponding incoming packet of a DetNet compound flow.  This is true whether or not PREOF is performed at the relay node. </ins> The internal design of a relay node is out of scope of this document. However the reader's attention is drawn to the need to make any PREOF state available to the packet processor(s) dealing with packets to which the PREOF functions must be applied, and to maintain that state  <ins> is such away that it is available to the packet processor operation </ins> on the next packet in the DetNet flow (which may be a duplicate, a late packet, or the next packet in sequence.  4.6. 4.6.1.


The Deprecation HTTP Header Field <del> draft-ietf-httpapi-deprecation-header-02 </del>  Abstract 1. <del> Deprecation of an HTTP resource (Section 2 of HTTP) communicates information about the lifecycle of a resource.  It encourages applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continuing dependence upon the resource. </del>  The act of deprecation does not change any behavior of the resource. It informs clients of the fact that a resource is deprecated.  The The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule <del> as defined in Section 7.1.1.1 of HTTP. </del>  <del> The term "resource" is to be interpreted as defined in Section 2 of HTTP. </del>  2. The "Deprecation" response header field describes the deprecation of the resource identified with the response it occurred within (see <del> Section 3.1.4.1 of HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </del>  Servers MUST NOT include more than one "Deprecation" header field in the same response. 2.2. The Deprecation header field applies to the resource identified with <del> the response it occurred within (see Section 3.1.4.1 of HTTP), meaning that it announces the upcoming deprecation of that specific resource.  However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears. </del>  Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of 7.2. The "deprecation" link relation type should be added to the permanent <del> registry of link relation types (Section 4.2 of LINK). </del>  8.

This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.

The Deprecation HTTP Header Field  <ins> draft-ietf-httpapi-deprecation-header-latest </ins> Abstract 1.  <ins> Deprecation of an HTTP resource (HTTP) communicates information about the lifecycle of a resource.  It encourages applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continuing dependence upon the resource. </ins> The act of deprecation does not change any behavior of the resource. It informs clients of the fact that a resource is deprecated.  The The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule  <ins> as defined in HTTP. </ins>  <ins> The term "resource" is to be interpreted as defined in HTTP. </ins> 2. The "Deprecation" response header field describes the deprecation of the resource identified with the response it occurred within (see  <ins> HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </ins> Servers MUST NOT include more than one "Deprecation" header field in the same response. 2.2. The Deprecation header field applies to the resource identified with  <ins> the response it occurred within (see HTTP), meaning that it announces the upcoming deprecation of that specific resource.  However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears. </ins> Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of 7.2. The "deprecation" link relation type should be added to the permanent  <ins> registry of link relation types (LINK). </ins> 8.


Servers receiving a "dnssec_chain" extension in the ClientHello, and which are capable of being authenticated via DANE, SHOULD return a <del> serialized authentication chain in the Certificate message associated with the end entity certificate being validated, using the format described below.  The authentication chain will be an extension to the certificate_list to which the certificate being authenticated belongs. </del>  The extension protocol behavior otherwise follows that specified for TLS version 1.2. The AuthenticationChain structure is composed of a sequence of uncompressed wire format DNS resource record sets (RRset) and <del> corresponding signatures (RRSIG) records. </del>  This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in <del> RFC1035, Section 3.2.1.  The resource records SHOULD be presented in the canonical form and ordering as described in RFC4034. </del>  <del> RRs within the RRset MAY be ordered canonically, by treating the RDATA portion of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet. Each RRset in the sequence is followed by its associated RRsig record.  The RRsig record is in DNS wire format as described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del>  where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field A TLS client making use of this specification, and which receives a DNSSEC authentication chain extension from a server, SHOULD use this information to perform DANE authentication of the server.  In order <del> to do this, it uses the mechanism specified by the RFC4035.  This mechanism is sometimes implemented in a DNSSEC validation engine or library. </del>  <del> If the authentication chain is correctly verified, the client then performs DANE authentication of the server according to the DANE TLS protocol RFC6698 RFC7671. </del>  7. 8. <del> A TLS server certificate MAY mandate the use of this extension by means of the X.509 TLS Feature Extension described in RFC7633.  This X.509 certificate extension, when populated with the dnssec_chain TLS extension identifier, indicates to the client that the server must deliver the authentication chain when asked to do so.  (The X.509 TLS Feature Extension is the same mechanism used to deliver other mandatory signals, such as OCSP "must staple" assertions.)  Mandating this extension for Raw Public Key authentication (where there are no X.509 certificates) could employ configuration mechanisms external to the TLS protocol. </del>  9. <del> The security considerations of the normatively referenced RFCs (1035, 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this extension.  Since the server is delivering a chain of DNS records and signatures to the client, it MUST rebuild the chain in accordance with TTL and signature expiration of the chain components as described in sec_caching.  TLS clients need roughly accurate time in order to properly authenticate these signatures.  This could be achieved by running a time synchronization protocol like NTP RFC5905 or SNTP RFC5905, which are already widely used today.  TLS clients MUST support a mechanism to track and rollover the trust anchor key, or be able to avail themselves of a service that does this, as described in sec_trustmaint. </del>  10. implies his endorsement.  This document also benefited from discussions with and review from the following people: Viktor Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick <del> McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters. </del>

Draft 05. Tried to address all the outstanding comments during the WGLC. Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version.

Servers receiving a "dnssec_chain" extension in the ClientHello, and which are capable of being authenticated via DANE, SHOULD return a  <ins> serialized authentication chain in the extension block of the Certificate message containing the end entity certificate being validated, using the format described below. </ins> The extension protocol behavior otherwise follows that specified for TLS version 1.2. The AuthenticationChain structure is composed of a sequence of uncompressed wire format DNS resource record sets (RRset) and  <ins> corresponding signatures (RRSIG) record sets. </ins> This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in  <ins> RFC1035, Section 3.2.1. </ins>  <ins> Each RRset in the sequence is followed by its associated RRsig record set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field A TLS client making use of this specification, and which receives a DNSSEC authentication chain extension from a server, SHOULD use this information to perform DANE authentication of the server.  In order  <ins> to do this, it uses the mechanism specified by the DNSSEC protocol RFC4035 RFC5155.  This mechanism is sometimes implemented in a DNSSEC validation engine or library. </ins>  <ins> Clients MAY cache the server's validated TLS RRset or other validated portions of the chain as an optimization to save signature verification work for future connections.  The period of such caching MUST NOT exceed the TTL associated with those records. </ins> 7. 8.  <ins> Green field applications that are designed to always employ this extension, could of course unconditionally mandate its use. If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced.  The client would refuse to authenticate such servers if they failed to deliver this extension. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. This protocol currently provides no way for a server to prove that it doesn't have a TLSA record.  Hence absent whitelists, a client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue server that precluded DANE authentication.  This could be solved by enhancing this protocol to require that servers without TLSA records need to provide a DNSSEC authentication chain that proves this (i.e. the chain includes NSEC or NSEC3 records that demonstrate either the absence of the TLSA record, or the absence of a secure delegation to the associated zone).  Such an enhancement would be impossible to deploy incrementally though since it requires all TLS servers to support this protocol. </ins> 9.  <ins> The security considerations of the normatively referenced RFCs all pertain to this extension.  Since the server is delivering a chain of DNS records and signatures to the client, it MUST rebuild the chain in accordance with TTL and signature expiration of the chain components as described in sec_caching.  TLS clients need roughly accurate time in order to properly authenticate these signatures. This could be achieved by running a time synchronization protocol like NTP RFC5905 or SNTP RFC5905, which are already widely used today.  TLS clients MUST support a mechanism to track and rollover the trust anchor key, or be able to avail themselves of a service that does this, as described in sec_trustmaint. </ins> 10. implies his endorsement.  This document also benefited from discussions with and review from the following people: Viktor Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick  <ins> McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters. </ins>


RFC5280 specifies several extended key usages for X.509 certificates. This document defines a general purpose document signing extended key <del> usage for X.509 public key certificates which restricts the usage of </del>  the certificates for document signing. 1. <del> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been addedRFC7299 as public OID under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp- emailProtection, id-kp-codeSigning or vendor defined Object ID for general document signing purposes. </del>  In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes Therefore, it is not favorable to use a vendor defined EKU for signing a document that is not governed by the vendor. <del> This document defines a general Document Signing extended key usage. </del>  2. This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> use of any Subject names in the certificate is restricted to use by a document signing. </del>  <del> Term of "Document Sign" in this document is digitally sign contents </del>  that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by means of services or software, rather than processed by machines. This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> use of any Subject names in the certificate is restricted to use by a document signing service or a software (along with any usages allowed by other EKU values). </del>  4. The signed contents of Internet-Drafts are primarily intended to be consumed by human.  To be more precise, contents are intended to be shown to human in a printable or displayable form by means of <del> services or software, rather than processed by machines.  To validate the digital signature which is signed to contents intended to be consumed by human, implementations MAY perform the steps below as a certificate validation: </del>  The implementation MAY examine the Extended Key Usage value(s): The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs.  It is outside the scope of this <del> document, but the relying party can permit or prohibit conbinations of EKU.  A consideration on prohibiting combination of EKUs is </del>  described in the security consideration section of this document. 2.1.  Excluded EKUs procedure "Excluded EKU" is an EKU which the restriction, the certificate is acceptable.  Otherwise, relying party or the relying party software rejects the certificate. <del> When a single software has capability to process various data </del>  formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling (e.g. text, pdf, etc). 6. <del> The usage of id-kp-documentSigning EKU intends to prevent id-kp- emailProtection from being used for none-email purposes and id-kp- codeSigning used to sign objects other than binary codes.  This EKU does not introduce new security risks but instead reduces existing security risks by providing means to separate other EKUs used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross protocol attacks. </del>  To reduce the risk of specific cross protocol attacks, the relying <del> party or relying party software may additionaly prohibit use of </del>  specific combination of EKUs. While a specific protocol or signing scheme may choose to come up <del> with their own EKU, some may not have significant motive or resource to set up and manage thier own EKU.  This general document signing </del>  EKU may be used as a stop gap for those that intend to set up their own EKU or those who do not intend to set up an EKU but still would <del> like to distinguish from other usage. </del>  Introduction of this id-kp-documentSigning EKU value does not introduce any new security or privacy concerns.

This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.

RFC5280 specifies several extended key usages for X.509 certificates. This document defines a general purpose document signing extended key  <ins> usage for X.509 public key certificates which specifies the usage of </ins> the certificates for document signing. 1.  <ins> RFC5280 specifies several extended key purpose identifiers for X.509 certificates.  In addition, several extended key purpose identifiers were addedRFC7299 as public OIDs under the IANA PKIX Extended key purpose identifiers arc.  While usage of the any extended key usage value is bad practice for publicly trusted certificates, there is no public and general extended key purpose identifier explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined Object IDs for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes Therefore, it is not favorable to use a vendor defined EKU for signing a document that is not governed by the vendor.  <ins> This document defines a general Document Signing extended key purpose identifier. </ins> 2. This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the  <ins> use of the certified public key is allowed to be used for verifying the signature on a document. </ins>  <ins> Term of "Document Sign" in this document is digitally signes contents </ins> that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by means of services or software, rather than processed by machines. This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the  <ins> Subject named in the certificate signed the document content, and the associated keys can be used by a document signing service or a software for authentication, message integrity, and non-repudiation of origin (using digital signatures, along with any usages allowed by other EKU values). </ins> 4. The signed contents of Internet-Drafts are primarily intended to be consumed by human.  To be more precise, contents are intended to be shown to human in a printable or displayable form by means of  <ins> services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by humans, implementations MAY perform the steps below during certificate validation: </ins> The implementation MAY examine the Extended Key Usage value(s): The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs.  It is outside the scope of this  <ins> document, but the relying party can permit or prohibit combinations of EKU.  A consideration on prohibiting combinations of EKUs is </ins> described in the security consideration section of this document. 2.1.  Excluded EKUs procedure "Excluded EKU" is an EKU which the restriction, the certificate is acceptable.  Otherwise, relying party or the relying party software rejects the certificate.  <ins> When a single software has the capability to process various data </ins> formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling (e.g. text, pdf, etc). 6.  <ins> The usage of id-kp-documentSigning EKU is to provide an alternative to id-kp-emailProtection being used for non-email purposes and id-kp- codeSigning being used to sign objects other than binary code.  This EKU does not introduce new security risks but instead reduces existing security risks by providing means to separate other EKUs used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross protocol attacks. </ins> To reduce the risk of specific cross protocol attacks, the relying  <ins> party or relying party software may additionally prohibit use of </ins> specific combination of EKUs. While a specific protocol or signing scheme may choose to come up  <ins> with their own EKU, some may not have significant motive or resources to set up and manage their own EKU.  This general document signing </ins> EKU may be used as a stop gap for those that intend to set up their own EKU or those who do not intend to set up an EKU but still would  <ins> like to distinguish document signing from other usages. </ins> Introduction of this id-kp-documentSigning EKU value does not introduce any new security or privacy concerns.


document signing. Term of "Document Sign" in this document is digitally sign contents <del> that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by </del>  means of services or software, rather than processed by machines. 3.1.

there was two more remaining human.
on the section 4, it seems better to change some of "EKU" to "KeyPurposeId" or "EKU values" to highlight following. excluded EKUs procedures checks, whether EKU values contain some OID(KeyPurpiseId), or absence of EKU extension. permitted EKU procedures check, whether EKU values contain some OID(KeyPurposeId).
Current expression on "Excluded EKUs procedure " and "Permitted EKU procedure" seems unclear about whether that procedure prohibits or allows, existence of certain key purpose identifier in the extended key usage value (partial match), OR certain set of key purpose identifier is on key usage value(exact match). my intension was the former. I will review, and will fix that expression if it were unclear. In addition, I will add "restrictions set is derived and implemented from (or configured with) the policy to which the implementation conforms." to clarify policy handling by RP or implementer.

document signing. Term of "Document Sign" in this document is digitally sign contents  <ins> that are consumed by people.  To be more precise, contents are intended to be shown to person with printable or displayable form by </ins> means of services or software, rather than processed by machines. 3.1.


Abstract <del> RFC 5280 specifies several extended key usages for X.509 certificates.  This document defines a general purpose document signing extended key usage for X.509 public key certificates which restricts the usage of the certificates for document signing. </del>  1. <del> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been added RFC7299 as public Object Identifier (OID) under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined OID for general document signing purposes. </del>  In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes cryptographic agility on the document signing ecosystem and vice versa. <del> There is no issue if the vendor defined OIDs are used in a PKI (or a trust program) governed by the vendor.  However, if the OID is used outside of the vendor governance, the usage can easily become out of control (e.g. - When the end user encounters vendor defined OIDs, they might want to ask that vendor about use of the certificate, however, the vendor may not know about the particular use. - If the issuance of the cert is not under the control of the OID owner, there is no way for the OID owner to know what the impact will be if any change is made to the OID in question, and it would restrict vendor's choice of OID management. etc.). </del>  <del> Therefore, it is not favorable to use a vendor defined EKU for signing a document that is not governed by the vendor. </del>  <del> This document defines a general Document Signing extended key purpose identifier. </del>  2. 3. This specification defines the KeyPurposeId id-kp-documentSigning. <del> Inclusion of this KeyPurposeId in a certificate indicates that the use of any Subject names in the certificate is restricted to use by a document signing. Term of "Document Sign" in this document is digitally sign contents that are consumed by people.  To be more precise, contents are intended to be shown to person with printable or displayable form by means of services or software, rather than processed by machines. </del>  3.1. <del> RFC5280 specifies the EKU X.509 certificate extension for use in the </del>  Internet.  The extension indicates one or more purposes for which the certified public key is valid.  The EKU extension can be used in <del> conjunction with the key usage extension, which indicates how the public key in the certificate is used, in a more basic cryptographic way. </del>  The EKU extension syntax is repeated here for convenience: This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> use of any Subject names in the certificate is restricted to use by a document signing service or a software (along with any usages allowed by other EKU values). </del>  4. RFC8358 specifies the conventions for digital signatures on Internet- Drafts.  This is one of the intended use cases for the general <del> document signing EKU described in this document.  RFC8358 uses CMS to digitally sign a wide array of files such as ASCII, PDF, EPUB, HTML etc.  Currently, there are no specification regarding EKU for certificates signing those files except those which are defined by the software vendor. </del>  The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of <del> services or software, rather than processed by machines.  To validate the digital signature on the contents that is intended to be consumed by people, implementations MAY perform the steps below as a certificate validation. The implementation MAY examine the Extended Key Usage value(s): </del>  If there are no restrictions set for the relying party and the relying party software, the certificate is acceptable. If there are restrictions set for the replying party and relying <del> party software, proceed as following. Each Restriction on the EKUs can be "Excluded EKU" or "Permitted EKU" and handled. The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs.  It is outside the scope of this document, but the relying party can permit or exclude combinations of EKU.  A consideration on prohibiting combination of EKUs is described in the security consideration section of this document. "Excluded EKU" is an EKU which the relying party or the relying party software prohibits.  Examples of "Excluded EKU" are, presence of anyExtendedKeyUsage or complete absence of EKU extension on a certificate.  If an EKU of the certificate meets the conditions set by the "Excluded EKU" restriction, the relying party or the relying party software rejects the certificate. "Permitted EKU" is an EKU which the relying party or the relying party software accepts.  Examples of "Permitted EKU" are, presence of this general document signing EKU and/or protocol specific document signing-type EKUs.  If an EKU of the certificate meets the condition set by a "Permitted EKU" restriction, the certificate is acceptable.  Otherwise, relying party or the relying party software rejects the certificate. When a single software has capability to process various data </del>  formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling <del> (e.g. text, pdf, etc). </del>  5. inserted in each certificate that is issued.  Unless certificates are governed by a vendor specific PKI (or trust program), certificates that indicate usage for document signing MAY include the id-kp- <del> documentSigning EKU extension.  This does not encompass the mandatory usage of the id-kp-documentSigning EKU in conjunction with the vendor specific EKU.  However, this does not restrict the CA from including multiple EKUs related to document signing. </del>  6. <del> The usage of id-kp-documentSigning EKU intends to prevent id-kp- emailProtection from being used for purposes other than email and id- kp-codeSigning used to sign objects other than binary codes.  This EKU does not introduce new security risks but instead reduces existing security risks by providing means to separate other EKUs used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross protocol attacks. </del>  <del> To reduce the risk of specific cross protocol attacks, the relying party or relying party software may additionaly prohibit use of specific combination of EKUs. </del>  While a specific protocol or signing scheme may choose to come up <del> with their own EKU, some may not have significant motive or resource to set up and manage thier own EKU.  This general document signing EKU may be used as a stop gap for those that intend to set up their own EKU or those who do not intend to set up an EKU but still would like to distinguish from other usage. Introduction of this id-kp-documentSigning EKU value does not </del>  introduce any new security or privacy concerns. 7. <del> This document requests that IANA make two assignments.  One for the id-kp-documentSigning object identifier (OID), as defined in ext, for the EKU from the "SMI Security for PKIX Extended Key Purpose" (1.3.6.1.5.5.7.3) registry.  Another for the id-mod-docsign-eku, as defined in Appendix A, for the ASN.1 module X.680 from the in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. No further action is necessary by IANA. </del>

Try to used KeyPurposeId (or key purpose, key purpose identifier, etc.), to express more accurately. Add some changes, related with restrictive expression of document signing KeyPurposeId, etc.
on the section 4, it seems better to change some of "EKU" to "KeyPurposeId" or "EKU values" to highlight following. excluded EKUs procedures checks, whether EKU values contain some OID(KeyPurpiseId), or absence of EKU extension. permitted EKU procedures check, whether EKU values contain some OID(KeyPurposeId).
Current expression on "Excluded EKUs procedure " and "Permitted EKU procedure" seems unclear about whether that procedure prohibits or allows, existence of certain key purpose identifier in the extended key usage value (partial match), OR certain set of key purpose identifier is on key usage value(exact match). my intension was the former. I will review, and will fix that expression if it were unclear. In addition, I will add "restrictions set is derived and implemented from (or configured with) the policy to which the implementation conforms." to clarify policy handling by RP or implementer.

Abstract  <ins> RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  This document defines a general purpose document signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates. Document Signing applications may require that the EKU extension be present and that a document signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document Signing application. </ins> 1.  <ins> RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  In addition, several KeyPurposeIds have been addedRFC7299 under the IANA repository "SMI Security for PKIX Extended Key Purpose".  While usage of the "anyExtendedKeyUsage" KeyPurposeId is bad practice for publicly trusted certificates, there is no public and general KeyPurposeId explicitly assigned for Document Signing.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or a vendor-defined KeyPurposeId for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes cryptographic agility on the document signing ecosystem and vice versa.  <ins> There is no issue if the vendor-defined KeyPurposeIds are used in a PKI (or a trust program) governed by the vendor.  However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control (e.g. - When the end user encounters vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate, however, the vendor may not know about the particular use. - If the issuance of the cert is not under the control of the KeyPurposeId owner, there is no way for the KeyPurposeId owner to know what the impact will be if any change is made to the KeyPurposeId in question, and it would restrict vendor's choice of OID management.  etc.). </ins>  <ins> Therefore, it is not favorable to use a vendor-defined KeyPurposeId for signing a document that is not governed by the vendor. </ins>  <ins> This document defines a extended key purpose identifier for Document Signing. </ins> 2. 3. This specification defines the KeyPurposeId id-kp-documentSigning.  <ins> As described in RFC5280, If the Extended Key Usage extension is present, then the certificate MUST only be used for one of the purposes indicated.  RFC5280 also describes that If multiple key purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Document Signing applications MAY require that the Extended Key Usage extension be present and that a id-kp-documentSigning be indicated in order for the certificate to be acceptable to that Document Signing application. The term "Document Signing" in this document refers to digitally signing contents that are consumed by people.  To be more precise, contents are intended to be shown to a person with printable or displayable form by means of services or software, rather than processed by machines. </ins> 3.1.  <ins> RFC5280 specifies the EKU X.509 certificate extension for use on the </ins> Internet.  The extension indicates one or more purposes for which the certified public key is valid.  The EKU extension can be used in  <ins> conjunction with the key usage extension, which indicates the set of basic cryptographic operations for which the certified key may be used. </ins> The EKU extension syntax is repeated here for convenience: This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the  <ins> public key encoded in the certificate has been certified to be used for cryptographic operations on contents that are consumed by people. </ins> 4. RFC8358 specifies the conventions for digital signatures on Internet- Drafts.  This is one of the intended use cases for the general  <ins> document signing key purpose described in this document.  RFC8358 uses CMS to digitally sign a wide array of files such as ASCII, PDF, EPUB, HTML etc.  Currently, there are no specification regarding key purposes for certificates signing those files except those which are defined by the software vendor. </ins> The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of  <ins> services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by people, implementations MAY perform the steps below during certificate validation: The implementation MAY examine the KeyPurposeId(s) included in the Extended Key Usage extension as follows: A Restriction on Extended Key Usage is derived and implemented from (or configured with) the policy to which the implementation conforms. </ins> If there are no restrictions set for the relying party and the relying party software, the certificate is acceptable. If there are restrictions set for the replying party and relying  <ins> party software, then process the KeyPurposeId(s) as described below. Each restriction on "Excluded KeyPurposeId" or "Permitted KeyPurposeId" is handled as described below. This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can permit or prohibit combinations of KeyPurposeIds.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document. "Excluded KeyPurposeId" is a KeyPurposeId which the relying party or the relying party software prohibits.  Examples of "Excluded KeyPurposeId" are, presence of the anyExtendedKeyUsage KeyPurposeId or complete absence of the EKU extension in a certificate.  If a KeyPurposeId of the certificate meets the conditions set by the "Excluded KeyPurposeId" restriction, the relying party or the relying party software rejects the certificate. Permitted KeyPurposeId procedure: : "Permitted KeyPurposeId" is a KeyPurposeId which the relying party or the relying party software accepts.  Examples of "Permitted KeyPurposeId" are, presence of this general document signing KeyPurposeId and/or protocol specific document signing- type KeyPurposeIds.  If a KeyPurposeId of the certificate meets the condition set by a "Permitted KeyPurposeId" restriction, the certificate is acceptable.  Otherwise, relying party or the relying party software rejects the certificate. When a single application has the capability to process various data </ins> formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling  <ins> (e.g.  text, pdf, etc). </ins> 5. inserted in each certificate that is issued.  Unless certificates are governed by a vendor specific PKI (or trust program), certificates that indicate usage for document signing MAY include the id-kp-  <ins> documentSigning KeyPurposeId.  The inclusion of the id-kp- documentSigning KeyPurposeId does not preclude the inclusion of other KeyPurposeIds. </ins> 6.  <ins> The usage of id-kp-documentSigning KeyPurposeId is to provide an alternative to id-kp-emailProtection being used for non-email purposes and id-kp-codeSigning being used to sign objects other than binary code.  This extended key purpose does not introduce new security risks but instead reduces existing security risks by providing means to separate other extended key purposes used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross-protocol attacks. </ins>  <ins> To reduce the risk of specific cross-protocol attacks, the relying party or relying party software may additionally prohibit use of specific combinations of KeyPurposeIds. </ins> While a specific protocol or signing scheme may choose to come up  <ins> with their own KeyPurposeIds, some may not have significant motive or resources to set up and manage their own KeyPurposeIds.  This general document signing KeyPurposeId may be used as a stop-gap for those that intend to define their own KeyPurposeId or those who do not intend to set up an KeyPurposeId but still would like to distinguish document signing from other usages. Introduction of this id-kp-documentSigning KeyPurposeId does not </ins> introduce any new security or privacy concerns. 7.  <ins> This document requests that IANA make two assignments.  One assignment is for the addition of the id-kp-documentSigning object identifier (OID), as defined in ext, to the "SMI Security for PKIX Extended Key Purpose" (1.3.6.1.5.5.7.3) registry.  The other assignment is for the addition of the id-mod-docsign-eku ASN.1 module X.680 object identifier (OID), as defined in Appendix A, to the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry.  No further action is necessary by IANA. </ins>


RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  In addition, several <del> KeyPurposeIds have been added RFC7299 under the IANA repository "SMI Security for PKIX Extended Key Purpose".  While usage of the </del>  "anyExtendedKeyUsage" KeyPurposeId is bad practice for publicly trusted certificates, there is no public and general KeyPurposeId explicitly assigned for Document Signing.  The current practice is to KeyPurposeId for general document signing purposes. In circumstances where code signing and S/MIME certificates are also <del> widely used for document signing, the technical or policy changes that are made to code signing and S/MIME certificates may cause unexpected behaviors or have an adverse impact such as decreased cryptographic agility on the document signing ecosystem and vice versa. </del>  There is no issue if the vendor-defined KeyPurposeIds are used in a <del> PKI (or a trust program) governed by the vendor.  However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control (e.g. - When the end user encounters vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate, however, the vendor may not know about the particular use. - If the issuance of the cert is not under the control of the KeyPurposeId owner, there is no way for the KeyPurposeId owner to know what the impact will be if any change is made to the KeyPurposeId in question, and it would restrict vendor's choice of OID management.  etc.). </del>  Therefore, it is not favorable to use a vendor-defined KeyPurposeId for signing a document that is not governed by the vendor. <del> This document defines a extended key purpose identifier for Document </del>  Signing. 2. This specification defines the KeyPurposeId id-kp-documentSigning. <del> As described in RFC5280, If the Extended Key Usage extension is </del>  present, then the certificate MUST only be used for one of the <del> purposes indicated.  RFC5280 also describes that If multiple key purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. </del>  Document Signing applications MAY require that the Extended Key Usage extension be present and that the id-kp-documentSigning be indicated 4. <del> RFC8358 specifies the conventions for digital signatures on Internet- Drafts.  This is one of the intended use cases for the general document signing key purpose described in this document.  RFC8358 uses CMS to digitally sign a wide array of files such as ASCII, PDF, EPUB, HTML etc.  Currently, there are no specification regarding key purposes for certificates signing those files except those which are defined by the software vendor. </del> The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of consumed by people, implementations MAY perform the steps below during certificate validation: <del> The implementation MAY examine the KeyPurposeId(s) included in the Extended Key Usage extension as follows: A Restriction on Extended Key Usage is derived and implemented from (or configured with) the policy to which the implementation conforms. </del>  If there are no restrictions set for the relying party and the relying party software, the certificate is acceptable. party software, then process the KeyPurposeId(s) as described below. <del> Each restriction on "Excluded KeyPurposeId" or "Permitted KeyPurposeId" is handled as described below. </del> This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can <del> permit or prohibit combinations of KeyPurposeIds.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document. </del>  "Excluded KeyPurposeId" is a KeyPurposeId which the relying party or the relying party software prohibits.  Examples of The procedures and practices employed by a certification authority MUST ensure that the correct values for the EKU extension are inserted in each certificate that is issued.  Unless certificates are <del> governed by a vendor specific PKI (or trust program), certificates that indicate usage for document signing MAY include the id-kp- documentSigning KeyPurposeId.  The inclusion of the id-kp- documentSigning KeyPurposeId does not preclude the inclusion of other KeyPurposeIds. </del>  6. binary code.  This extended key purpose does not introduce new security risks but instead reduces existing security risks by providing means to separate other extended key purposes used for <del> communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross-protocol attacks. </del>  To reduce the risk of specific cross-protocol attacks, the relying party or relying party software may additionally prohibit use of

changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."

RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  In addition, several  <ins> KeyPurposeIds have been added under the IANA repository "SMI Security for PKIX Extended Key Purpose" RFC7299.  While usage of the </ins> "anyExtendedKeyUsage" KeyPurposeId is bad practice for publicly trusted certificates, there is no public and general KeyPurposeId explicitly assigned for Document Signing.  The current practice is to KeyPurposeId for general document signing purposes. In circumstances where code signing and S/MIME certificates are also  <ins> used for document signing, technical or policy changes made to the code signing and S/MIME ecosystem may cause unexpected behaviors or have an adverse impact such as decreased cryptographic agility on the document signing ecosystem and vice versa. </ins> There is no issue if the vendor-defined KeyPurposeIds are used in a  <ins> PKI governed by the vendor or a set of specific group of vendors. However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control.  For instance, when the end user encounters certificates with vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate. However, if those certificates were not governed by the KeyPurposeIds owner but by another vendor, the vender who own the KeyPurposeIds may not able to control use, or even do not know about the use. - If the issuance of the cert is not under the control of the KeyPurposeIds owner, it is hard to estimate the impact of change to made on the KeyPurposeId.  Changes related to KeyPurposeIds possibly make negative impacts that some group of people do not tolerate, and it could become a migration agility issue. </ins> Therefore, it is not favorable to use a vendor-defined KeyPurposeId for signing a document that is not governed by the vendor.  <ins> This document defines an extended key purpose identifier for Document </ins> Signing. 2. This specification defines the KeyPurposeId id-kp-documentSigning.  <ins> As described in RFC5280, "[i]f the [Extended Key Usage] extension is </ins> present, then the certificate MUST only be used for one of the  <ins> purposes indicated."  RFC5280 also describes that "[i]f multiple [key] purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present." </ins> Document Signing applications MAY require that the Extended Key Usage extension be present and that the id-kp-documentSigning be indicated 4.  The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of consumed by people, implementations MAY perform the steps below during certificate validation:  <ins> The following procedure is used to examine the KeyPurposeId(s) included in the Extended Key Usage extension.  Restrictions on Extended Key Usage is derived and implemented from (or configured with) the policy to which the implementation conforms. </ins> If there are no restrictions set for the relying party and the relying party software, the certificate is acceptable. party software, then process the KeyPurposeId(s) as described below.  This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can  <ins> permit or prohibit combinations of KeyPurposeIds, instead of single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and "Permitted KeyPurposeId" exists, the relying party or the relying party software proresses each restriction on "Excluded KeyPurposeId" first, and then processes each restriction on "Permitted KeyPurposeId". </ins> "Excluded KeyPurposeId" is a KeyPurposeId which the relying party or the relying party software prohibits.  Examples of The procedures and practices employed by a certification authority MUST ensure that the correct values for the EKU extension are inserted in each certificate that is issued.  Unless certificates are  <ins> governed by a vendor(s) specific PKI, certificates that indicate usage for document signing MAY include the id-kp-documentSigning KeyPurposeId.  The inclusion of the id-kp-documentSigning KeyPurposeId does not preclude the inclusion of other KeyPurposeIds. </ins> 6. binary code.  This extended key purpose does not introduce new security risks but instead reduces existing security risks by providing means to separate other extended key purposes used for  <ins> communication protocols namely, TLS (id-kp-clientAuth) or S/MIME (id- kp-emailProtection) etc.  in order to minimize the risk of cross- protocol attacks. </ins> To reduce the risk of specific cross-protocol attacks, the relying party or relying party software may additionally prohibit use of