jiebi/TextFlow huggingface dataset:
Original text:
"authority" as defined in Section 3.2 of RFC3986. The Alternative-Address Option is a repeatable option as defined in <del> Section 5.4.5 of RFC7252. </del>  The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in

Reviewer comments:
URL - WGLC review by Esko Dijk Page 20: Alternative-Address Option - the semantics of including multiple of these options is not defined. Can the receiver pick any of the addresses? Or does it need to try the first address first? And then keep trying all alternatives until one succeeds, or not?
URL Unless Carsten or Hannes (authors of draft-bormann-core-coap-sig-02) have a preference, I would suggest that the addresses are unordered (pick any).

Revised text:
"authority" as defined in Section 3.2 of RFC3986. The Alternative-Address Option is a repeatable option as defined in  <ins> Section 5.4.5 of RFC7252.  When multiple occurrences of the option are included, the peer can choose any of the alternative transport addresses. </ins> The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in
Original text:
Capability and Settings messages are used for two purposes: <del> Capability options advertise the capabilities of the sender to the recipient. </del>  Setting options indicate a setting that will be applied by the sender.

Reviewer comments:
sig-02 did not define the length for options with uint values. Can you confirm whether 0-4 is correct? I note that there are variants in the RFC7252 options with uint values.
Good catch. 0-4 definitely is right for Max-Message-Size. 0-4 is a bit over the top for Hold-Off, but arbitrarily limiting the time at, say, 65535 seconds (0-2) or 16777215 seconds (0-3) doesn't sound right either -- well, maybe half a year max (0-3) is about right. Option numbers are 65535 max, so Bad-CSM-Option needs to be 0-2.

Revised text:
Capability and Settings messages are used for two purposes:  <ins> Each capability option advertises one capability of the sender to the recipient. </ins> Setting options indicate a setting that will be applied by the sender.
Original text:
1.1. <del> The terminology from RFC7252 and STD94 applies.  Readers are also expected to be familiar with the terminology from RFC7807. </del>  In this document, the structure of data is specified in CDDL RFC8610 RFC9165.

Reviewer comments:
Start collecting changes from AD review
Comment by NAME : /example value 4711 not actually registered like this:/ ~~~ I don't get the sentence above - if this is to highlight that this is an example and that the value 4711 is not actually registered, I think this is redundant (and you could also add that in the Figure caption rather than in the example's text).
See : The danger that people are just blindly copying an example is just too high. So we would prefer to keep this redundant comment in. We could improve the wording of the comment.
Comment by NAME : Please explicitly state that the example (or examples if you add one in ) uses CBOR diagnostic notation.
Fixed in .
Closed by 7463ce1

Revised text:
1.1.  <ins> The terminology from RFC7252, STD94, and RFC8610 applies; in particular CBOR diagnostic notation is defined in STD94 and RFC8610. Readers are also expected to be familiar with the terminology from RFC7807. </ins> In this document, the structure of data is specified in CDDL RFC8610 RFC9165.
Original text:
be dereferenced in the normal course of handling problem details (i.e., outside diagnostic/debugging procedures involving humans). <del> An example of a custom extension using a URI as "custom-problem- detail-entries" key is shown in fig-example-custom-with-uri. </del>  Obviously, an SDO like 3GPP can also easily register such a custom problem detail entry to receive a more efficient unsigned integer <del> key; the same example but using a registered unsigned int as "custom- problem-detail-entries" key is shown in fig-example-custom-with-uint. </del>  In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically to the identifier of that Custom

Reviewer comments:
Start collecting changes from AD review
Comment by NAME : /example value 4711 not actually registered like this:/ ~~~ I don't get the sentence above - if this is to highlight that this is an example and that the value 4711 is not actually registered, I think this is redundant (and you could also add that in the Figure caption rather than in the example's text).
See : The danger that people are just blindly copying an example is just too high. So we would prefer to keep this redundant comment in. We could improve the wording of the comment.
Comment by NAME : Please explicitly state that the example (or examples if you add one in ) uses CBOR diagnostic notation.
Fixed in .
Closed by 7463ce1

Revised text:
be dereferenced in the normal course of handling problem details (i.e., outside diagnostic/debugging procedures involving humans).  <ins> fig-example-custom-with-uri shows an example (in CBOR diagnostic notation) of a custom extension using a (made-up) URI as "custom- problem-detail-entries" key. </ins> Obviously, an SDO like 3GPP can also easily register such a custom problem detail entry to receive a more efficient unsigned integer  <ins> key; fig-example-custom-with-uint shows how the same example would look like using a (made-up) registered unsigned int as "custom- problem-detail-entries" key: </ins> In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically to the identifier of that Custom
Original text:
calculation of the counter signature can be computed.  Details on computing counter signatures are found in counter_signature. <del> This parameter provides the time the content was created.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content was created. The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970. </del>  The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional

Reviewer comments:
It makes sense that we do not talk about creation time of the content. However the concept of having a time in the header is also very reasonable for things like countersignatures where one wants to make a timestamp as there is no content that the time marker can be placed in. We therefore change the text to make the time field be the time that the cryptographic operation was performed at.

