jiebi/TextFlow huggingface dataset:
Original text:
If the 'alg' field present, it MUST match the HMAC algorithm being used. <del> If the 'key_ops' field is present, it MUST include 'sign' when creating an HMAC authentication tag. </del>  <del> If the 'key_ops' field is present, it MUST include 'verify' when verifying an HMAC authentication tag. </del>  Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate

Reviewer comments:
Create MAC as separate key operations per issue
Should we attempt to add the MACverify and MACcreate elements to the key_ops field since we have decided to distinguish between a signature and a MAC - or do we keep the same signature/verify tags that are currently used in the JWK document?

Revised text:
If the 'alg' field present, it MUST match the HMAC algorithm being used.  <ins> If the 'key_ops' field is present, it MUST include 'MAC create' when creating an HMAC authentication tag. </ins>  <ins> If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an HMAC authentication tag. </ins> Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate
Original text:
If the 'alg' field present, it MUST match the AES-MAC algorithm being used. <del> If the 'key_ops' field is present, it MUST include 'sign' when creating an AES-MAC authentication tag. </del>  <del> If the 'key_ops' field is present, it MUST include 'verify' when verifying an AES-MAC authentication tag. </del>  9.2.1.

Reviewer comments:
Create MAC as separate key operations per issue
Should we attempt to add the MACverify and MACcreate elements to the key_ops field since we have decided to distinguish between a signature and a MAC - or do we keep the same signature/verify tags that are currently used in the JWK document?

Revised text:
If the 'alg' field present, it MUST match the AES-MAC algorithm being used.  <ins> If the 'key_ops' field is present, it MUST include 'MAC create' when creating an AES-MAC authentication tag. </ins>  <ins> If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an AES-MAC authentication tag. </ins> 9.2.1.
Original text:
cryptographic key, we use the term "label" for this usage of either an integer or a string to identify map keys and choice data items.  2. The COSE_MSG structure is a top level CBOR object that corresponds to

Reviewer comments:
MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Revised text:
cryptographic key, we use the term "label" for this usage of either an integer or a string to identify map keys and choice data items. <ins> 1.5. One of the standard issues that is specified in IETF cryptographic algorithms is a requirement that a standard specify a set of minimal algorithms that are required to be implemented.  This is done to promote interoperability as it provides a minimal set of algorithms that all devices can be sure will exist at both ends.  However, we have elected not to specify a set of mandatory algorithms in this document. It is expected that COSE is going to be used in a wide variety of applications and on a wide variety of devices.  Many of the constrained devices are going to be setup to used a small fixed set of algorithms, and this set of algorithms may not match those available on a device.  We therefore have deferred to the application protocols the decision of what to specify for mandatory algorithms. Since the set of algorithms in an environment of constrained devices may depend on what the set of devices are and how long they have been in operation, we want to highlight that application protocols will need to specify some type of discovery method of algorithm capabilities.  The discovery method may be as simple as requiring preconfiguration of the set of algorithms to providing a discovery method built into the protocol.  S/MIME provided a number of different ways to approach the problem: Advertising in the message (S/MIME capabilities) Advertising in the certificate (capabilities extension) Minimum requirements for the S/MIME which have been updated over time </ins> 2. The COSE_MSG structure is a top level CBOR object that corresponds to
Original text:
9. <del> 9.1. </del>  <del> 9.2. </del>  ECDSA DSS defines a signature algorithm using ECC.

Reviewer comments:
MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Revised text:
9.  <ins> M00TODO: Put in generalities about sigature algorithms and parameters. </ins>  <ins> 9.1. </ins> ECDSA DSS defines a signature algorithm using ECC.
Original text:
Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8) <del> 9.2.1. </del>  On of the issues that needs to be discussed is substitution attacks. There are two different things that can potentially be substituted in

Reviewer comments:
MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Revised text:
Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8)  <ins> 9.1.1. </ins> On of the issues that needs to be discussed is substitution attacks. There are two different things that can potentially be substituted in
Original text:
including the signature algorithm identifier in the data to be signed.  10. Message Authentication Codes (MACs) provide data authentication and

