jiebi/CodeConvo huggingface dataset:
Change:
A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any <del> value smaller than the "min_ack_delay" advertised by this endpoint is invalid.  Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> value larger than 16,383,000 microseconds is invalid, as specified for the "max_ack_delay" transport parameter.  Any value smaller than the "min_ack_delay" advertised by this endpoint is invalid. Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01

Discussion:
Does it make sense to specify any maximum values for any of the ACK frequency frame fields, such as for Packet Tolerance? Does a value of 4 billion make sense? Can I use a in my implementation to store this locally? Is there any expectation around the sizes of these fields? If there is no explicit max, what if I implicitly apply one? I'm working on implementing this and I'm trying to figure out how small (byte size) I can make the variables I use to store the values on the connection.
Update Max Ack Delay will be limited by the Max Ack Delay limit once lands. That leaves Packet Tolerance, which I agree is reasonable to limit to a value smaller than 2^62-1 locally. We could add a comment like "Implementations that have a lower limit than 2^62-1 on the Packet Tolerance MUST set treat it as though the maximum supported Packet Tolerance value has been received."
Slight tweak: "If an endpoint receives a Packet Tolerance value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable maximum value instead."
If I understand correctly, the maximum value of the transport parameter is supposed to ensure that the value is smaller or equal than the transport parameter. According to the maximum value of is . However, the maximum value of is .
We're going to remove the 2^24 - 1 limit and just rely on the MUST that minackdelay can't be greater than maxackdelay, which implies the 2^14-1 limit.
QUIC Transport specifies a maximum value of 2^14 ms (roughly 16s) for the transport parameter. Does this limit apply to values sent in the field of the ACK_FREQUENCY frame, or is any value up to 2^62 microseconds allowed here? Either way, the draft might benefit from clarifying the rules here.
The editors do not have a strong opinion, and we currently say nothing about the limit being changed by this extension, so we're inclined to keep the limit as is and add some text clarifying that the extension doesn't change the limit. We're open to arguments otherwise if people have them.
Change:
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

Discussion:
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.
Change:
Retry tokens generated by the service MUST have the format below. <del> The first bit of retry tokens generated by the service must be zero. </del> <ins> The first bit of retry tokens generated by the service MUST be zero. </ins> The token has the following additional fields: ODCIL: The length of the original destination connection ID from the

Discussion:
Fixes URL
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni
Change:
or not ECH was accepted and proceeds with the handshake accordingly. (See client-behavior for details.) <ins> Informally, a primary goal of ECH is ensuring that connections to servers in the same anonymity set are indistinguishable from one another without affecting any existing security properties of TLS 1.3.  See goals for more details about the ECH security and privacy goals. </ins> 4. ECH uses HPKE for public key encryption I-D.irtf-cfrg-hpke.  The ECH

Discussion:
cc NAME
In just a few sentences, let's define the anonymity set and say what it means for connections to end points in this set to be indistignuishable. We might also enumerate non-goals (though we still need consensus on what these are).
I've not yet gotten around to the PR yet, but here's the gist: Attackers: Passive attackers are those which cannot probe, e.g., buggy middleboxes that filter based on plaintext packet contents. Active attackers can probe, e.g., censors. Goals: ECH does not negatively affect any existing security properties of TLS 1.3. ECH connections to servers in the same anonymity set are indistinguishable from one another for passive and active attackers, modulo traffic analysis. (Note: an anonymity set is determined by the client and server parameters, e.g., the SNI, supported application protocols, and so on.) ECH support is secret from passive attackers who don't know the ECH configuration, but not active attackers. ECH usage is secret from passive attackers who don't know the ECH configuration, but not active attackers. More specifically: Passive attackers with a known ECH configuration can distinguish between a connection that negotiates ECH with that configuration and one which does not (GREASEd or using a different configuration). Passive attackers without the ECH configuration cannot distinguish between a connection that negotiates ECH and one which does not (but GREASEd). Active attackers can distinguish between a connection that negotiates ECH and one which does not (but GREASEd).
Yeah this looks good.
From the interim: merge this as a PR and then address censorship separately (if desired).
Change:
6. Unlike RTP, which is encrypted both hop-by-hop and end-to-end using <del> two separate cryptographic key, RTCP is encrypted using only the </del> <ins> two separate cryptographic keys, RTCP is encrypted using only the </ins> outer (hop-by-hop) cryptographic key.  The procedures for RTCP encryption are specified in RFC3711 and this document introduces no additional steps.

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be <del> in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </del> <ins> in flight or responses outstanding when the sender decides to send a Release message.  The peer responding to the Release message SHOULD delay the closing of the connection until it has responded to all requests received by it before the Release message.  It also MAY wait for the responses to its own requests. </ins> Release messages are indicated by the 7.04 code (Release).

