jiebi/TextFlow huggingface dataset:
Original text:
3.2. A document in the binary format MAY reference values from an external <del> dictionary.  This helps to reduce representation size and processing cost.  Dictionary references can be used in place of link relation types, link targets, operation types, submission targets, form field types, and form field values. </del>  <del> 3.2.1. A dictionary reference is encoded as an unsigned integer.  Where a dictionary reference cannot be expressed unambiguously, the unsigned integer is tagged with CBOR tag TBD6, as follows: </del>  <del> A dictionary reference MUST NOT refer to a dictionary value that would otherwise not be syntactically allowed in that position.  For example, a dictionary reference in the position of a link relation type cannot refer to a Boolean value; it can only refer to an IRI. </del>  <del> 3.2.2. </del>  The "application/coral+cbor" media type for documents in the binary format is defined to have a "dictionary" parameter that specifies the

Reviewer comments:
This replaces the previous mechanism of having bespoke dictionaries with Packed CBOR. Other places in the text still talk of "dictionaries", but that's not necessarily wrong, it's a term even used occasionally in packed.

Revised text:
3.2. A document in the binary format MAY reference values from an external  <ins> dictionary using Packed CBOR I-D.ietf-cbor-packed.  This helps to reduce representation size and processing cost. </ins>  <ins> Dictionary references can be used subject to [ yet to be defined ] profiling. </ins>  <ins> Implementers should note that Packed CBOR is not designed to be uncompressed, but to be used in a compressed form.  In particular, constrained devices may operate without even knowing what a given dictionary entry expands to (as long as they know its meaning) . </ins>  <ins> 3.2.1. </ins> The "application/coral+cbor" media type for documents in the binary format is defined to have a "dictionary" parameter that specifies the
Original text:
2. A Concise Problem Details data item is a CBOR data item with the <del> following structure: </del>  A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38 <del> for the definition of the latter. </del>  The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered.

Reviewer comments:
Capture the discussion in the 2022-06-08 interim and .
Comment by NAME : I have a hard time motivating why this can be unadorned CBOR text string, given that these two fields are always human-readable text. Maybe we need to add a default, i.e. that when text used, that is to be interpreted as English language is used.
(w/ TF:) making "foo" a shorthand for 38(["en", "foo", false]) makes sense in the Anglo-American dominated world we live in. Details (en? en-US?) need to be discussed though.
I wouldn't go down the rabbit hole of also picking the locale. Too much stress I'm happy with the minimum required to satisfy the rule, i.e., "en".
In we decided to go with the following: use context if available fall back to english Now, similar to , should we have a (and ) keys for when the CPD is stored/forwarded and therefore the context is lost?
LGTM

Revised text:
2. A Concise Problem Details data item is a CBOR data item with the  <ins> following structure (rules named starting with "tag38" are defined in tag38): </ins> A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38  <ins> for the definition of the latter.  Language tag and writing direction information for unadorned text strings are intended to be obtained from context; if that context needs to be saved or forwarded with a Concise Problem Details data item, "base-lang" and "base-rtl" can be used for that.  If no such (explicitly saved or implicit) context information is available, unadorned text is interpreted with language-tag "en" and writing-direction "false" (ltr). </ins> The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered.
Original text:
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. </del>  contains either the sign bit or the value of y coordinate for the EC point.  When encoding the value y, the integer is converted to an octet string (as defined in SEC1) and encoded as a CBOR bstr. <del> Leading zero octets MUST be preserved.  When encoding the sign of y, the expression 'y > 0' is evaluated and encoded a CBOR boolean. </del>  contains the private key.

Reviewer comments:
The sign encoding function should deal with other types of curves as well. Make the text refer to the SEC1 encoding function.

