jiebi/TextFlow huggingface dataset:
Original text:
value is used to indicate the number of seconds, excluding leap seconds, since the start of the year 1970 in UTC.  Representing the statistical characteristics of measurements, such as accuracy, can be very complex.  Future specification may add new attributes to provide better information about the statistical

Reviewer comments:
Clarify semantics of base time 0 ("now")
For base time, draft already has If either the Base Time or Time value is missing, the missing attribute is considered to have a value of zero.

Revised text:
value is used to indicate the number of seconds, excluding leap seconds, since the start of the year 1970 in UTC. <ins> If only one of the Base Sum or Sum value is present, the missing attribute is considered to have a value of zero.  The Base Sum and Sum values are added together to get the sum of measurement.  If neither the Base Sum or Sum are present, then the measurement does not have a sum value. </ins> Representing the statistical characteristics of measurements, such as accuracy, can be very complex.  Future specification may add new attributes to provide better information about the statistical
Original text:
and has gotten two separate values as a result, a temperature and humidity measurement.  6. The CBOR RFC7049 representation is equivalent to the JSON

Reviewer comments:
Current text hints that you can use SenML also with actuators, but there is not much details about this yet.
+1 For actuators. But the ability to set any arbitrary value would be preferred - for example the coefficients of an analog sensor, or a flag to initiate a sensor update.
I did not get this into the -03 update but still plan to add it.
I did not get this into the -03 update but still plan to add it.
Comments on the examples

Revised text:
and has gotten two separate values as a result, a temperature and humidity measurement. <ins> 5.1.7. The following example show the SenML that could be used to set the current set point of a typical residential thermostat which has a temperature set point, a switch to turn on and off the heat, and a switch to turn on the fan override. In the following example two different lights are turned on.  It is assumed that the lights are on a 802.1BA network that can guarantee delivery of the messages to the two lights within 15 ms and uses 802.1AS for time synchronization.  The controller has set the time of the lights coming on to 20 ms in the future from the current time. This allows both lights to receive the message, wait till that time, then apply the switch command so that both lights come on at the same time. The following shows two lights being turned off using a non deterministic network that has a high odds of delivering a message in less than 100 ms and uses NTP for time synchronization.  The curent time is 1320078429.  The user has just turned off a light switch which is turning off two lights.  Both lights are dimmed to 50% brightness immediately to give the user instant feedback that something is changing.  However given the network, the lights will probably dim at somewhat different times.  Then 100 ms in the future, both lights will go off at the same time.  The instant but not synchronized dimming gives the user the sensation of quick responses and the timed off 100 ms in the future gives the perception of both lights going off at the same time. </ins> 6. The CBOR RFC7049 representation is equivalent to the JSON
Original text:
format in the first place.  The relevant media type indicator is included in the Content-Type (ct=) attribute.  5. The SenML labels (JSON object member names) shown in tbl-json-labels

Reviewer comments:
Added descriptive text about configuration/actuation usage
Addressing issue
Should there be explanation of the configuration usage?
This looks good to me. Two little tweeks but if you don't like them, I can live with it as it is.