Reviewer comments:
MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Revised text:
including the signature algorithm identifier in the data to be signed. <ins> 9.2. The RSASSA-PSS signature algorithm is defined in RFC3447. The RSASSA-PSS signature algorithm is parametized with a hash function, a mask generation function and a salt length (sLen).  For this specification, the mask generation function is fixed to be MGF1 as defined in RFC3447.  It has been recommended that the same hash function be used for hashing the data as well as in the mask generation function, for this specification we following this recommendation.  The salt length is the same length as the hash function output. Three algorithms are defined in this document.  These algorithms are: This uses the hash algorithm SHA-256 for signature processing. The value used for this algorithm is -10.  The key type used for this algorithm is 'RSA'. This uses the hash algorithm SHA-384 for signature processing. The value used for this algorithm is "PS384".  The key type used for this algorithm is 'RSA'. This uses the hash algorithm SHA-512 for signature processing. The value used for this algorithm is -11.  The key type used for this algorithm is 'RSA'. There are no algorithm parameters defined for these signature algorithms.  A summary of the algorithm definitions can be found in table-rsa-algs. 9.2.1. Key size.  is there a MUST for 2048? or do we need to specify a minimum here? </ins> 10. Message Authentication Codes (MACs) provide data authentication and
Original text:
the future and private curves can be used as well. contains the x coordinate for the EC point.  The integer is <del> converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string.  [CREF21] contains either the sign bit or the value of y coordinate for the EC point.  For the value, the integer is converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string.  For the sign bit, the value is true if the value of y is positive. </del>  contains the private key.

Reviewer comments:
MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Revised text:
the future and private curves can be used as well. contains the x coordinate for the EC point.  The integer is  <ins> converted to an octet string use ???.  Note that the octet string represents a little-endian encoding of x.  [CREF21] </ins> contains the private key.
Original text:
This contains a pointer to the public specification for the field if one exists <del> This registry will be initially populated by the values in COSE_KEY_PARAM_KEYS.  The specification column for all of these entries will be this document. </del>  15.8.

Reviewer comments:
MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Revised text:
This contains a pointer to the public specification for the field if one exists  <ins> This registry will be initially populated by the values in --Multiple Tables--.  The specification column for all of these entries will be this document. </ins> 15.8.
Original text:
[CREF20] JLS: Do we create a registry for curves?  Is is the same registry for both EC1 and EC2? <del> [CREF21] JLS: Should we use the integer encoding for x, y and d instead of bstr? </del>  [CREF22] JLS: Should we use the integer encoding for x, y and d instead of bstr?

Reviewer comments:
MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).

Revised text:
[CREF20] JLS: Do we create a registry for curves?  Is is the same registry for both EC1 and EC2?  <ins> [CREF21] JLS: Should we use the integer encoding for x and d instead of bstr? </ins> [CREF22] JLS: Should we use the integer encoding for x, y and d instead of bstr?
Original text:
bounded end-to-end delivery latency.  General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> The DetNet Architecture models the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service functions such as protection and reordering.  The </del>  forwarding sub-layer is used to provide forwarding assurance (low <del> loss, assured latency, and limited out-of-order delivery). </del>  This document specifies the DetNet data plane operation and the on- wire encapsulation of DetNet flows over an MPLS-based Packet Switched

Reviewer comments:
Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

Revised text:
bounded end-to-end delivery latency.  General background and concepts of DetNet can be found in the DetNet Architecture RFC8655.  <ins> The purpose of this document is to describe the use of the MPLS data plane to establish and support DetNet flows.  The DetNet Architecture models the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service functions such as protection and reordering.  At the DetNet data plane a new set of functions (PREOF) provide the service sub-layer specific tasks.  The </ins> forwarding sub-layer is used to provide forwarding assurance (low  <ins> loss, assured latency, and limited out-of-order delivery) via already existing Traffic Engineering and queuing tools.  The use of the functionalities of the DetNet service sub-layer and the DetNet forwarding sub-layer require careful design and control by the controller plane in addition to the DetNet specific use of MPLS encapsulation as specified by this document. </ins> This document specifies the DetNet data plane operation and the on- wire encapsulation of DetNet flows over an MPLS-based Packet Switched
Original text:
encapsulations for consistency but there is no hard requirement in this regard.  4.2.2.1. The Packet Replication Function (PRF) function MAY be supported by an

Reviewer comments:
Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

