jiebi/TextFlow huggingface dataset:
Original text:
5.1. <del> IANA is requested to create a new registry for "EKT Messages Types". The initial values in this registry are: </del>  Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. 5.2. <del> IANA is requested to create a new registry for "EKT Ciphers".  The </del>  initial values in this registry are: Note to RFC Editor: Please replace RFCAAAA with the RFC number for

Reviewer comments:
Ignoring my concern and bias over extensibility with EKT :), this looks fine.
Should the registries be part of the SDP or RTP parameters group? I.e., collected together with the other SDP parameters?

Revised text:
5.1.  <ins> IANA is requested to create a new table for "EKT Messages Types" in the "Real-Time Transport Protocol (RTP) Parameters" registry.  The initial values in this registry are: </ins> Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. 5.2.  <ins> IANA is requested to create a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) Parameters" registry.  The </ins> initial values in this registry are: Note to RFC Editor: Please replace RFCAAAA with the RFC number for
Original text:
The last byte is used to indicate the type of the EKTField.  This MUST be 2 in the FullEKTField format and 0 in ShortEKTField <del> format.  Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented. </del>  2.2.

Reviewer comments:
If anyone has ideas on how to write this is a more clear way, love any suggestions ...
s2.1, MessageType Maybe it’s late but I’m having trouble parsing this sentence: Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented. Can “and is not implemented” be dropped?

Revised text:
The last byte is used to indicate the type of the EKTField.  This MUST be 2 in the FullEKTField format and 0 in ShortEKTField  <ins> format.  Values less than 64 are mandatory to understand while other values are optional to understand.  A receiver SHOULD discard the whole EKTField if it contains any message type value that is less than 64 and that is not understood.  Message type values that are 64 or greater but not implemented or understood can simply be ignored. </ins> 2.2.
Original text:
Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. <del> All EKT message other that ShortEKTField must have a length as </del>  second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type.

Reviewer comments:
s2.1, EKTMsgLength Should this be “MUST”: All EKT message other that ShortEKTField must have ...

Revised text:
Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity.  <ins> All EKT message other that ShortEKTField MUST have a length as </ins> second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type.
Original text:
When an SRTP or SRTCP packet contains a ShortEKTField, the ShortEKTField is removed from the packet then normal SRTP or SRTCP processing occurs.  If the packet contains a FullEKTField, then <del> processing continues as described below. </del>  The Security Parameter Index (SPI) field is used to find which EKT parameter set to be used when processing the packet.  If there is

Reviewer comments:
Does this way of phrasing it look better ?
2) s2.2.2, : I gotta ask why the MessageType byte isn’t first? Wouldn’t putting the MessageType first allow you avoid buffering everything before proceeding? It seems like you’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations.

Revised text:
When an SRTP or SRTCP packet contains a ShortEKTField, the ShortEKTField is removed from the packet then normal SRTP or SRTCP processing occurs.  If the packet contains a FullEKTField, then  <ins> processing continues as described below.  The reason for using the last byte of the packet to indicate the type is that the length of the SRTP or SRTCP part is not known until the decryption has occurred.  At this point in the processing, there is no easy way to know where the EKT field would start.  However, the whole UDP packet has been received so instead of the starting at the front of the packet, the parsing works backwards off the end of the packet and thus the type is put at the very end of the packet. </ins> The Security Parameter Index (SPI) field is used to find which EKT parameter set to be used when processing the packet.  If there is
Original text:
The following shows the syntax of the EKTField expressed in ABNF RFC5234.  The EKTField is added to the end of an SRTP or SRTCP <del> packet.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </del>  These fields and data elements are defined as follows:

Reviewer comments:
s2.1, EKTPlaintext Probably over thinking this, but is the concatentation like so: +--------------+--------+--------+ +-------------+---------+--------+ I’d be afraid somebody would think it’s the other way around without being more specific. Maybe it’s as easy as: putting something like "SRTP MK denotes concatenation” s omewhere in the paragraph.

Revised text:
The following shows the syntax of the EKTField expressed in ABNF RFC5234.  The EKTField is added to the end of an SRTP or SRTCP  <ins> packet.  The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </ins> These fields and data elements are defined as follows:
Original text:
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> RFC3711, as those SRTP features <del> duplicate some of the functions of EKT. </del>  2.1.