Revised text:
calculation of the counter signature can be computed.  Details on computing counter signatures are found in counter_signature.  <ins> This parameter provides the time the content cryptographic operation is performed.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content structure was created.  The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970.  The field is primarily intended to be to be used for countersignatures, however it can additionally be used for replay detection as well. </ins> The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional
Original text:
1.3. There currently is no standard CBOR grammar available for use by <del> specifications.  In this document, we use a modified version of the CBOR data definition language (CDDL) defined in I-D.greevenbosch- appsawg-cbor-cddl.  The differences between the defined grammar and the one we used are mostly self explanatory.  The biggest difference being the addition of the choice operator '|'.  Additionally, note the use of the null value which is used to occupy a location in an array but to mark that the element is not present. </del>  2.

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
1.3. There currently is no standard CBOR grammar available for use by  <ins> specifications.  In this document, we use the grammar defined in the CBOR data definition language (CDDL) I-D.greevenbosch-appsawg-cbor- cddl. </ins> 2.
Original text:
contains the information about the plain text or encryption process that is to be integrity protected.  The field is encoded <del> in CBOR as a 'bstr' if present and the value 'null' if there is no </del>  data.  The contents of the protected field is a CBOR map of the protected data names and values.  The map is CBOR encoded before placing it into the bstr.  Only values associated with the current

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
contains the information about the plain text or encryption process that is to be integrity protected.  The field is encoded  <ins> in CBOR as a 'bstr' if present and the value 'nil' if there is no </ins> data.  The contents of the protected field is a CBOR map of the protected data names and values.  The map is CBOR encoded before placing it into the bstr.  Only values associated with the current
Original text:
would apply to multiple recipient structures. contains information about the plain text that is not integrity <del> protected.  If there are no field, then the value 'null' is used. </del>  Only values associated with the current cipher text are to be placed in this location even if the value would apply to multiple recipient structures. contains the initialization vector (IV), or it's equivalent, if one is needed by the encryption algorithm.  If there is no IV, <del> then the value 'null' is used. </del>  contains additional authenticated data (aad) supplied by the application.  This field contains information about the plain text data that is authenticated, but not encrypted.  If the application <del> does not provide this data, the value 'null' is used. </del>  contains the encrypted plain text.  If the cipherText is to be transported independently of the control information about the <del> encryption process (i.e. detached content) then the value 'null' is encoded here. </del>  contains the recipient information.  The field can have one of three data types:

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
would apply to multiple recipient structures. contains information about the plain text that is not integrity  <ins> protected.  If there are no field, then the value 'nil' is used. </ins> Only values associated with the current cipher text are to be placed in this location even if the value would apply to multiple recipient structures. contains the initialization vector (IV), or it's equivalent, if one is needed by the encryption algorithm.  If there is no IV,  <ins> then the value 'nil' is used. </ins> contains additional authenticated data (aad) supplied by the application.  This field contains information about the plain text data that is authenticated, but not encrypted.  If the application  <ins> does not provide this data, the value 'nil' is used. </ins> contains the encrypted plain text.  If the cipherText is to be transported independently of the control information about the  <ins> encryption process (i.e. detached content) then the value 'nil' is encoded here. </ins> contains the recipient information.  The field can have one of three data types:
Original text:
recipients can be encoded either this way or as a single array element. <del> A 'null' value if there are no recipients. </del>  4.1.

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
recipients can be encoded either this way or as a single array element.  <ins> A 'nil' value if there are no recipients. </ins> 4.1.
Original text:
4.1.1. In direct encryption mode, a shared secret between the sender and the <del> recipient is used as the CEK.  For direct encryption mode, no recipient structure is built.  All of the information about the key is placed in either the protected or unprotected fields at the content level.  When direct encryption mode is used, it MUST be the only mode used on the message.  It is a massive security leak to have both direct encryption and a different key management mode on the same message. </del>  For JOSE, direct encryption key management is the only key management method allowed for doing MAC-ed messages.  In COSE, all of the key

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
4.1.1. In direct encryption mode, a shared secret between the sender and the  <ins> recipient is used as the CEK.  When direct encryption mode is used, it MUST be the only mode used on the message.  It is a massive security leak to have both direct encryption and a different key management mode on the same message. </ins> For JOSE, direct encryption key management is the only key management method allowed for doing MAC-ed messages.  In COSE, all of the key
Original text:
The COSE_encrypt structure for the recipient is organized as follows: The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields <del> MUST be null. </del>  At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the shared secret.

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
The COSE_encrypt structure for the recipient is organized as follows: The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields  <ins> MUST be nil. </ins> At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the shared secret.
Original text:
The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'recipients' fields MUST be null. </del>  The plain text to be encrypted is the key from next layer down (usually the content layer).

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
The COSE_encrypt structure for the recipient is organized as follows:  <ins> The 'protected', 'aad', and 'recipients' fields MUST be nil. </ins> The plain text to be encrypted is the key from next layer down (usually the content layer).
Original text:
4.1.4. Direct Key Agreement derives the CEK from the shared secret computed <del> by the key agreement operation.  For Direct Key Agreement, no recipient structure is built.  All of the information about the key and key agreement process is placed in either the 'protected' or 'unprotected' fields at the content level. </del>  When direct key agreement mode is used, it SHOULD be the only mode used on the message.  This method creates the CEK directly and that

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
4.1.4. Direct Key Agreement derives the CEK from the shared secret computed  <ins> by the key agreement operation. </ins> When direct key agreement mode is used, it SHOULD be the only mode used on the message.  This method creates the CEK directly and that
Original text:
The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del>  At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key.

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
The COSE_encrypt structure for the recipient is organized as follows:  <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key.
Original text:
The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del>  The plain text to be encrypted is the key from next layer down (usually the content layer).

