jiebi/CodeConvo huggingface dataset:
Change:
8.4. <del> In order to provide forward secrecy and post-compromise security, whenever a member initiates an epoch change (i.e., commits; see commit), they refresh the key pairs of their leaf and of all nodes on their leaf's direct path (all nodes for which they know the secret key). </del> <ins> Whenever a member initiates an epoch change (i.e., commits; see commit), they may need to refresh the key pairs of their leaf and of the nodes on their leaf's direct path in order to maintain forward secrecy and post-compromise security. </ins> The member initiating the epoch change generates the fresh key pairs using the following procedure.  The procedure is designed in a way

Discussion:
In first paragraph, the "Ratchet Tree Evolution" Section states that whenever a member initiates an epoch change, they refresh the key pair in their leaves, etc. This is not the case for partial commits, where the epoch is advanced without a key update and without achieving PCS.
Change:
4. <del> The client SHOULD retrieve server key commitments prior to both an </del> <ins> The Client SHOULD retrieve Server key commitments prior to both an </ins> issuance and redemption to verify the consistency of the keys and to monitor for key rotation between issuance and redemption events.

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()
Change:
The "max_fragment_length" extension is also ill-suited to cases where the capabilities of client and server are asymmetric.  Constraints on <del> record size are often receiver constraints.  In particular, an Authentication Encryption with Additional Data (AEAD) ciphers (see RFC5116) API requires that an entire record be present to decrypt and authenticate it.  Some implementations choose not to implement an AEAD interface in this way to avoid this problem, but that exposes them to risks that an AEAD is intended to protect against. </del> <ins> record size are often receiver constraints. </ins> In comparison, an implementation might be able to send data incrementally.  Encryption does not have the same atomicity

Discussion:
This is a good part of what motivates the existence of the mechanism.
The text changes look good to me. I only had a minor remark regarding another sentence.
Change:
4.7. <ins> Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by QUIC to probe for the supported PMTU.  PLPMTUD optionally uses ICMP messages (e.g., IPv6 Packet Too Big messages).  Given known attacks with the use of ICMP messages, the use of PLPMTUD in QUIC has been designed to safely use but not rely on receiving ICMP feedback (see Section 14.2.1. of QUIC-TRANSPORT). Networks are recommended to forward these ICMP messages and retain as much of the original packet as possible without exceeding the minimum MTU for the IP version when generating ICMP messages as recommended in RFC1812 and RFC4443. 4.8. </ins> It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not

Discussion:
addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.
Change:
Type, each of the content coding values is appended to the Content- Type value (media type and parameters, if any), separated by a "@" sign, in the order of the content codings were applied (the same <del> order as in RFC7231).  For example (using a content coding value of "deflate" as defined in RFC7230): </del> <ins> order as in I-D.ietf-httpbis-semantics).  For example (using a content coding value of "deflate" as defined in I-D.ietf-httpbis- semantics): </ins> If no "@" sign is present after the media type and parameters, then no content coding has been specified, and the "identity" content

Discussion:
7de7a76 Update the ABNF to refer to httpbis-semantics; include quoted-pair 7775765 Switch from 7230/7231 to httpbis-semantics 0a57952 Address the question Roman Danyliw did not ask :-)
Change:
5.1. The following MAC algorithm applies to block ciphers that do not use <del> the with Encrypt-then-MAC processing described in RFC7366. </del> <ins> the Encrypt-then-MAC processing described in RFC7366. </ins> The rationale behind this construction is to separate the MAC input for DTLS without the connection ID from the MAC input with the

Discussion:
Tom Petch's review: URL
URL Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >
Change:
associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake. <del> Specificially, an application that has additional information that the client is not behind a NAT and the server is not behind a load </del> <ins> Specifically, an application that has additional information that the client is not behind a NAT and the server is not behind a load </ins> balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a connection ID.

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is <del> also closing or draining.  In this case, the draining state SHOULD end when the closing state would have ended.  In other words, the endpoint uses the same end time, but ceases transmission of any packets on this connection. </del> <ins> also closing or draining.  In this case, the draining state ends when the closing state would have ended.  In other words, the endpoint uses the same end time, but ceases transmission of any packets on this connection. </ins> 10.2.3.

Discussion:
No need for a SHOULD here. (No issue yet.)
Murray might have more choice words.
Change:
Signature Algorithm is applied using the following RSA key (presented here in JWK format): <ins> Key proofing methods SHOULD define a mechanism to allow the rotation of keys discussed in rotate-access-token-key.  Key rotation mechanisms MUST define a way for presenting proof of two keys simultaneously with the following attributes: The value of or reference to the new key material MUST be signed by the existing key.  Generally speaking, this amounts to using the existing key to sign the body of the message. The signature of the old key MUST be signed by the new key. Generally speaking, this means including the signature value of the old key under the coverage of the new key. </ins> 7.3.1. This method is indicated by the method value "httpsig" and can be

Discussion:
To edit notification comments on pull requests, go to your .
The "previous_key" element added in is not necessary in practice because the AS should always be able to look up the current key value based on the access token, and the signature using the previous key proves possession of that key separate from any presentation of the key value or reference.
Makes sense
Change:
using an ACK_FREQUENCY frame, shown below: Following the common frame format described in Section 12.4 of QUIC- <del> TRANSPORT, ACK_FREQUENCY frames have a type of 0xAF, and contain the </del> <ins> TRANSPORT, ACK_FREQUENCY frames have a type of 0xaf, and contain the </ins> following fields: A variable-length integer representing the sequence number

Discussion:
We don't need to change the frame type on each draft version, but I figured that it'd be safer.
Change:
this document in the Reference column for entry 4 in the TLS HandshakeType registry. <del> 9. </del> <ins> 10. </ins> The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
Note: The designated expert RFC5226 only ensures that the specification is publicly available. <del> 8. </del> <ins> 9. </ins> To align with TLS implementations and to align the naming nomenclature for other Handshake message types, IANA is to rename

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
of the parameter. This registry initially contains the following entries: <del> 6.3. This registers a "vapid" parameter for the Crypto-Key header field in the "Hypertext Transfer Protocol (HTTP) Crypto-Key Parameters" established in I-D.ietf-httpbis-encryption-encoding. vapid An ECDSA public key for use in validating vapid tokens restrict of this document </del>

Discussion:
I know that it's the devil, but JSON is the obvious choice here.
Why would it be obvious ? application/x-www-form-urlencoded or a request parameter ?
It's an obvious choice given the proprietary precedence in the industry. I can't really judge the appropriateness of using JSON as opposed to an alternative -- this change LGTM assuming it is. Since the UA chooses the PS, there is no need for encryption. JSON provides good extensibility for additional (proprietary) data that may have to be transmitted over this channel.
At least it's not xml... I don't mind json - just didn't think it is so obvious. It does open an important question: will the user be allowed to pass more information to the push service (voluntarily) ? But +1 on this change.
Probably, but I don't want to think about that just yet :)
Change:
An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as <del> specified in RFC4566, Section 6.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see </del> <ins> specified in RFC4566, Section 6.  The audio and video codecs that MUST be supported are specified in I-D.ietf-rtcweb-audio (see </ins> Section 3) and I-D.ietf-rtcweb-video (see Section 5). If this m= section is for media with configurable frame sizes,

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
the previously valid address, i.e. no switch to the new path takes place and the peer address binding is not updated. <del> When a "return_routability_check" message of type "path_delete" </del> <ins> When a "return_routability_check" message of type "path_drop" </ins> was received, the initiator MUST perform a return routability check on the observed new address, as described in regular.

Discussion:
Signed-off-by: Thomas Fossati
A better name could be or -- one doesn't "delete" a path.
I agree. I prefer path_drop
Change:
validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection.  Unless some other mechanism is used to select <del> HTTP/3, the token "h3" is used in the Application Layer Protocol </del> <ins> HTTP/3, the token "h3" is used in the Application-Layer Protocol </ins> Negotiation (ALPN; see RFC7301) extension during the TLS handshake. Connectivity problems (e.g., blocking UDP) can result in QUIC

Discussion:
as well as other instances of the term. RFC 7301 does indeed hyphenate (and that's correct, since "application-layer" is being used as a single unit to describe "protocol").
URL says the registry is
Change:
Grant Negotiation and Authorization Protocol Resource Server Connections <del> draft-ietf-gnap-resource-servers-latest </del> <ins> draft-ietf-gnap-resource-servers-00 </ins> Abstract

Discussion:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 24fa4dc27f079697512f5eb15ca85b15f1c7ec62 https://deploy-preview-1--gnap-resource-servers-editors-URL
Change:
MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> If the RtpSender of the RtpTransceiver associated with this m=section is active: </del> <ins> If the RtpTransceiver has a sendrecv or sendonly direction: </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.

Discussion:
Reference transceiver direction as opposed to "active" senders/receivers We initially thought there would be an "active" bit on senders/receivers to control the direction of a media description, but instead we now have a "setDirection" API on the transceiver. So we should reference that.
lgtm
Change:
maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6. <del> If this m= section is for video media, an "a=imageattr" line, as specified in sec.imageattr. </del> <ins> If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate

Discussion:
LGTM
G. Section 5.2.1: This section contains the following: Each m= section MUST include the following attribute lines: o If this m= section is for video media, an "a=imageattr" line, as specified in Section 3.6. But, Section 3.6 does not mandate that a=imageattr always is included. Thus the text must be modified to allow the selective inclusion of the attribute based on what needs to be said.
Agreed; although 3.6 allows it to be omitted, we should update the text in 5.2.1 to avoid confusion.
Change:
This specification defines the HTTP Problem Type registry for common, widely-used problem type URIs, to promote reuse. <del> A Designated Expert reviews and approves registration requests, as per RFC8126, Section 4.5.  A specification document is appreciated, but not required. </del> <ins> The policy for this registry is Specification Required, per RFC8126, Section 4.5. </ins> When evaluating requests, the Expert(s) should consider community feedback, how well-defined the problem type is, and this specification's requirements.  Vendor-specific, application-specific, <del> and deployment-specific values are not registrable. </del> <ins> and deployment-specific values are not registrable.  Specification documents should be published in a stable, freely available manner (ideally located with a URL), but need not be standards. </ins> Registrations MAY use the prefix "https://iana.org/assignments/http- <del> problem-types#", and are encouraged to do so when a stable, neutral URI is desirable. </del> <ins> problem-types#" for the type URI. </ins> Registration requests should use the following template:

Discussion:
Currently: That doesn't seem like a recipe for good interop. While it doesn't need to be an RFC, some sort of reference is necessary...
I'm sorry, but I don't quite understand what is being referred to here. Is the quoted paragraph from RFC7807? Because I can't find it. Without more context I also don't quote understand what it is referring to.
NAME https://ietf-wg-URL
Change:
restrictions as the first Initial packet.  A client MUST use the same cryptographic handshake message it included in this packet.  A server MAY treat a packet that contains a different cryptographic handshake <del> message as a connection error or discard it. </del> <ins> message as a connection error or discard it.  Note that including a Token field reduces the available space for the cryptographic handshake message, which might result in the client needing to send multiple Initial packets. </ins> A client MAY attempt 0-RTT after receiving a Retry packet by sending <del> 0-RTT packets to the connection ID provided by the server.  A client MUST NOT change the cryptographic handshake message it sends in response to receiving a Retry. </del> <ins> 0-RTT packets to the connection ID provided by the server. </ins> A client MUST NOT reset the packet number for any packet number space after processing a Retry packet.  In particular, 0-RTT packets

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:
MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supported_groups" extension.  Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its <del> corresponding KeyShare. </del> <ins> corresponding KeyShare.  Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal "illegal_parameter" alert. </ins> If no mutually supported group is available between the two endpoints' KeyShare offers, yet there is a mutually supported group

Discussion:
The current text is a mix of omitting and sending empty, as pointed out by Ilari on the mailing list. This fixes things and switches to an always-send model.
This looks good to me modulo the issue noted above
NAME Ok, I've pushed a second commit here which clarifies that point and also reconciles the fact that the two extensions here both claim to determine group priority. Suggestions to reduce verbosity without reducing clarity would be appreciated. (this commit fixes issue )
Typo fixed & rebased.
Since the list is in favor of "forward secrecy" over "forward security", I've changed my use of the term in this PR to the former (a commit just landed to change the existing uses elsewhere). Not rebased again; still merges cleanly (for the moment, at least).
Change:
If an entire connection needs to be terminated, QUIC similarly provides mechanisms to communicate a reason; see QUIC-TRANSPORT. <del> This is referred to as a "".  Similar to stream errors, an HTTP/3 implementation can terminate a QUIC connection and communicate the reason using an error code from http-error-codes. </del> <ins> This is referred to as a "".  Similar to , an HTTP/3 implementation can terminate a QUIC connection and communicate the reason using an error code from http-error-codes. </ins> Although the reasons for closing streams and connections are called "errors", these actions do not necessarily indicate a problem with

Discussion:
NAME was helpful enough to show me how to do this in URL, so now singular and plural versions of the same term are a single index entry.