Revised text:
format in the first place.  The relevant media type indicator is included in the Content-Type (ct=) attribute. <ins> 4.6. SenML can also be used for configuring parameters and controlling actuators.  When a SenML Pack is sent (e.g., using a HTTP/CoAP POST or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given resources (names) to given values at the given time(s). </ins> 5. The SenML labels (JSON object member names) shown in tbl-json-labels
Original text:
used with care or avoided as described in RFC7721. The resulting concatenated name MUST consist only of characters out <del> of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name. </del>  If the Record has no Unit, the Base Unit is used as the Unit.  Having no Unit and no Base Unit is allowed.

Reviewer comments:
The actually change looks good to me and if we fail to get all the examples correctly generated, don't worry, we can clean that up during WGLC

Revised text:
used with care or avoided as described in RFC7721. The resulting concatenated name MUST consist only of characters out  <ins> of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name. </ins> If the Record has no Unit, the Base Unit is used as the Unit.  Having no Unit and no Base Unit is allowed.
Original text:
Magic number(s): none <del> File extension(s): senml </del>  Macintosh file type code(s): none Magic number(s): none <del> File extension(s): senml </del>  Macintosh file type code(s): none Magic number(s): none <del> File extension(s): senml </del>  Macintosh file type code(s): none Magic number(s): none <del> File extension(s): senml </del>  Macintosh file type code(s): none

Reviewer comments:
Why is there no sensml+cbor? (I can't really find where sensml+json is actually defined.) Is that really TODO?
sensml+json is defined in "Multiple Datapoints". Perhaps could be improved. That TODO was fixed in URL
That is an example, no? Where is the definition?
(In CBOR, SensML would just be a CBOR sequence. No need even for an array around that.) See also RFC 7464...

Revised text:
Magic number(s): none  <ins> File extension(s): senml and sensml </ins> Macintosh file type code(s): none Magic number(s): none  <ins> File extension(s): senmlc </ins> Macintosh file type code(s): none Magic number(s): none  <ins> File extension(s): senmlx and sensmlx </ins> Macintosh file type code(s): none Magic number(s): none  <ins> File extension(s): senmle </ins> Macintosh file type code(s): none
Original text:
strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! <del> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC5226.  Experts should exercise their own good judgment but need to consider the following guidelines: </del>  There needs to be a real and compelling use for any new unit to be added. does not lose any information from the JSON value.  EXI uses the XML types. <del> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC5226.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </del>  All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that

Reviewer comments:
Is there a reason we keep it for label registrations?
NAME Good point; same considerations apply to both. Will fix.
From Peter's review: or IESG Approval as defined in [RFC5226]. confusion.
It means that if something needs to happen and AD can make it happen without firing the expert which creates so much bad will that an AD would much rather wit 6 months for the expert to respond. All it says if the AD can do this or the expert can. I don't care much.
NAME Our AD had preference to have just Expert review in order for people to not think there are two paths but show clear preference. If things are slow, the IESG is next on the appeal path, so ADs can do it anyway.
Addressed by PR
Note that even with we still have the dual policy on the labels. Bug or feature?
On the "Our AD had preference to have just Expert review " ... I'm fine with this.
NAME The dual policy was fixed with the latest commit. Although perhaps we want to have more guidelines for the expert to follow?

Revised text:
strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio!  <ins> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider the following guidelines: </ins> There needs to be a real and compelling use for any new unit to be added. does not lose any information from the JSON value.  EXI uses the XML types.  <ins> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that
Original text:
or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as <del> names) to given values at the given time(s). </del>  5.

Reviewer comments:
target are such that SenML is interpreted as configuration/actuation"? And aren't configuration and actuation quite different use cases? These semantics need to be established out of band from SenML point of view. Could be something like CoRE interface type or LwM2M resource type that accepts SenML for this purpose. But we don't want to be prescriptive here. Perhaps giving example(s) is good approach
Addressed by PR

Revised text:
or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as  <ins> names) to given values at the given time(s).  The semantics of the target resource supporting this usage can be described, e.g., using I-D.ietf-core-interfaces.  Examples of actuation usage are shown in thermo-ex. </ins> 5.
Original text:
7.2. The cipher suites defined in this draft use short authentication tags <del> for both inner and outer encryption, however it can easily support other ciphers with full authentication tag if the short ones are proved insecure. </del>  8.

Reviewer comments:
I don't think we should not reference the inner/outer encryption, as we only define the e2ee encryption in the draft

Revised text:
7.2. The cipher suites defined in this draft use short authentication tags  <ins> for encryption, however it can easily support other ciphers with full authentication tag if the short ones are proved insecure. </ins> 8.
Original text:
media metadata The IV is 128 bits long and calculated from the CTR field of the <del> Frame header: </del>  4.3.2.

