jiebi/TextFlow huggingface dataset:
Original text:
2. The design goal is to be able to send simple sensor measurements in <del> small packets on mesh networks from large numbers of constrained devices.  Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor. Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </del>  The basic design is an array with a series of measurements.  The following example shows two measurements made at different times.

Reviewer comments:
100 bytes? (Here again I'd remove the text about mesh networks.) mesh networks result in about 80 bytes of usable payload per packet without fragmentation. How about we say keeping it small is good and quote examples of 802.15.4 has about 80 byte payload and that LoRa has 51 byte of applications payload in long range mode and just remove any reference to "mesh"
I'm fine with suggestion above. I'm also fine with just leaving draft as is.
Addressed by PR

Revised text:
2. The design goal is to be able to send simple sensor measurements in  <ins> small packets from large numbers of constrained devices.  Keeping the total size of payload small makes it easy to use SenML also in constrained networks, e.g., in a 6LoWPAN RFC4944.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor.  Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </ins> The basic design is an array with a series of measurements.  The following example shows two measurements made at different times.
Original text:
fields to provide better information about the statistical properties of the measurement.  4.4. Sometimes it is useful to be able to refer to a defined normalized

Reviewer comments:
Dave's comments: The issue is that neither of the above have an asterisk by them, so both are recommended and per Carsten’s definition of “units” during the meeting (i.e., where the reference point is separate from the units), then Kelvin and Celsius have the same units as they only vary by what the reference point is.

Revised text:
fields to provide better information about the statistical properties of the measurement. <ins> In summary, the structure of a SenML record is laid out to support a single measurement per record.  If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate records linked through their Time value; this is even true where one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time). </ins> 4.4. Sometimes it is useful to be able to refer to a defined normalized
Original text:
as mile, foot, light year are not allowed.  For most cases, the SI unit is preferred.  Symbol names that could be easily confused with existing common units or units combined with prefixes should be avoided.  For example, selecting a unit name of "mph" to indicate something that

Reviewer comments:
Dave's comments: The issue is that neither of the above have an asterisk by them, so both are recommended and per Carsten’s definition of “units” during the meeting (i.e., where the reference point is separate from the units), then Kelvin and Celsius have the same units as they only vary by what the reference point is.

Revised text:
as mile, foot, light year are not allowed.  For most cases, the SI unit is preferred. <ins> (Note that some amount of judgement will be required here, as even SI itself is not entirely consistent in this respect.  For instance, for temperature ISO-80000-5 defines a quantity, item 5-1 (thermodynamic temperature), and a corresponding unit 5-1.a (Kelvin), and then goes ahead to define another quantity right besides that, item 5-2 ("Celsius temperature"), and the corresponding unit 5-2.a (degree Celsius).  The latter quantity is defined such that it gives the thermodynamic temperature as a delta from T0 = 275.15 K.  ISO 80000-5 is defining both units side by side, and not really expressing a preference.  This level of recognition of the alternative unit degree Celsius is the reason why Celsius temperatures exceptionally seem acceptable in the SenML units list alongside Kelvin.) </ins> Symbol names that could be easily confused with existing common units or units combined with prefixes should be avoided.  For example, selecting a unit name of "mph" to indicate something that
Original text:
does not lose any information from the JSON value.  EXI uses the XML types. <del> 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. </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:
Dave's comments: The issue is that neither of the above have an asterisk by them, so both are recommended and per Carsten’s definition of “units” during the meeting (i.e., where the reference point is separate from the units), then Kelvin and Celsius have the same units as they only vary by what the reference point is.

Revised text:
does not lose any information from the JSON value.  EXI uses the XML types.  <ins> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review.  New entries should not be made that counteract the advice at the end of considerations. </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:
3- Authentication key to authenticate the encrypted frame and the media metadata <del> The IV is 128 bits long and calculated from the SRC and CTR field of the Frame header: </del>  3.2.2.

Reviewer comments:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