Reviewer comments:
Section 2 (para 2) EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's [RFC3711], as those SRTP features duplicate some of the functions of EKT. Same issue has be raised by Spt >>>What happens if an implementation does use SRTP's MKI or with SRTP's ? Is an error thrown?
I do expect they'd check, because they have to know how to parse the packet and where to insert the EKT field. With EKT, the key to use is conveyed via the RTP packet. Only after the EKT field is parsed would it make sense to look to find an MKI value. In any case, if MKI is used it's just redundant. One thing I didn't see in reviewing the current specs is where the EKT field should be inserted. It should be inserted on the inner encryption step of double. The outer encryption is consumed by intermediaries and they don't understand EKT. We probably need to put that back into the framework document. The packet format was removed during one revision.
opened new bug for where EKT goes

Revised text:
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> RFC3711, as those SRTP features  <ins> duplicate some of the functions of EKT.  Senders MUST not include MKI when using EKT.  Receivers SHOULD simply ignore any MKI field received if EKT is in use. </ins> 2.1.
Original text:
Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. <del> All EKT message other that ShortEKTField MUST have a length as second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type. </del>  The last byte is used to indicate the type of the EKTField.  This MUST be 2 in the FullEKTField format and 0 in ShortEKTField values over odd ones until the even code points are consumed to avoid conflicts with pre standard versions of EKT that have been deployed.  5.2. IANA is requested to create a new table for "EKT Ciphers" in the

Reviewer comments:
EKTMsgLength All EKT message other that ShortEKTField must have a length as second from the last element. This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type.

Revised text:
Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity.  <ins> All EKT message other that ShortEKTField have a length as second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type. </ins> The last byte is used to indicate the type of the EKTField.  This MUST be 2 in the FullEKTField format and 0 in ShortEKTField values over odd ones until the even code points are consumed to avoid conflicts with pre standard versions of EKT that have been deployed. <ins> All new EKT messages MUST be defined to have a length as second from the last element. </ins> 5.2. IANA is requested to create a new table for "EKT Ciphers" in the
Original text:
2.2.2. <del> When receiving a packet on a RTP stream where EKT was negotiated, the following steps are applied for each received packet. </del>  The final byte is checked to determine which EKT format is in use. When an SRTP or SRTCP packet contains a ShortEKTField, the

Reviewer comments:
Inbound Processing When receiving a packet on a RTP stream where EKT was negotiated, the following steps are applied for each received packet.
I don't think you can ever receive non EKT packets on a flow with EKT negotiated. That is to say know from the SDP when you get a SRTP packet if it is EKT or not
Use of EKT must be negotiated in signalling on a per session basis. In the case of PERC, all multiplexed flows must use EKT. For WebRTC, that should also be true, unless a determination can be made based on the payload type. That actually raises a question. How are PERC endpoints supposed to construct the SDP for PERC that indicates use of DTLS? Is that going to be in Adam's draft? PERC endpoints are always required to initiate the DTLS association.
Framework and Signaling draft should sum up the usage of this.
More reason to delay framework until we know we've covered everything.
Framework is not getting published anytime soon . We have time :)

Revised text:
2.2.2.  <ins> When receiving a packet on a RTP stream, the following steps are applied for each received packet. </ins> The final byte is checked to determine which EKT format is in use. When an SRTP or SRTCP packet contains a ShortEKTField, the
Original text:
2.3. EKT uses an authenticated cipher to encrypt and authenticate the <del> EKTPlaintext.  We first specify the interface to the cipher, in order to abstract the interface away from the details of that function.  We then define the cipher that is used in EKT by default.  The default cipher described in DefaultCipher MUST be implemented, but another cipher that conforms to this interface MAY be used, in which case its use MUST be coordinated by external means (e.g., key management). </del>  An EKTCipher consists of an encryption function and a decryption function.  The encryption function E(K, P) takes the following

Reviewer comments:
Section 2.3 Ciphers EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. We first specify the interface to the cipher, in order to abstract the interface away from the details of that function. We then define the cipher that is used in EKT by default. The default cipher described in Section 2.3.1 MUST be implemented, but another cipher that conforms to this interface MAY be used, in which case its use MUST be coordinated by external means (e.g., key management).
Fixed by