Reviewer comments:
Add more information for how the CTR is used to derive the final IV
The current IV equation is IVCounter XOR SaltKey. This will lead to IV reuse across multiple blocks in AES-CTR for example Frame 0 AES(0) XOR Block0, AES(1) XOR Block1, AES(2) XOR Block2,... Frame 1 AES (1) XOR Block0, AES(2) XOR Block1, AES(3) XOR Block2,.. Frame 2 AES(2) XOR Block0, AES(3) XOR Block1, AES(4) XOR Block2,... The equation should be changed to shift the frame counter to high significant 8 bytes and the other 8 bytes will be zeros then do the XOR FrameCounter8 = DecodeVarIntIntoInt64(counter) FrameCounter16 = FrameCounter << 8 IV = FrameCounter16 XOR SaltKey
lgtm

Revised text:
media metadata The IV is 128 bits long and calculated from the CTR field of the  <ins> Frame header.  First the var int CTR is decoded into 16 bytes long field, where CTR fills the the 8 most significant bytes and low 8 bytes are always filled with zeros: </ins> 4.3.2.
Original text:
9. This document makes no requests of IANA. 

Reviewer comments:
This PR adds test vectors for SFrame encryption. A Go script is provided that implements the header encoding and the relevant encryption routines, generates test vectors for salient cases, and serializes them as Markdown or JSON. The Markdown version is included in the specification directly.

Revised text:
9. This document makes no requests of IANA. <ins> 10. This section provides a set of test vectors that implementations can use to verify that they correctly implement SFrame encryption and decryption.  For each ciphersuite, we provide: [in] The "base_key" value (hex encoded) [out] The "secret", "key", and "salt" values derived from the "base_key" (hex encoded) A plaintext value that is encrypted in the following encryption cases A sequence of encryption cases, including: [in] The "KID" and "CTR" values to be included in the header [out] The resulting encoded header (hex encoded) [out] The nonce computed from the "salt" and "CTR" values The ciphertext resulting from encrypting the plaintext with these parameters (hex encoded) An implementation should reproduce the output values given the input values.  Encryption with the input values and the plaintext should produce the ciphertext.  Decryption with the input values and the ciphertext should produce the plaintext. Line breaks and whitespace within values are inserted to conform to the width requirements of the RFC format.  They should be removed before use.  These test vectors are also available in JSON format at TestVectors. 10.1. 10.2. 10.3. 10.4. </ins>
Original text:
hash function: The AEAD encryption and decryption functions are then composed of <del> individual calls to the CM encrypt function and HMAC.  The resulting </del>  MAC value is truncated to a number of bytes "tag_len" fixed by the ciphersuite.

Reviewer comments:
I wasn't sure if CM was meant for "Counter Mode", if so, I thought using the standard terminology would be better... : )
I also originally got very confused by the CM acronym so definitely suggest taking the change.
NAME would you be able to rebase your commit?
NAME Should be good now. (~Note that I did not update the label in to avoid affecting the test vectors.~ Pushed a commit with updated test vectors.)
This PR looks good to me. I agree with the terminology change and the changes to the known-answer test generator. I re-ran the known-answer test generator locally and confirmed that it produced the test vectors in the PR.LGTM. This might conflict with URL depending on which PR gets merged first.

Revised text:
hash function: The AEAD encryption and decryption functions are then composed of  <ins> individual calls to the CTR encrypt function and HMAC.  The resulting </ins> MAC value is truncated to a number of bytes "tag_len" fixed by the ciphersuite.
Original text:
S/MIME receiving agents during certificate and CRL signature verification: <del> For 512-bit RSA with SHA-1 see RFC3279 and FIPS186-2 without Change Notice 1, for 512-bit RSA with SHA-256 see RFC4055 and FIPS186-2 without Change Notice 1, for 1024-bit through 3072-bit RSA with SHA-256 see RFC4055 and FIPS186-2 with Change Notice 1, and for 4096-bit RSA with SHA-256 see RFC4055 and RFC3447.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. For 512-bit DSA with SHA-1 see RFC3279 and FIPS186-2 without Change Notice 1, for 512-bit DSA with SHA-256 see RFC5758 and FIPS186-2 without Change Notice 1, for 1024-bit DSA with SHA-1 see RFC3279 and FIPS186-2 with Change Notice 1, for 1024-bit through 3072 DSA with SHA-256 see RFC5758 and FIPS186-3.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </del>  For RSASSA-PSS with SHA-256 see RFC4056.  4.4. PKIX describes an extensible framework in which the basic certificate