Revised text:
private curves can be used as well. contains the x coordinate for the EC point.  The integer is  <ins> converted to an octet string as defined in SEC1.  Leading zero octets MUST be preserved. </ins> contains either the sign bit or the value of y coordinate for the EC point.  When encoding the value y, the integer is converted to an octet string (as defined in SEC1) and encoded as a CBOR bstr.  <ins> Leading zero octets MUST be preserved.  The compressed point encoding is also supported.  Compute the sign bit as laid out in the Elliptic-Curve-Point-to-Octet-String Conversion function of SEC1.  If the sign bit is zero, then encode y as a CBOR false value, otherwise encode y as a CBOR true value.  The encoding of the infinity point is not supported. </ins> contains the private key.
Original text:
Since the only the math is changed by changing the curve, the curve is not fixed for any of the algorithm identifiers we define.  Ephemeral-static or static-static: The key agreement process may be done using either a static or an ephemeral key for the sender's side.  When using ephemeral keys, the sender MUST generate a new If the 'key_ops' field is present, it MUST be empty for the public key.  12.5. Key Agreement with Key Wrapping uses a randomly generated CEK.  The applications to document how content padding is to be done in order to prevent or discourage such analysis.  (For example the strings could be defined as 'YES' and 'NO '.) <del> Timing Issues - TBD </del>

Reviewer comments:
Response to note from Göran Selander 1) we need to say where the secret is derived from 2) how it is formatted, and 3) why we are not using KA and KB in the KDF step.

Revised text:
Since the only the math is changed by changing the curve, the curve is not fixed for any of the algorithm identifiers we define. <ins> Shared Secret to Byte String: Once the shared secret is computed using the correct mathematics, the resulting value needs to be converted to a byte string to run the KDF function.  The X coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly as it is a byte string of a known length.  For the P-256, P-384 and P-521 curves, the X coordinate is run through the I2OSP function defined in RFC3447 using the same computation for n as is defined in ECDSA. </ins> Ephemeral-static or static-static: The key agreement process may be done using either a static or an ephemeral key for the sender's side.  When using ephemeral keys, the sender MUST generate a new If the 'key_ops' field is present, it MUST be empty for the public key. <ins> 12.4.2. Some method of checking that points provided from external entities are valid.  For the 'EC2' key format, this can be done by checking that the x and y values form a point on the curve.  For the 'OKP' format, there is no simple way to do point validation. Consideration was given to requiring that the public keys of both entities be provided as part of the key derivation process.  (As recommended in section 6.1 of RFC7748.)  This was not done as COSE is used in a store and forward format rather than in on line key exchange.  In order for this to be a problem, either the receiver public key has to be chosen maliciously or the sender has to be malicious.  In either case, all security evaporates anyway. A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted. (Either by the end user or by the entity that is responsible for making trust statements on keys.) </ins> 12.5. Key Agreement with Key Wrapping uses a randomly generated CEK.  The applications to document how content padding is to be done in order to prevent or discourage such analysis.  (For example the strings could be defined as 'YES' and 'NO '.)
Original text:
contains the value of the key. <del> This key structure contains only private key information; care must be taken that it is never transmitted accidentally.  For public keys, there are no required fields.  For private keys, it is REQUIRED that </del>  'k' be present in the structure. 14.

Reviewer comments:
This is basically the text that Ludwig agreed to. Will seek second confirmation for issue
In Section 13.2. there is the following text: "This key structure contains only private key information, care must be taken that it is never transmitted accidentally. For public keys, there are no required fields. For private keys, it is REQUIRED that 'k' be present in the structure." This should probably read something like this: "This key structure only contains secret (or symmetric) key information, care must be taken that it is never transmitted accidentally. For symmetric keys, it is REQUIRED that 'k' be present in the structure."
What if we change it to be This key structure does not have a form that contains only public members. For symmetric keys, it is REQUIRED that 'k' be present in the structure.
I really have nothing against the "care must be taken ..." part. I'd actually tend to leave it in, but feel free to rephrase that as you see fit.

Revised text:
contains the value of the key.  <ins> This key structure does not have a form which contains only public members.  As it is expected that this key structure is going to be transmitted, care must be taking that it is never transmitted accidentally or insecurely.  For symmetric keys, it is REQUIRED that </ins> 'k' be present in the structure. 14.
Original text:
Have any security considerations that are part of the message been enforced (as specified by the application or crit parameter)? <del> This document defines several algorithms where the computed authentication tag can be truncated to a shorter value than the default value.  Doing this truncation affects the authentication service provided by this value.  In general, [CREF3] </del> There are a large number of algorithms presented in this document that use nonce values.  For all of the nonces defined in this document, there is some type of restriction on the nonce being a appropriate table when we defined what a 'kty' is so they have had a chance to find out what 'OKP' is.  If we did this we would need to do it for all of the different values that show up here. <del> [CREF3] GS: Include a birthday attack note on tag size? </del>