Reviewer comments:
The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.

Revised text:
The COSE_encrypt structure for the recipient is organized as follows:  <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> The plain text to be encrypted is the key from next layer down (usually the content layer).
Original text:
The following values are used for L: <del> limits messages to 2^16 bytes in length.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </del>  limits messages to 2^64 byes in length.  The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without

Reviewer comments:
Assign integer tags to the CCM modes that we are keeping. Remove the 192-bit key CCM modes from the table. Update example using CCM

Revised text:
The following values are used for L:  <ins> limits messages to 2^16 bytes (64Kbyte) in length.  This sufficently long for messages in the constrainted world.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </ins> limits messages to 2^64 byes in length.  The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without
Original text:
7. Security considerations for DetNet are described in detail in I- <del> D.ietf-detnet-security.  This section considers exclusively security considerations which are specific to the DetNet 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

Reviewer comments:
Sorry, now it is uploaded to the right folder. Simple accept pull request. Thx Bala'zs

Revised text:
7. Security considerations for DetNet are described in detail in I-  <ins> D.ietf-detnet-security.  General security considerations are described in I-D.ietf-detnet-architecture.  This section considers exclusively security considerations which are specific to the DetNet IP 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
Original text:
10. <del> The first example shows a deprecation header field without date information: The second example shows a deprecation header with date information </del>  and a link to the successor version: <del> The third example shows a deprecation header field with links for the successor version and for the API's deprecation policy.  In addition, it shows the sunset date for the deprecated resource: </del> 

Reviewer comments:
Looks good to me.
... are considered a 'bad smell'. Instead of a date vs. a fixed string, could we just say that a date in the past is equal to 'true'?
i guess we could. and we already say that a date in the past means that the resource is deprecated. the motivation to allow a flag was to not force services to make up a date when they don't have one and simply want to flag something as deprecated. but we could also "force" them to make up a date by not allowing the "true" flag. i am fine either way and i do see the point that the syntax may cause some implementations to not parse the field correctly. maybe others can weigh in as well?
FWIW, I see it like Expires -- if it's already stale, you just assign a date in the past.
i could definitely live with such a design.
One use case was to align the header's usage with API contract as defined using OpenAPI. Having boolean helps align this header with OpenAPI's flag which does not require date. Forcing API developers to add a random date in the past in case if it is not available due toe various reasons would not be desirable for various other reasons (SLA?). Although, I wish that OpenAPI adds date for . >If the deprecation date is not known, the header field can carry the simple string "true", indicating that the resource context is deprecated, without indicating when that happened: On Jul 31, 2021, at 06:46, Mark Nottingham NAME wrote: FWIW, I see it like Expires -- if it's already stale, you just assign a date in the past.
For Expires, January 1 1970 (epoch 0) is widely used.
NAME I wish OpenAPI supported deprecated date also. But when we do, it won't be with a property that can be boolean or date.
Ok NAME thanks for clarification on the OpenAPI side of things. I agree. We can just use date. There are some implementations out there, I would not know if any of those use boolean but since we are not an RFC yet, such a change should not be unexpected.
it seems like we can safely remove the alternative syntax. i have created a PR asking for review by NAME
LGTM

Revised text:
10.  <ins> The first example shows a deprecation header with date information </ins> and a link to the successor version:  <ins> The second example shows a deprecation header field with links for the successor version and for the API's deprecation policy.  In addition, it shows the sunset date for the deprecated resource: </ins>
Original text:
unsigned CNAME records that may have been synthesized in the response from a DNS resolver. <del> The subsequent RRsets MUST contain the full sequence of DNS records needed to authenticate the TLSA record set from the server's trust anchor.  Typically this means a sequence of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone. </del>  Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree.  In this case, the authentication

Reviewer comments:
Small tweak to text to make clearer that validation RRsets can be in any order.

Revised text:
unsigned CNAME records that may have been synthesized in the response from a DNS resolver.  <ins> The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set from the server's trust anchor. Typically this means a set of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone.  The TLS client should be prepared to receive this set of RRsets in any order. </ins> Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree.  In this case, the authentication