Discussion:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)
Change:
2.1. TLS provides two endpoints with a way to establish a means of <del> communication over an untrusted medium (that is, the Internet) that ensures that messages they exchange cannot be observed, modified, or forged. </del> <ins> communication over an untrusted medium (that is, the Internet).  TLS enables authentication of peers and provides confidentiality and integrity protection for messages that endpoints exchange. </ins> Internally, TLS is a layered protocol, with the structure shown in tls-layers.

Discussion:
These are all small, but neat improvements inspired by the feedback in .
Here are some minor editorial issues: Section 2.1: "TLS provides two endpoints with a way to establish a means of communication over an untrusted medium (that is, the Internet) that ensures that messages they exchange cannot be observed, modified, or forged." I think "observed" as used here is the wrong word. Because the encrypted form of the clear-text message will be possible to observe. Please reformulate to give actual security properties. Section 2.1: "A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately. This Application Data can be replayed by an attacker so it MUST NOT carry a self-contained trigger for any non-idempotent action." Please do not use RFC2119 words "MUST NOT" in overview. I understand the need for emphasis on this. However, I assume this is actually specified normatively elsewhere. So simply using other words to provide the emphasis and possibly a reference to the section defining this normatively. Section 5.2: "Note: The Destination Connection ID is of arbitrary length, and it could be zero length if the server sends a Retry packet with a zero-length Source Connection ID field." To my understanding the DCID is not arbitrary length, it is of any octet length between 0 and 160 bits. Does the Initial processing function need to deal with non QUIC version-1 long header packets?
Based on , labeling this as "editorial"
I think the PR resolves my issues nicely.
I liked that we dropped the MUST NOT, it's already somewhere else. I also like that we point back to quic-trans for the dcid URL
Change:
1. <del> QUIC is a new multiplexed and secure transport atop UDP.  QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport.  The QUIC protocol is described in QUIC-TRANSPORT. QUIC implements the spirit of existing TCP congestion control and </del> <ins> QUIC is a new multiplexed and secure transport protocol atop UDP, specified in QUIC-TRANSPORT.  This document describes congestion control and loss recovery for QUIC.  Mechanisms described in this document follow the spirit of existing TCP congestion control and </ins> loss recovery mechanisms, described in RFCs, various Internet-drafts, <del> and also those prevalent in the Linux TCP implementation.  This document describes QUIC congestion control and loss recovery, and where applicable, attributes the TCP equivalent in RFCs, Internet- drafts, academic papers, and/or TCP implementations. </del> <ins> or academic papers, and also those prevalent in TCP implementations. </ins> 2.

Discussion:
Just a proposal but I would prefer to remove the advertising slang ("decades of transport and security experience" and "makes it attractive").
Isn't the introduction the right place for ad copy, though? It describes what the document hopes to achieve and why it's worth doing. I think some of the rewording you've done here is an improvement, but I'm not convinced we should edit out the fact that we're trying to incorporate many years of work that hasn't been universally deployable.
I'm fine with this new language.
Change:
It is important to note that neither the Transport Services API I- D.ietf-taps-interface nor the Implementation document I-D.ietf-taps- impl define new protocols or protocol capabilities that affect what <del> is communicated across the network.  The Transport Services system MUST be deployable on one side only.  A Transport Services system acting as a connection initiator can communicate with any existing system that implements the transport protocol(s) selected by the Transport Services system.  Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system, from existing initiators. </del> <ins> is communicated across the network: this implies that a Transport Services system MUST be deployable on only one side of a connection. A Transport Services system acting as a connection initiator can communicate with any existing system that implements the transport protocol(s) selected by the Transport Services system.  Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system, from existing initiators. </ins> 4.

Discussion:
Note that Security Considerations and Acknowledgments changes are newline-rewrap only.
Change:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement. </del> <ins> acknowledgement.  This limit could be based on the receiver's clock or timer granularity. </ins> An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat

Discussion:
Although I understand what minackdelay represents it's not clear to me what an implementation should do with that value. Is the purpose to make sure that stacks sufficiently wait enough time before triggering PTO? There's no guidance on this in the draft. Perhaps there should be.
represents the minimum time that the receiver can delay for. In the common case, this would be the receiver's clock or timer granularity. This is for the receiver to indicate that the sender cannot reduce below this value. So a receiver implementation can simply use its granularity for this value, and a sender must ensure that its is not below the received . Does this help, NAME We can add some text to clarify this.
Thanks. Yes, I think this should be explained in the draft like you said.
Change:
WT_MAX_DATA frames contain the following field: <del> Maximum Data: A variable-length integer indicating the maximum amount of data that can be sent on the entire connection, in units of bytes. </del> <ins> A variable-length integer indicating the maximum amount of data that can be sent on the entire connection, in units of bytes. </ins> All data sent in WT_STREAM frames counts toward this limit.  The sum of the lengths of Stream Data fields in WT_STREAM frames MUST NOT

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
frames to signal acknowledgement of 1-RTT packets on path number 0, and also 0-RTT packets as specified in handling-of-0-rtt-packets. <del> 1-RTT packets sent to different paths SHOULD carry different connection identifiers, if a non-zero connection ID is used. </del> <ins> An endpoint sending 1-RTT packets MUST use different Connection IDs on different paths, if non-zero-length Connection IDs are used. Still, the receiver may observe the same Connection ID used on different 4-tuples due to, e.g., NAT rebinding.  In such case, the receiver reacts as specified in Section 9.3 of QUIC-TRANSPORT. </ins> 6.1.