Reviewer comments:
Started a birthday attack consideration, but it is not valid as far as I can tell so remove it.

Revised text:
Have any security considerations that are part of the message been enforced (as specified by the application or crit parameter)?  There are a large number of algorithms presented in this document that use nonce values.  For all of the nonces defined in this document, there is some type of restriction on the nonce being a appropriate table when we defined what a 'kty' is so they have had a chance to find out what 'OKP' is.  If we did this we would need to do it for all of the different values that show up here.
Original text:
this structure does not preclude a protocol to use one of the individual structures as a stand alone component. <del> This structure is encoded as an array by CBOR.  Descriptions of the fields: indicates which of the security structures is in this block. contains the top level fields for the security service provided. The type in this field is based on the value of the field msg_type. msg_type 1 is used for COSE_sign msg_type 2 is used for COSE_encrypt msg_type 3 is used for COSE_mac </del>  3.

Reviewer comments:
Fix some additional errors found in the CDDL descriptions. It is still not completely correct so automatic testing is not turned on yet. Also some of the examples were out of date to the expected syntax so they got some updates.

Revised text:
this structure does not preclude a protocol to use one of the individual structures as a stand alone component.  <ins> The top level of each of the COSE message structures are encoded as arrays. We use an integer to distingish bettwen the different security message types.  By looking at the integer in the first element, one can determine which security message is being used and thus what the syntax is for the rest of the elements in the array. Implementations SHOULD be prepared to find an integer in the location which does not correspond to the values 0 to 2.  If this is found then the client MUST stop attempting to parse the structure and fail. Clients need to recognize that the set of values could be extended at a later date, but should not provide a security service based on guesses of what is there. NOTE: Alternative syntax with tags would be Where we would need to define the latter two as tagged arrays like is currently done for COSE_SignedMessage. There is no space savings in CBOR, this is strictly about using CBOR paradymes.  It is not clear what would happen if a JOSE serialization appeared, but that is probably not interesting.  If this path is used, then there is no extensibility for new messages types.  They would need to be defined on their own. </ins> 3.
Original text:
a later date, but should not provide a security service based on guesses of what is there. <del> NOTE: Alternative syntax with tags would be Where we would need to define the latter two as tagged arrays like is currently done for COSE_SignedMessage. There is no space savings in CBOR, this is strictly about using CBOR paradymes.  It is not clear what would happen if a JOSE serialization appeared, but that is probably not interesting.  If this path is used, then there is no extensibility for new messages types.  They would need to be defined on their own. </del> 3. The signature structure allows for one or more signatures to be 8. <del> There are IANA considerations to be filled in. </del>  9.

Reviewer comments:
Fix install instructions in the README for kramdown-xml2rfc Update COSE spec for tagging discussion Update Issues document for closed and newly opened discussion issues.
Carsten has suggested that we could eliminate the need for the COSE_MSG structure if we were to get tags assigned from CBOR for these structures. Should this be done?
a) CBOR Tag - either general or specific to each type b) Required Identifier c) Use the same techniques as JOSE There was no support for option C. There was support for Option B There was some support for Option A, but only if it was optional. Mike Jones suggested that we should use the header parameter 'typ', I responded to this message saying that it was not clear that this was a correct use of the field based on the description in the JWS document. At this point I will keep the field as mandatory and outside of the headers field. I am planning on doing the IANA request for a CBOR Tag and to keep the tag as being optional in the grammar and text.
Closed in Pull request

Revised text:
a later date, but should not provide a security service based on guesses of what is there.  3. The signature structure allows for one or more signatures to be 8.  <ins> 8.1. It is requested that IANA assign a new tag from the "Concise Binary Object Represetion (CBOR) Tags" registry.  It is requested that the tag be assigned in the 0 to 23 value range. Tag Value: TBD1 Data Item: CBOR map Semantics: COSE security message. </ins> 9.
Original text:
This section registers the "application/cose" and "application/ cose+cbor" media types in the "Media Types" registry.  [CREF11] These media types are used to indicate that the content is a COSE_MSG.  Type name: application Provisional registration?  No  16. There are security considerations: explicitly allow for integers encoded with leading zeros. [CREF11] JLS: Should we register both or just the cose+cbor one? 

