jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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:
Change:
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

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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
Change:
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 :)

Discussion:
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> <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
Change:
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

Discussion:
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> <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
Change:
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.

Discussion:
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
Change:
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.

Discussion:
and SRTCP traffic. Either the FullEKTField or ShortEKTField is appended at the tail end <del> of all SRTP packets. </del> <ins> of all SRTP packets.  The decision on which to send is specified in timing. </ins> 2.2.1.
Change:
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.

Discussion:
[!@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> <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:
Change:
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.

Discussion:
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
Change:
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.

Discussion:
"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-
Change:
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.

Discussion:
<del> HTTP/3 and QPACK event definitions for qlog </del> <ins> HTTP/3 and QPACK qlog event definitions </ins> draft-ietf-quic-qlog-h3-events-latest Abstract
Change:
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.

Discussion:
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> <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
Change:
While DPLPMTUD is optional, there's an about it in QUIC transport. Minimal support for this in qlog would define an event for every increase of the MTU: I don't think we need a separate event for the sending of an MTU probe packet, but we should probably standardize a for this. Suggestion: . Open question: Do we want a separate failure event? Failure would be either the loss of an MTU probe packet, or (for implementations that pay attention to ICMP packets) the receipt of an ICMP Packet Too Big (PTB) message.
I agree it would be useful to have this information in qlog. In terms of design, as always there are several options: 1) have separate events for this (, , , etc.) 2) integrate them into existing events( triggers on and , new field in ) 3) a combination of these approaches (which is what you suggest IIUC) This is imo a good example of where we need clear design guidelines on how to add new information/events to qlog.
Revisiting this after a long time: is problematic, as this would essentially be a copy of the normal event (it is allowed, although not recommended, to just send normal application data as a probe packet). The trigger seems to be the best solution here needs to be a separate event, there's just no way we can reasonably collapse this into an acknowledgment event is what I'm still undecided about. This logically belongs to the regular event, we'd just need a way to attach "oh and by the way, this was a MTU probe packet". In fact, it would be really useful to have it on that event, since the congestion control implications are very different for lost MTU packets (i.e., you wouldn't decrease your cwnd).
I have to disagree with myself here. The sending of the packet might have been triggered by something else, it's just that the stack decided to send a probe packet. I suggest: Add a optional on the and events. Add a event.
Supporting DPLPMTUTD events seems important to cover in the base specs.

Discussion:
Definition: <ins> 3.5. Importance: Extra This event indicates that the estimated Path MTU was updated.  This happens as part of the Path MTU discovery process. </ins> 4. TBD
Change:
There's too much text here that doesn't aid the reader. Delete it to be clear that we're using JSON as the notational convention for examples. If this text was valuable, it should be somewhere else.
I still feel we should have a "forward reference" here, indicating that we also discuss I-JSON and Streaming JSON considerations in this document, rather than making it seem we only do "pure JSON" due to the examples. Put differently, something like this should still be mentioned in this location imo:
But the fact it can be serialized to I-JSON has nothing to do with notational conventions used in this document, because we don't use any I-JSON.
NAME I just pushed a commit with a proposal to split up the original text to keep only a minimal amount in "Notational Conventions" but keep the core message alive in the introduction (which seemed the most logical location for now). I added the "unless otherwise indicated", as there are some examples of JSON-SEQ near the end of the document that obviously don't use RFC8259 notation directly. Please review and if approved, merge :)

Discussion:
inclusion, log aggregation, event grouping and log file size reduction techniques. <ins> The qlog schema can be serialized in many ways (e.g., JSON, CBOR, protobuf, etc).  This document describes only how to employ JSON, its subset I-JSON, and its streamable derivative JSON-Text-Sequences. </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 URL for an up-to-date version of this document.

have a string key that maps to any value.  Used to indicate a generic JSON object. <ins> All timestamps and time-related values (e.g., offsets) in qlog are logged as "float64" in the millisecond resolution. Other qlog documents can define their own CDDL-compatible (struct) types (e.g., separately for each Packet type that a protocol supports). </ins> 1.1.2. <del> While the qlog schemas are format-agnostic, and can be serialized in many ways (e.g., JSON, CBOR, protobuf, ...), this document only describes how to employ JSON, its subset I-JSON, and its streamable derivative JSON-Text-Sequences as textual serialization options.  As such, examples are provided in JSON.  Other documents may describe how to utilize other concrete serialization options, though tips and requirements for these are also listed in this document (concrete- formats). </del> <ins> Serialization examples in this document use JSON (JSON) unless otherwise indicated. </ins> 2.
Change:
Updates as that had some problems: used instead of for CDDL type in some of the definitions (not in others)... Made a separate category for the event. It's debatable imo whether it belongs in or , but it shouldn't be its own thing. In general, I feel was approved/merged too soon and this type of things should be checked for future PRs of a similar type.
Changes look good to me. First of all, sorry for messing up the type name. I'm not sure I agree that it was merge too soon though, was open for 3 months, and was approved by one of the editors. Sometimes it's better to make progress instead of not moving at all, even if some cleanup is necessary later.
NAME no problem, I mess up way worse than that :) Let me rephrase that to just "approved" too soon then, instead of "merged" too soon (which is again perfectly understandable with Lucas not used to watching for that type of issue, just wanted to indicate future approvals should).
From the discussion in , it seems better to keep this consistent with other events. Also noticed I forgot to prefix the event with Connectivity and add it to the CDDL list on the bottom...
Sorry if that's a stupid question, but why do we have an and a field here? I thought you can only set it once. Originally posted by NAME in URL
This is a fair question. This is most likely a copy-paste from one of the events (can't find evidence that this was once called StreamTypeUpdated though...) For updates this makes sense, but if the StreamType is only ever set once after becoming known, it would be better to change the definition to e.g., (note, is from ) :

Discussion:
For now, infer from other connectivity events and path_challenge/ path_response frames <ins> 3.1.9. Importance: Extra This event indicates that the estimated Path MTU was updated.  This happens as part of the Path MTU discovery process. </ins> 3.2. 3.2.1.

Definition: <del> 3.5. Importance: Extra This event indicates that the estimated Path MTU was updated.  This happens as part of the Path MTU discovery process. </del> 4. TBD
Change:
In the main schema document, there's a a chunk of text that says: The danger with restating things like this is that there is some subtle problem or incompatibility with the canonical CDDL source citation. I appreciate the QUIC WG might not be familiar with this syntax, so it's handy. But the long-term problems a more insidious. Consider replacing it with deep links to CDDL syntax, or sticking it behind a note that it will be removed prior to publication.
Yes, the intent is to remove this prior to publication. It's just there to make early adoption easier for now. Will look up how to properly add such a note (not sure if there's something default in the kramdown for that) and add it.

Discussion:
Additionally, this document defines the following custom types for clarity: <ins> All timestamps and time-related values (e.g., offsets) in qlog are logged as "float64" in the millisecond resolution. Other qlog documents can define their own CDDL-compatible (struct) types (e.g., separately for each Packet type that a protocol supports). </ins> The main general CDDL syntax conventions in this document a reader should be aware of for easy reading comprehension are:

have a string key that maps to any value.  Used to indicate a generic JSON object. <del> All timestamps and time-related values (e.g., offsets) in qlog are logged as "float64" in the millisecond resolution. Other qlog documents can define their own CDDL-compatible (struct) types (e.g., separately for each Packet type that a protocol supports). </del> 1.1.2. While the qlog schemas are format-agnostic, and can be serialized in