Reviewer comments:
Move the pointer to docs for historical algorithms to the historic appendix. Correct the fact that this is now a WG document.

Revised text:
S/MIME receiving agents during certificate and CRL signature verification:  <ins> For 1024-bit through 3072-bit RSA with SHA-256 see RFC4055 and FIPS186-2 with Change Notice 1, and for 4096-bit RSA with SHA-256 see RFC4055 and RFC3447.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </ins> For RSASSA-PSS with SHA-256 see RFC4056. <ins> For ECDSA see RFC5758 and RFC6090.  The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. For EdDSA see I-D.ietf-curdle-pkix and I-D.irtf-cfrg-eddsa.  The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </ins> 4.4. PKIX describes an extensible framework in which the basic certificate
Original text:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The- <del> Middle attack by the fronting service. </del>  The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to [1]. Thanks to Daniel Kahn Gillmor for a pretty detailed review of the <del> initial draft.  Thanks to Stephen Farrell, Mark Orchezowski, Martin Rex and Martin Thomson for their reviews. </del>  8.  References

Reviewer comments:
Two sets of comments from Mark O, received after WGLC. One is a reference to the acknowledgement section, in which he would rather not see his name spelled out. The other is about residual risks of fronting server spoofing when only the hidden service is verified in TLS.

Revised text:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The-  <ins> Middle attack by the fronting service.  The downside is the the client will not verify the identity of the fronting service with risks discussed in {#frontingspoofing}, but solutions will have to mitigate this risks.  Overall, end-to-end TLS to the protected service is preferable. </ins> The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to [1]. Thanks to Daniel Kahn Gillmor for a pretty detailed review of the  <ins> initial draft.  Thanks to Stephen Farrell, Martin Rex Martin Thomson and employees of the UK National Cyber Security Centre for their reviews. </ins> 8.  References
Original text:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The- <del> Middle attack by the fronting service.  The downside is the the client will not verify the identity of the fronting service with risks discussed in {#frontingspoofing}, but solutions will have to mitigate this risks.  Overall, end-to-end TLS to the protected service is preferable. </del>  The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to

Reviewer comments:
The delayed merge of PR left a dangling reference in the markdown source. This is an attempt to fix the issue.

Revised text:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The-  <ins> Middle attack by the fronting service.  The downside is that the client will not verify the identity of the fronting service, which enables fronting server spoofing attacks such as the "honeypot" attack discussed below.  Overall, end-to-end TLS to the protected service is preferable, but it is important to also provide a way to authenticate the fronting service. </ins> The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to
Original text:
httpfronting. This document does not present the design of a solution, but provides <del> guidelines for evaluating proposed solutions.  The need for related work on the encryption of the Application Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in hiding-alpn. </del>  2. They include: The SNI is probably also included in the general collection of <del> metadata by pervasive surveillance actors, for example to identify services used by surveillance targets. </del>  2.2. solutions that could quickly reach large scale deployments. Replacing clear text SNI transmission by an encrypted variant will <del> also thwart MITM interferences that are sometimes described as legitimate.  As explained in end-to-end, alternative solutions will have to be developed. </del>  6.

Reviewer comments:
Trying to address the last comments (issue ).
NAME I hope this reflects our discussion.
Checking in after Roman's comments on the list.

Revised text:
httpfronting. This document does not present the design of a solution, but provides  <ins> guidelines for evaluating proposed solutions.  (The review of HTTP- level solutionsin httpfronting is not an endorsement of these solutions.)  The need for related work on the encryption of the Application Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in hiding-alpn. </ins> 2. They include: The SNI is probably also included in the general collection of  <ins> metadata by pervasive surveillance actors RFC7258, for example to identify services used by surveillance targets. </ins> 2.2. solutions that could quickly reach large scale deployments. Replacing clear text SNI transmission by an encrypted variant will  <ins> break or reduce the efficacy of the operational practices and techniques implemented in middle-boxes as described in snileak.  As explained in end-to-end, alternative solutions will have to be developed. </ins> 6.