Revised text:
2.3. EKT uses an authenticated cipher to encrypt and authenticate the  <ins> EKTPlaintext.  This specification defines the interface to the cipher, in order to abstract the interface away from the details of that function.  This specification also defines the default cipher that is used in EKT.  The default cipher described in DefaultCipher MUST be implemented, but another cipher that conforms to this interface MAY be used. </ins> An EKTCipher consists of an encryption function and a decryption function.  The encryption function E(K, P) takes the following
Original text:
longer than needed by SRTP, then it is truncated by taking the first N bytes from the srtp_master_salt field.  The SRTP Master Key, ROC, and SRTP Master Salt from the previous step are saved in a map indexed by the SSRC found in the EKTPlaintext and can be used for any future crypto operations on

Reviewer comments:
This is a very substantial change. I suspect it is correct but given text in security section but think carefully about if this breaks anything.
Section 4 The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another SRTP stream.
I think this is right.

Revised text:
longer than needed by SRTP, then it is truncated by taking the first N bytes from the srtp_master_salt field. <ins> If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet, then all the information from this EKTPlaintext MUST be discarded and the following steps in this list are not done. </ins> The SRTP Master Key, ROC, and SRTP Master Salt from the previous step are saved in a map indexed by the SSRC found in the EKTPlaintext and can be used for any future crypto operations on
Original text:
and SRTCP traffic. Either the FullEKTField or ShortEKTField is appended at the tail end <del> of all SRTP packets. </del>  2.2.1.

Reviewer comments:
There is slight mention of i frames but they get called "intra coded video frames"
Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets.
Pointing to the section looks good This is ok. I reviewed the timing section briefly, but didn't see mention of I-frame or key frame packets. That's another good time to provide the full EKT field.

Revised text:
and SRTCP traffic. Either the FullEKTField or ShortEKTField is appended at the tail end  <ins> of all SRTP packets.  The decision on which to send is specified in timing. </ins> 2.2.1.
Original text:
[!@RFC5246].  This section provides an example of what the bits on the wire would look like for the <del> message that advertises support for both SRTP_AEAD_AES_128_GCM and SRTP_AEAD_AES_256_GCM RFC7714. </del>  Thus, the encoding on the wire presented here in network bytes order would be this stream of octets:

Reviewer comments:
This is a rebased version of from last October.
You want the MDD to be told "use DOUBLEAEADAES128GCMAEADAES128GCM", when it will actually only do have of it?
Another question: can we change the words "if IANA assigned" to something concrete? That is, we just make this assumption. Then, insert a note to RFC Editor to adjust these values as necessary before publication?
On MDD told to do double ... The TLS has to negotiate double or the endpoints will not do double. The endpoints can only do what is negotiated inside of TLS. Keep in mind our desing goal here is to minimize the code changes outside libsrtp to the endpoints and not worry too much about the amount of code on MDD and KDD. On IANA - yah fine with changing this to an RFC editor note to change values to whatever IANA assigned. I think we are at the point where we could have the chairs ask IANA for an early assignment to help pre standard implementations write code.

Revised text:
[!@RFC5246].  This section provides an example of what the bits on the wire would look like for the  <ins> message that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM I-D.ietf-perc-double. RFC Editor Note: Please replace the values 0009 and 000A in the following two examples with whatever code points IANA assigned for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. </ins> Thus, the encoding on the wire presented here in network bytes order would be this stream of octets:
Original text:
cryptographic context and then encrypts using the outer cryptographic context.  The processes is as follows:  5.2. The Media Distributor does not have a notion of outer or inner

Reviewer comments:
You can't think of this as SRTP tunneled inside of SRTP. It's not. It is SRTP done once with a crypto transform called "double" and with a single key. Double has the weird property that if you know half the key, it ends up only decrypting half the the data for you. The endpoints know the full key, the MDD only half the key, and the both the endpoints and the MMD have to do double.
Make sure specs are clear on this
wondering where size ends up
Which size?
That aligns with what you said you preferred. It's certainly easier to explain in words here. But, it will be more challenging for MDDs to explain. Since we are using the same cipher and the ciphertext will have a constant size, we can do in-place authenticated encryption and not destroy the EKT field in the process. So performance will not be affected on the middle box. But, we need to explain this somewhere for the media distributor. Maybe the right place to explain that is when we also show an example of the packet format. I can see that expanding to be processing rules for endpoints and the media distributor.