Revised text:
encapsulations for consistency but there is no hard requirement in this regard. <ins> Implementation details of PREOF functions is out of scope for this document.  IEEE802.1CB-2017 specifies replication and elimination specific aspects, which can be applied to PRF and PEF. </ins> 4.2.2.1. The Packet Replication Function (PRF) function MAY be supported by an
Original text:
basis.  The number of out of order packets that can be processed also impacts the latency of a flow.  4.2.3. F-Labels support the DetNet forwarding sub-layer.  F-Labels are used

Reviewer comments:
Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

Revised text:
basis.  The number of out of order packets that can be processed also impacts the latency of a flow. <ins> The latency impact on the system resources needed to support a specific DetNet flow will need to be evaluated by the controller plane based on that flow's traffic specification.  An example traffic specification that can be used with MPLS with Traffic Engineering (MPLS-TE) can be found in RFC2212. DetNet uses flow-specific requirements (e.g., maximum number of out- of-order packets, maximum latency of the flow) for configuration of POF-related buffers.  POF implementation details are out-of-scope for this document and POF configuration parameters are implementation specific.  The Controller Plane determines and sets the POF configuration parameters.  If PEF is combined with POF, then their configurations need to be coordinated to ensure the combined functionality. </ins> 4.2.3. F-Labels support the DetNet forwarding sub-layer.  F-Labels are used
Original text:
protect against DOS attacks, excess traffic due to malicious or malfunctioning devices is prevented or mitigated through the use of existing mechanisms, for example by policing and shaping incoming <del> traffic.  To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of on-path attackers, for example through use of authentication and authorization of devices within the DetNet domain. </del>  7.

Reviewer comments:
Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane

Revised text:
protect against DOS attacks, excess traffic due to malicious or malfunctioning devices is prevented or mitigated through the use of existing mechanisms, for example by policing and shaping incoming  <ins> traffic.  To prevent DetNet packets having their delay manipulated by an external entity, precautions need to be taken to ensure that all devices on an LSP are those intended to be there by the network operator and that they are well behaved.  In addition to physical security, technical methods such as authentication and authorization of network equipment and the instrumentation and monitoring of the LSP packet delay may be used.  If a delay attack is suspected, traffic may be moved to an alternate path, for example through changing the LSP or management of the PREOF configuration. </ins> 7.
Original text:
General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> I-D.ietf-detnet-ip specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </del>  The DetNet Architecture decomposes the DetNet related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service protection and reordering.  The forwarding sub-layer is used to provides congestion protection (low loss, assured latency, and <del> limited reordering).  As described in I-D.ietf-detnet-ip no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </del>  2.

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
General background and concepts of DetNet can be found in the DetNet Architecture RFC8655.  <ins> RFC8939 specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </ins> The DetNet Architecture decomposes the DetNet related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service protection and reordering.  The forwarding sub-layer is used to provides congestion protection (low loss, assured latency, and  <ins> limited reordering).  As described in RFC8939 no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </ins> 2.
Original text:
Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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> 3. <del> I-D.ietf-detnet-ip describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </del>  DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes and ranges.  IP tunnels may also be used to support

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group.  3.  <ins> RFC8939 describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </ins> DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes and ranges.  IP tunnels may also be used to support
Original text:
configure DetNet IP over TSN: DetNet IP related configuration information according to the <del> DetNet role of the DetNet IP node, as per I-D.ietf-detnet-ip. </del>  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 <del> 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. </del>  This information must be provisioned per DetNet flow.

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
configure DetNet IP over TSN: DetNet IP related configuration information according to the  <ins> DetNet role of the DetNet IP node, as per RFC8939. </ins> 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  <ins> in RFC8939, 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. </ins> This information must be provisioned per DetNet flow.
Original text:
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 <del> 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. </del>  The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
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  <ins> are summarized in RFC8939.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. </ins> The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/
Original text:
Time-Sensitive Network. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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> 3. The basic approach defined in I-D.ietf-detnet-mpls supports the

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
Time-Sensitive Network.  3. The basic approach defined in I-D.ietf-detnet-mpls supports the
Original text:
2.1. This document uses the terminology and concepts established in the <del> DetNet architecture RFC8655 and I-D.ietf-detnet-data-plane-framework, and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with these documents and their terminology. </del>  2.2.

Reviewer comments:
ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)

Revised text:
2.1. This document uses the terminology and concepts established in the  <ins> DetNet architecture RFC8655 and RFC8938, and I-D.ietf-detnet-mpls. The reader is assumed to be familiar with these documents and their terminology. </ins> 2.2.