Revised text:
3- Authentication key to authenticate the encrypted frame and the media metadata  <ins> The IV is 128 bits long and calculated from the CTR field of the Frame header: </ins> 3.2.2.
Original text:
5.1.2. <del> The sender of a simulcast stream may use the same SRC for all the simulcast streams from the same media source or use a different SRC for each of them, in any case it is transparent to the SFU which will be able to perform the simulcast layer switching normally.  The senders are already able to receive different SRCs from different participants due to LastN and RTP Stream reuse, so supporting simulcast uses same mechanisms. </del>  5.1.3.

Reviewer comments:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

Revised text:
5.1.2.  <ins> When using simulcast, the same input image will produce N different encoded frames (one per simulcat layer) which would be processed inpependently by the frame encryptor and assigned an unique counter for each. </ins> 5.1.3.
Original text:
sizes or frames per second.  In order to support it, the sender MUST encode each spatial layer of a given picture in a different frame. That is, an RTP frame may contain more than one SFrame encrypted <del> frame with same source (SRC) and incrementing frame counter. </del>  5.2.

Reviewer comments:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

Revised text:
sizes or frames per second.  In order to support it, the sender MUST encode each spatial layer of a given picture in a different frame. That is, an RTP frame may contain more than one SFrame encrypted  <ins> frame with an incrementing frame counter. </ins> 5.2.
Original text:
Secure Frame (SFrame) <del> draft-omara-sframe-01 </del>  Abstract

Reviewer comments:
This: Changes the name of the draft (I made something up, but you are free to suggest a different name) Adds venue information to the draft (working group, area, stream, github, etc...) Updates some of the boilerplate stuff (README, CONTRIBUTING, .gitignore, Makefile) Adds workflows for CI with GitHub Actions Cleans up trailing whitespace (with ) so that the build runs cleanly Updates the Gemfile (I don't use this, but I tried to make it functional for those that do) From here, you should be able to create a first submission of a draft-ietf-sframe-enc-00 by pushing a tag of draft-ietf-sframe-enc-00 (or making a new release with that name).
Spec changes look ok since they are editorial/ NAME is this ready to go?
You should be able to merge this and use it straight away, if that is what you want to do (the only thing that might need attention is the proposed filename, which I just made up).

Revised text:
Secure Frame (SFrame)  <ins> draft-ietf-sframe-enc-latest </ins> Abstract
Original text:
a RESTful API. Different protocols can be used with RESTful systems, but at the time <del> of writing the most common protocols are HTTP RFC7230 and CoAP </del>  RFC7252.  Since RESTful APIs are often lightweight and enable loose coupling of system components, they are a good fit for various Internet of Things (IoT) applications, which in general aim at

Reviewer comments:
Updating HTTP references to RFC9110 and RFC9112. Moving CoAP reference to normative to be consistent with other references.
; httpbis-messaging/-semantics/-cache are in the RFC editor queue and will be published before this document. URL
They actually have been published.
Thanks!

Revised text:
a RESTful API. Different protocols can be used with RESTful systems, but at the time  <ins> of writing the most common protocols are HTTP RFC9110 and CoAP </ins> RFC7252.  Since RESTful APIs are often lightweight and enable loose coupling of system components, they are a good fit for various Internet of Things (IoT) applications, which in general aim at
Original text:
3.5. <del> Section 4.3 of RFC7231 defines the set of methods in HTTP; </del>  Section 5.8 of RFC7252 defines the set of methods in CoAP.  As part of the Uniform Interface constraint, each method can have certain properties that give guarantees to clients.

Reviewer comments:
Updating HTTP references to RFC9110 and RFC9112. Moving CoAP reference to normative to be consistent with other references.
; httpbis-messaging/-semantics/-cache are in the RFC editor queue and will be published before this document. URL
They actually have been published.
Thanks!

Revised text:
3.5.  <ins> Section 9.3 of RFC9110 defines the set of methods in HTTP; </ins> Section 5.8 of RFC7252 defines the set of methods in CoAP.  As part of the Uniform Interface constraint, each method can have certain properties that give guarantees to clients.
Original text:
3.6. <del> Section 6 of RFC7231 defines a set of Status Codes in HTTP that are </del>  assigned by the server to indicate whether a request was understood and satisfied, and how to interpret the answer.  Similarly, Section 5.9 of RFC7252 defines the set of Response Codes in CoAP. <del> The status codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code.  Implementations do not need to understand all status codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </del>  available in CoAP).  Codes starting with 2 indicate a successful request.  Codes starting with 3 indicate redirection; further action is needed to complete the request (not available in CoAP).  Codes