Discussion:
There is a SHOULD here, which I believe should be a MUST as we taking about the receiver behaviour here.
NAME NAME is this ready to merge?
Sorry, I am working on several projects in parallel, missed this. Text is fine.
Change:
This specification describes an interoperable regular expression flavor, I-Regexp. <del> This document uses the abbreviation "regexp" for what are usually called regular expressions in programming.  "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". I-Regexp does not provide advanced regexp features such as capture groups, lookahead, or backreferences.  It supports only a Boolean matching capability, i.e., testing whether a given regexp matches a given piece of text. </del> <ins> I-Regexp does not provide advanced regular expression features such as capture groups, lookahead, or backreferences.  It supports only a Boolean matching capability, i.e., testing whether a given regular expression matches a given piece of text. </ins> I-Regexp supports the entire repertoire of Unicode characters. <del> I-Regexp is a subset of XSD regexps XSD-2. </del> <ins> I-Regexp is a subset of XSD regular expressions XSD-2. </ins> <del> This document includes rules for converting I-Regexps for use with several well-known regexp libraries. </del> <ins> This document includes guidance for converting I-Regexps for use with several well-known regular expression idioms. </ins> 1.1. <ins> This document uses the abbreviation "regexp" for what are usually called regular expressions in programming.  "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in

Discussion:
Signed-off-by: Tim Bray Based on our email thread with James, and a couple of minor editorial touch-ups.
LGTM, thanks.
Change:
5.1. <del> IANA is requested to create a new registry for "EKT Messages Types". The initial values in this registry are: </del> <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.

Discussion:
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?
Change:
vulnerable according to the information contained in the vulnerability description information. <del> The task of collecting specific endpoint information from the target endpoint, that is not available from the endpoint management capability, in order to make a determination about that endpoint (vulnerability status, identification, etc.). </del> 3. A number of assumptions must be stated in order to further clarify

Discussion:
We should examine the vulnerability assessment process outlined in the draft and determine the alignment with SACM tasks and update as necessary.
URL
Addressed in URL During yesterday's virtual interim meeting, we discussed various open issues with respect to the Vulnerability Assessment Scenario [1] as a result of feedback that we received on the draft which you can see here [2][3]. The slide's from the meeting can be found here [4]. One issue that we didn't have a chance to discuss because we ran out of time was whether or not an endpoint management capability has the ability to push supplemental endpoint information to the vulnerability assessment capability. This question came out of a review of the following text from the Vulnerability Assessment Scenario (specifically the last sentence). "In many cases, the endpoint information needed to determine an endpoint's vulnerability status will have been previously collected by the Endpoint Management Capability and available in a Repository. However, in other cases, the necessary endpoint information will not be readily available in a Repository and a targeted collection will be necessary. Of course, an implementation of an endpoint management capability may prefer to enable operators to perform targeted collection under certain circumstances, even when sufficient information can be provided by the endpoint management capability (e.g. there may be freshness requirements for information). Targeted collection of endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by the vulnerability assessment capability. Under certain deployment scenarios, once the necessary detection information is known, the information beyond that which is available in the endpoint management capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes." Our main question is whether or not pushing information from the endpoint management capability to the vulnerability assessment capability is actually possible because it would not necessarily know what information it needs to push prior to the server requesting it (in which case it is probably considered a pull)? Is there a situation where the endpoint would know, in advance, what additional information is needed for an assessment without a server requesting it? If you have any thoughts on this issue, please provide feedback by May 31st. We are planning to have an updated version of the scenario for June 8th. Thanks, Danny [1] URL [2] URL [3] URL [4] URL (looks like the slides are not available just yet, but, I suspect they should be soon)
Change:
length of the data. The AEAD output consists of the ciphertext output by the AEAD <del> encryption operation.  The length of the plaintext is one greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type. The length of aead_output will generally be larger than the plaintext, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSPlaintext.length values.  Symbolically, </del> <ins> encryption operation.  The length of the plaintext is greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type and however much padding is supplied by the sender.  The length of aead_output will generally be larger than the plaintext, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The

Discussion:
This is a big improvement over the previous proposed methods, by the way. NAME I suggest filing a followup PR for your comments, as it looks like this has already merged.