Revised text:
cryptographic context and then encrypts using the outer cryptographic context.  The processes is as follows: <ins> When using EKT I-D.ietf-perc-srtp-ekt-diet, the EKT Field comes after the SRTP packet exactly like using EKT with any other SRTP transform. </ins> 5.2. The Media Distributor does not have a notion of outer or inner
Original text:
"unexpected_version"  Note: sometimes packets are dropped before they can be associated with a particular connection (e.g., in case of "unsupported_version").  This situation is discussed in handling-

Reviewer comments:
There are two conditions an Initial packet has to fulfill: It's DCID must be >= 8 bytes long. The size of the datagram must be >= 1200. None of the other triggers for the event seem appropriate for this.

Revised text:
"unexpected_version" <ins> "invalid_initial" </ins> Note: sometimes packets are dropped before they can be associated with a particular connection (e.g., in case of "unsupported_version").  This situation is discussed in handling-
Original text:
<del> HTTP/3 and QPACK event definitions for qlog </del>  draft-ietf-quic-qlog-h3-events-latest Abstract

Reviewer comments:
Fixes part of . The changes are tedious but also not too onerous. The main issue you have is that there's lots of comments here and there that break length limits. So I've just picked a line length that will appease xml2rfc. The changes you have in mind might have obviated the errors anyway. But if not, these changes will set a strong foundation to know how to shut xml2rfc up.
According to the official IETF draft guidelines, line length should not be longer than 72 ASCII characters (URL, and URL). For some reason, I had previously understood this to be 82 characters, and so the current texts are 10 characters too wide... Since this will be somewhat of a tedious process (which can be done largely automatically but with manual checks) which will impact allmost all parts of the documents, I propose we do this in a single burst somewhere down the line. cc NAME
Chatted a bit with rmarx offline. The errors that xml2rfc moans about are about artwork, not body text etc. Over the 3 PRs I created, there might look like a lot of churn but it is all constrained to the artwork pieces. In my opinion, it's better to fix these now (or nullify the json validation errors) so that we don't start ignoring things that exist or get newly introduced.
This should be fixed as of main-schema-02 and h3/quic-events-01. For future reference: hard limit of 72 is only needed inside "figures" (including code blocks!). Running text paragraphs/lists/etc. can be done by the tooling itself.

Revised text:
 <ins> HTTP/3 and QPACK qlog event definitions </ins> draft-ietf-quic-qlog-h3-events-latest Abstract
Original text:
This document describes the values of the qlog name ("category" + "event") and "data" fields and their semantics for the QUIC protocol. <del> This document is based on draft-34 of the QUIC I-Ds QUIC-RECOVERY QUIC-TLS.  HTTP/3 and QPACK events are defined in a separate document QLOG-H3. </del>  Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that

Reviewer comments:
quic: fix artwork line length quic: stick commas between refs to unfool xml2rfc Fixes part of URL The changes are tedious but also not too onerous. The main issue you have is that there's lots of comments here and there that break length limits. So I've just picked a line length that will appease xml2rfc. The changes you have in mind might have obviated the errors anyway. But if not, these changes will set a strong foundation to know how to shut xml2rfc up.
According to the official IETF draft guidelines, line length should not be longer than 72 ASCII characters (URL, and URL). For some reason, I had previously understood this to be 82 characters, and so the current texts are 10 characters too wide... Since this will be somewhat of a tedious process (which can be done largely automatically but with manual checks) which will impact allmost all parts of the documents, I propose we do this in a single burst somewhere down the line. cc NAME
Chatted a bit with rmarx offline. The errors that xml2rfc moans about are about artwork, not body text etc. Over the 3 PRs I created, there might look like a lot of churn but it is all constrained to the artwork pieces. In my opinion, it's better to fix these now (or nullify the json validation errors) so that we don't start ignoring things that exist or get newly introduced.
This should be fixed as of main-schema-02 and h3/quic-events-01. For future reference: hard limit of 72 is only needed inside "figures" (including code blocks!). Running text paragraphs/lists/etc. can be done by the tooling itself.

Revised text:
This document describes the values of the qlog name ("category" + "event") and "data" fields and their semantics for the QUIC protocol.  <ins> This document is based on draft-34 of the QUIC I-Ds QUIC-TRANSPORT, QUIC-RECOVERY, and QUIC-TLS.  HTTP/3 and QPACK events are defined in a separate document QLOG-H3. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that