Reviewer comments:
Updating HTTP references to RFC9110 and RFC9112. Moving CoAP reference to normative to be consistent with other references.
; httpbis-messaging/-semantics/-cache are in the RFC editor queue and will be published before this document. URL
They actually have been published.
Thanks!

Revised text:
3.6.  <ins> Section 15 of RFC9110 defines a set of Status Codes in HTTP that are </ins> assigned by the server to indicate whether a request was understood and satisfied, and how to interpret the answer.  Similarly, Section 5.9 of RFC7252 defines the set of Response Codes in CoAP.  <ins> The codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code. Implementations do not need to understand all codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </ins> available in CoAP).  Codes starting with 2 indicate a successful request.  Codes starting with 3 indicate redirection; further action is needed to complete the request (not available in CoAP).  Codes
Original text:
Internet X.509 Public Key Infrastructure: <del> HTTP security: Section 9 of RFC7230, Section 9 of RFC7231, etc. </del>  CoAP security:

Reviewer comments:
Updating HTTP references to RFC9110 and RFC9112. Moving CoAP reference to normative to be consistent with other references.
; httpbis-messaging/-semantics/-cache are in the RFC editor queue and will be published before this document. URL
They actually have been published.
Thanks!

Revised text:
Internet X.509 Public Key Infrastructure:  <ins> HTTP security: Section 11 of RFC9112, Section 17 of RFC9110, etc. </ins> CoAP security:
Original text:
7. <del> This document has no IANA actions. </del>  8.

Reviewer comments:
TBH I don't really know if this is actually needed.
Whoops that was supposed to be about it's good to merge. We need this section to tell IANA to register the exporter.
NAME do you mind amending this to add:
Added section about exporter labels as well.

Revised text:
7.  <ins> 7.1. IANA is requested to update the entry for server_name(0) in the registry for ExtensionType (defined in TLS13) by replacing the value in the "TLS 1.3" column with the value "CH, EE, CR". 7.2. IANA is requested to add the following entries to the registry for Exporter Labels (defined in RFC5705): "EXPORTER-server authenticator handshake context", "EXPORTER-client authenticator finished key" and "EXPORTER-server authenticator finished key". </ins> 8.
Original text:
Abstract The organizational separation between the operator of a TLS server <del> and the certificate authority can create limitations.  For example, </del>  the lifetime of certificates, how they may be used, and the <del> algorithms they support are ultimately determined by the certificate authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. </del>  1.

Reviewer comments:
Just some nits.
The public key name and type have been changed in , as NAME suggested on the mailing list.
NAME beat me to it!
oh looks like the travis build is failing for some reason
NAME I have no idea why pushing that worked ...
awesomesauce. it's probably some temporary failure while trying to fetch the new references or something

Revised text:
Abstract The organizational separation between the operator of a TLS server  <ins> and the certification authority can create limitations.  For example, </ins> the lifetime of certificates, how they may be used, and the  <ins> algorithms they support are ultimately determined by the certification authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. </ins> 1.
Original text:
operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely <del> on an external CA for such short-lived credentials.  In OCSP stapling, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled </del>  response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which

Reviewer comments:
Just some nits.
The public key name and type have been changed in , as NAME suggested on the mailing list.
NAME beat me to it!
oh looks like the travis build is failing for some reason
NAME I have no idea why pushing that worked ...
awesomesauce. it's probably some temporary failure while trying to fetch the new references or something

Revised text:
operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely  <ins> on an external CA for such short-lived credentials.  In OCSP stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled </ins> response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which