Reviewer comments:
Create IANA considerations for: 1) key and keyset CBOR tags 2) COAP Content Format registrations

Revised text:
This section registers the "application/cose" and "application/ cose+cbor" media types in the "Media Types" registry.  [CREF11] These media types are used to indicate that the content is a COSE_MSG. <ins> [CREF12] </ins> Type name: application Provisional registration?  No <ins> 15.9. This section registers a set of content formats for CoAP.  ID assignment in the 24-255 range requested. </ins> 16. There are security considerations: explicitly allow for integers encoded with leading zeros. [CREF11] JLS: Should we register both or just the cose+cbor one? <ins> [CREF12] JLS: Should we create the equivalent of the smime-type parameter to identify the inner content type? </ins>
Original text:
padding is to be done to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.)  7. This section records the status of known implementations of the

Reviewer comments:
When either COSEEncrypt and COSEMac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key. Countersignatures of COSEEncrypt and COSEMac with short authentication tags do not provide the security properties associated with the same algorithm used in COSESign. To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits. A countersignature of a COSEMac with AES-MAC 256/128 provides at most 64 bits of integrity protection. Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection.

Revised text:
padding is to be done to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.) <ins> When either COSE_Encrypt and COSE_Mac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key. Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign.  To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits.  A countersignature of a COSE_Mac with AES-MAC 256/128 provides at most 64 bits of integrity protection.  Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection. </ins> 7. This section records the status of known implementations of the
Original text:
A P-Route may be installed in either Storing and Non-Storing Mode, potentially resulting in hybrid situations where the Mode of the <del> P-Route is different from that of the RPL Main DODAG.  P-Routes can be used as stand-alone segments to reduce the size of the source routing headers with loose source routing operations down the main RPL DODAG.  P-Routes can also be combined with other P-Routes to form a more complex forwarding graph called a Track. </del>  3.3.

Reviewer comments:
Comments on the content In the XML file you can search for "COMMENT:". In the TXT file, the comments start with "_COMMENT:"
I'll address inline and commit too. Many thanks Aris!!!

Revised text:
A P-Route may be installed in either Storing and Non-Storing Mode, potentially resulting in hybrid situations where the Mode of the  <ins> P-Route is different from that of the RPL Main DODAG. P-Routes can be used as stand-alone segments to reduce the size of the source routing headers with loose source routing operations down the main RPL DODAG.  P-Routes can also be combined with other P-Routes to form a more complex forwarding graph called a Track. </ins> 3.3.
Original text:
5.  5.1. A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a Section 5.1. An implementation MUST support the provisioning for handling any <del> received DetNet MPLS data plane as DetNet IP flows via configuration. Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. </del>  Note: using Layer-4 (L4) transport protocols e.g., for multipath are out of scope of this document both for a single flow and aggregate

Reviewer comments:
Changes: 1, Section “5. IP over DetNet MPLS Procedures” Add new text before section 5.1. 2, Fix a nit in penultimate paragraph of “5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures”

Revised text:
5. <ins> Main differences of mapping to DetNet MPLS (compared to plain MPLS) are that (1) there is a mandatory flow identification to make the forwarding decision (i.e., forwarding is not based on FEC), (2) the d-CW (DetNet Control Word) is mandatory for the MPLS encapsulation and (3) during forwarding over the DetNet MPLS network DetNet flow specific treatment is needed. </ins> 5.1. A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a Section 5.1. An implementation MUST support the provisioning for handling any  <ins> packet flows received via DetNet MPLS data plane as DetNet IP flows via configuration.  Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. </ins> Note: using Layer-4 (L4) transport protocols e.g., for multipath are out of scope of this document both for a single flow and aggregate
Original text:
5. <del> The following summarizes the set of information that is needed to configure DetNet MPLS over UDP/IP: </del>  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 UDP Destination Port.  This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller RFC8655 or management plane.  It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific

Reviewer comments:
In chapter 5. Management and Control Information Summary one more bullet added + clarification text to the paragraph after the list.

Revised text:
5.  <ins> The following summarizes the minimum 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 UDP Destination Port. <ins> Use/non-use of UDP checksum. </ins> This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller RFC8655 or management plane. <ins> Not using the UDP checksum has to be evaluated on a case-by-case basis for a given network scenario based on the exception criteria's defined in RFC7510, particularly when IPv6 is used. </ins> It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific