jiebi/CodeConvo huggingface dataset:
Change:
A list of the identities (labels for keys) that the client is <del> willing to negotiate with the server. </del> <ins> willing to negotiate with the server.  If sent alongside the "early_data" extension (see early-data-indication), the first identity is the one used for 0-RTT data. </ins> The server's chosen identity expressed as a (0-based) index into

Discussion:
I would actually much rather we only offer one PSK identity since TLS 1.2 was perfectly fine offering just one and resumption has no use for offering multiple, but I suspect I will lose that fight. Absent that, at least make the protocol well-defined. Unlike both TLS 1.2 resumption and TLS 1.2 PSK, TLS 1.3 increases the state space and allows clients to offer multiple PSK identities. This mostly works, but 0-RTT presumes that only one is offered. Define 0-RTT to presume the first identity is selected and clarify that other shapes are possible due to the increased state space.
Change:
Indicates that x is A bits long Indicates that x holds an integer value using the variable-length <del> encoding in </del> <ins> encoding described in </ins> Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del> <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x has a fixed value of C with the length described by L, which can use any of the three length forms above </del> <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins> Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above <del> Indicates that x is optional (and has length of L) </del> <ins> Indicates that x is optional and has a length of L </ins> <del> Indicates that zero or more instances of x are present (and that each instance is length L) </del> <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
Indicates that x is A bits long Indicates that x holds an integer value using the variable-length <del> encoding in </del> <ins> encoding described in </ins> Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del> <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x has a fixed value of C with the length described by L, which can use any of the three length forms above </del> <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins> Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above <del> Indicates that x is optional (and has length of L) </del> <ins> Indicates that x is optional and has a length of L </ins> <del> Indicates that zero or more instances of x are present (and that each instance is length L) </del> <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.

Discussion:
These were not the same, even for the same items, so I fixed that. Checked with: Which shows the three items that are only present in -transport (-invariants doesn't use these).
Change:
This byte string may represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this <del> extension was used.  For the Curve25519 and Curve448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or </del> <ins> extension was used.  For the X25519 and X448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or </ins> 56-octet representation of the u value of the point.  This structure MUST NOT be used with Ed25519 and Ed448 public keys.

Discussion:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec
Change:
it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the <del> application). </del> <ins> application).  Implementations that use packet pacing SHOULD support delaying the transmission of DATAGRAM frames for at least the time it takes to send the paced packets allowed by the congestion controller to avoid dropping frames excessively. </ins> Implementations can optionally support allowing the application to specify a sending expiration time, beyond which a congestion-

Discussion:
Warn against the pathological case of dropping packets due to pacing.
Early in our VPN implementation, we sent QUIC datagrams without any queueing, assuming that if a datagram gets dropped, then we exceeded the cwnd (and thus the estimated channel capacity), so it would likely not reach the peer anyways. In practice, this turned out to be a terrible idea that lead to underutilization of the channel; our implementation always does pacing, so if you don't queue the datagram, it will get dropped unless it just happens to fit into the current pacing quantum. Because pacing is RECOMMENDED for QUIC, I believe some form of queueing should be RECOMMENDED for datagrams, otherwise the users risk running into the same hard-to-debug problem that we had.
I think adding a note about pacing to the "Congestion Control" subsection makes sense to me.
+1, if you're in the bucket of implementations that have insight into their pacing algorithm, it should be reasonable to expect that you'd avoid dropping your own datagrams unless you make a queue and then build up too much in that queue.
Thanks!
Change:
lost or when the limit is updated, with care taken to prevent the frame from being sent too often.  An endpoint SHOULD stop sending MAX_STREAM_DATA frames when the receiving part of the stream <del> enters a "Size Known" state. </del> <ins> enters a "Size Known" or "Reset Recvd" state. </ins> The limit on streams of a given type is sent in MAX_STREAMS frames.  Like MAX_DATA, an updated value is sent when a packet

Discussion:
This should address all of them at once; one per commit for those that I think need action. This is probably OK: This is not expressly forbidden. We do say : Which doesn't really contradict the other. FWIW, I'm not a fan of allowing frames to be copied, implementations really should do that, but it's a consequence of having frame idempotency. This is one I'm not sure about: What is the prevailing advice regarding MTU and tunnels? Clearly when you tunnel you get a smaller MTU, but I haven't seen what happens when IPv6 is tunneled over a network that has a minimum MTU. Most paths don't have that small an MTU, so it might be that things just fail.
I realized that there are some answers here in the description, but probably best to move them to the relevant issues anyways.
NAME said: >
NAME said: with TLS.
NAME said:
NAME said: this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be copied.
My recommendation is to answer the question, but not change anything. See for an answer.
Very well, please close this issue. Sorry for the confusion.
NAME said: RESET_RECVD.
NAME said:
NAME said:
This looks good to me, with NAME 's nit.
Change:
IP packets in HTTP Datagrams (packet-handling). Any 2xx (Successful) response indicates that the proxy is willing to <del> open an IP forwarding path between it and the client.  Any response </del> <ins> open an IP forwarding tunnel between it and the client.  Any response </ins> other than a successful response indicates that the tunnel has not been formed.

Discussion:
The draft currently mentions an "IP forwarding path" (or elsewhere a "path for proxying IP packets") without defining what that term means. It's ambiguous because "path" is a . I'd propose we replace this use of the word "path" with the word "tunnel" which is .
Yes, "IP forwarding tunnel" sounds fine to me.
Yes tunnel is good. Or maybe association in the context of handling state st the proxy.
Change:
the subdomain's name ends with the containing domain's name." (Quoted from RFC1034, Section 3.1).  For example, in the host name "nnn.mmm.example.com", both "mmm.example.com" and <del> "nnn.mmm.example.com" are subdomains of "example.com". </del> <ins> "nnn.mmm.example.com" are subdomains of "example.com".  Note that the comparisons here are done on whole labels; that is, "ooo.example.com" is not a subdomain of "oo.example.com". </ins> The owner of a CNAME resource record, or a subdomain of the owner of a DNAME resource record (DNAME records are defined in RFC6672).

Discussion:
"each other" is clearer in English. I agree that "whole labels" is better and have changed the text.
At line 139, "each other" may be "others" ? At line 358, "full labels" may be "whole labels" or "each label".
Change:
concatenated as described in basic-block-size and are also unsigned. The following numeric types are predefined. <del> All values, here and elsewhere in the specification, are stored in network byte (big-endian) order; the uint32 represented by the hex </del> <ins> All values, here and elsewhere in the specification, are transmitted in network byte (big-endian) order; the uint32 represented by the hex </ins> bytes 01 02 03 04 is equivalent to the decimal value 16909060. 3.5.

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
An in-network observer assuming that a set of packets belongs to a QUIC flow might infer the version number in use by observing the <del> handshake: for QUIC version 1, if the version number in the Initial packet from a client is the same as the version number in the Initial packet of the server response, that version has been accepted by both endpoints to be used for the rest of the connection. </del> <ins> handshake.  If the version number in an Initial packet of the server response is subsequently seen in a packet from the client, that version has been accepted by both endpoints to be used for the rest of the connection (see Section 2 of I-D.ietf-quic-version- negotiation). </ins> The negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection

Discussion:
From review by NAME
it’s worth noting that compatible version negotiation can cause the version to change mid-handshake. The true signal is a server-chosen version field echoed in a client packet.
Should this reference the compatible version negotiation piece of QUIC-VN?
Change:
although there may be more RtpTransceivers than m= sections when RtpTransceivers are created but not yet associated with a m= section, or if RtpTransceivers have been stopped and disassociated from m= <del> sections.  An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. </del> <ins> sections.  An RtpTransceiver is said to be associated with an m= section if its mid property is non-null; otherwise it is said to be disassociated.  The associated m= section is determined using a mapping between transceivers and m= section indices, formed when creating an offer or applying a remote offer.  An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds

Discussion:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM
Change:
9. <del> DNS over HTTPS relies on the underlying HTTPS connection to provide confidentiality.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for confidential transport. </del> <ins> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with

Discussion:
Reverts dohwg/draft-ietf-doh-dns-over-https
Change:
algorithms.  server-certificate and server-key-share describe the appropriate rules. <del> All clients MUST send a valid "signature_algorithms" extension in their ClientHello when offering certificate authenticated cipher suites.  Servers receiving a TLS 1.3 ClientHello offering certificate authenticated cipher suites without this extension MUST send a "missing_extension" alert message and close the connection. Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension. </del> Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not contain this extension.  If those servers are willing to negotiate TLS 1.2, they MUST behave in accordance with the requirements of

Discussion:
Modified extension requirements based on recent list discussion. It's a little verbose with repeated boilerplate, but it's clear no matter which section you read now. I've also moved the relevant requirements up top to a consistent place for each extension's section. The level of strictness here is now: If attempting to negotiate and the mandatory extension isn't available: MUST error If just detecting an invalid combination, but not actively negotiating: MAY error SNI is clearly listed as MUST support, servers MAY require, and SHOULD error if required The "unsupportedextension" alert is reworded more generally and put in as the consequence for violating the pre-existing "MUST NOT" send the client-only extensions from a server requirements. Also added some more, namely the fact that "clientkey_share" is clearly an error to be sent from a server.
NAME & NAME Please take a look when you get a chance. Are we all on the same page with this language? Anything that needs tweaking to focus on the above better? Edited to add: Also, do I need to cut out SNI again, or is this wording ok? It's not requiring it to be sent, just noting it must be supported, which was agreed to on list a while ago, and noting the existing case that servers MAY require it with a way to indicate it using the new error alert.
NAME New commit pushed here with changes for your comments: "invalid" -> "prohibited" Text is now: "Servers MUST NOT negotiate use of cipher suites unless the client supplies a supported . If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert." So, trying to find a viable cipher suite is preferred and the error is only required when there's nothing else to do. Edited to note: The latter doesn't contradict the mandatory error on negotiation without the needed extension, as the server simply has the (unlikely) chance of negotiating something completely different instead. The MAY error is still included later in the changeset, as discussed, so clients are still expected to always do this correctly or risk the server throwing an error.
NAME Ok, repushed with one-word change to clarify to "at least one group for each ephemeral key exchange algorithm". This excludes PSK, but is still fine for (EC)DHE when used with it. Seems like the simplest fix.
Change:
S SERVFAIL <ins> SOA </ins> SOA field names Secondary server Secure Entry Point (SEP)

Discussion:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.
Change:
The "Deprecation" response header field describes the deprecation of the resource identified with the response it occurred within (see <del> Section 3.1.4.1 of HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </del> <ins> HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </ins> Servers MUST NOT include more than one "Deprecation" header field in the same response.

Discussion:
This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.
Change:
Data transport: such as TCP, UDP and the means to securely set up connections between entities, as well as the functions for <del> deciding when to send data: Congestion management, bandwidth </del> <ins> deciding when to send data: congestion management, bandwidth </ins> estimation and so on. <del> Data framing: RTP, SCTP and other data formats that serve as containers, and their functions for data confidentiality and </del> <ins> Data framing: RTP, SCTP, DTLS, and other data formats that serve as containers, and their functions for data confidentiality and </ins> integrity. Data formats: Codec specifications, format specifications and

Discussion:
ekr had the following comment: You should probably list DTLS, SCTP, and SDP in this section. It's not like we haven't decided we need them.
LGTM with nits
Change:
In both cases, the new members need information to bootstrap their local group state. <ins> The "group_context" field represents the current state of the group. The "extensions" field allows the sender to provide additional data that might be useful to new joiners.  The "confirmation_tag" represents the confirmation tag from the Commit that initiated the current epoch, or for epoch 0, the confirmation tag computed in the creation of the group (see group-creation).  (In either case, the creator of a GroupInfo may recompute the confirmation tag as "MAC(confirmation_key, confirmed_transcript_hash)".) </ins> New members MUST verify that "group_id" is unique among the groups they're currently participating in.

Discussion:
This PR is an alternative to . This PR updates the group creation process so that epoch 0 is a "full-fledged" epoch, with an epoch secret (and all the derivatives) instead of just an init secret. One implication of that is that the interim transcript hash can now be computed in the usual way, by extending the confirmed transcript hash with a confirmation tag: This has the nice side effect of immediately mixing the epoch secret into the transcript hash, helping the group diverge (a concern NAME raised on the call today). While I was editing the group creation section, I also rationalized the requirements a bit. One reason that came up is that the group creation section currently assumes you're always starting with multiple members. So the MUST-level requirement to fetch key packages has been downgraded to a SHOULD. Finally, I updated the specification of GroupInfo to explain the fields, in particular explaining how you get the confirmation tag in epoch 0 or later epochs.
Since this PR clarifies more than and the solution is equally good, I'd suggest closing and merging this one.
Change:
and/or pending remote description according to the rules defined for Trickle ICE.  Connectivity checks will be sent to the new candidate. <ins> This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for all media descriptions in the last remote description. </ins> This call will result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity being established.

Discussion:
Specifically, "addIceCandidate" and "Applying a Remote Description".
I'm fine this however it ends up. I will r+ this and people can merge it once it is done. Thanks
Just adding a still LGTM
lgtm once my comment from today is addressed
Change:
Sending different payloads each time reduces the chances of spurious retransmission. <del> 5.3.2. </del> <ins> 5.2.4. </ins> Delivery or loss of packets in flight is established when an ACK frame is received that newly acknowledges one or more packets.

Discussion:
I believe this section was mistakenly on the wrong level. I also added a reference to a later section to the last sentence. Alternatively this sentence could just be removed as this is normatively specified later on.