jiebi/CodeConvo huggingface dataset:
Change:
handshake, authenticating for ECHConfig.contents.public_name as described in auth-public-name.  If authentication or the handshake fails, the client MUST return a failure to the calling application. <del> It MUST NOT use the retry keys. </del> <ins> It MUST NOT use the retry configurations. </ins> <del> Otherwise, when the handshake completes successfully with the public name authenticated, the client MUST abort the connection with an </del> <ins> Otherwise, if both authentication and the handshake complete successfully, the client MUST abort the connection with an </ins> "ech_required" alert.  It then processes the "retry_configs" field from the server's "encrypted_client_hello" extension.

Discussion:
The reference to "retry keys" comes from when the field was called retrykeys and the type ESNIKeys. We've since renamed them to retryconfig and ECHConfig, so the prose should match.
Change:
8.1. <del> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying relay services that are on path between clients and servers avoids adding significant additional delay due to network topology.  A study of a similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. </del> <ins> Using Oblivious HTTP adds both cryptographic overhead and latency to requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between clients and servers avoids adding significant additional delay due to network topology. A study of a similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. </ins> 8.2.

Discussion:
In Deployment Considerations / Performance Overhead... Should that be "cryptographic" -> "cryptographic complexity" or something like that?
It should probably be "cryptographic overhead." Nice catch!
Change:
defined in QUIC) in Supported Version fields. Clients will ignore a Version Negotiation packet if it contains the <del> original version attempted by the client.  The client also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. </del> <ins> original version attempted by the client; see downgrade.  The client also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. </ins> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it

Discussion:
URL here, it feel lacking normative language. The current text gives feel like there are other options the client can do and these are examples. if that is true what are those other options? if the client behave differently than described here as there is no normative language will that not cause interoperability issues?
The normative language already exists in . That said, the QUIC-VN draft is written in terms of QUIC invariants so we should tweak this.
we should or we should not?
We should
takes care of this
Change:
that it will not be able to reach the MASA during deployment.  See RequestVoucherFromMASA. <del> The following example illustrates a registrar voucher-request. The 'prior-signed-voucher-request' leaf is not populated with the pledge voucher-request because the pledge did not sign its own request.  This form might be used when more constrained pledges are being deployed.  The nonce is populated from the pledge's request.  See RequestVoucherFromMASA. </del> 3.4. Following is a YANG RFC7950 module formally extending the RFC8366

Discussion:
This should be a complete set of diffs for removing unsigned pledge voucher-requests from the text.
For issue
The text "This artifact may be optionally signed" is buried in the yang module (ietf-voucher-URL) and needs to be removed.
When a pledge decides to use an unsigned voucher request, the Registrar will place it into prior-signed-voucher request on the BRSKI-MASA arc. It will be JSON embedded in. When a pledge decides to use a signed voucher request, the Registrar will place the base64 encode of the pledge_request in as a string. The MASA can tell the difference between the two because the signed thing (whether CBOR, COSE, CMS signed CBOR, or CMS signed JSON) will always be base64 encoded. We need to explain this somewhere.
section 5.5 indicates that: prior-signed-voucher-request: If a signed pledge voucher-request was received then it SHOULD be included in the registrar voucher- request. (NOTE: what is included is the complete pledge voucher- request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This indicates that the MASA never needs to "tell the difference" only the registrar. (The pledge to registrar signaling is via request media type as detailed in s5.2). I did notice this when reading: s3.3. these references to voucher in the leaf description should be to voucher request? "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field." etc. subsequent paragraphs.
URL tries to fix the lack of specification for unsigned voucher requests.
Max to produce a draft branch that removes unsigned voucher request so we can examine the ramifications of this.
v20 of BRSKI removed unsigned voucher requests. What were the reasons for removing? I don't see a mention of this in the anima WG email. If removed as a final decision, then this issue can be closed also.
Hi, yes, we could close this now. I did post several times to the list in Feb and March, and it was raised during the WG meeting itself, asking for feedback.

Ok, I now see the email list discussion also in December 2018 and based on this the unsigned voucher was removed.
Change:
abort the connection with a "decrypt_error" alert. If the decrypted value's length is different from the advertised <del> ESNIConfig.padded_length or the padding consists of any value other than 0, then the server MUST abort the connection with an </del> <ins> ESNIConfigContents.padded_length or the padding consists of any value other than 0, then the server MUST abort the connection with an </ins> "illegal_parameter" alert.  Otherwise, the server uses the PaddedServerNameList.sni value as if it were the "server_name" extension.  Any actual "server_name" extension is ignored, which also

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.
Change:
the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. <del> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </del> <ins> A token SHOULD be constructed in a way that allows the server to distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </ins> The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was

Discussion:
This addresses some questions about use of multiple tokens, as well as cleaning up the text adjacent in minor ways.
The spec doesn't define what is a client is supposed to do when it receives multiple NEWTOKEN frames. There seem to be multiple reasonable ways to handle this situation: A client could always use the oldest token first. This would allow the client to establish multiple connections at the same time. A client could replace any old tokens when receiving a new token. This has the advantage that the most recently issued token will (presumably) have the longest life time. Furthermore, if the server encodes connection statistics (RTT, cwnd, etc.) into the ticket, using the newest ticket would provide it with the most recent data. From the Slack discussion, a better way might be a combination of these two: When establishing a new connection, use the most recently obtained token first. When establishing another connection to the same server (before receiving a new NEWTOKEN), use an older token. Client might then want to remember n tokens per endpoint, if they expect to establish n new connections simultaneously (or a few more than n, depending on the network conditions, to account for failed connection establishments).
Your suggestion SGTM.
This is fine, and it merely reflects reality: older tokens are less likely to be useful. But there is no harm in attempting to use any token, provided that it hasn't been used before.
Do we need text about that? NAME do you want me to prepare a PR?
I think that an editorial PR would be great. This is advice that doesn't change interoperability.
Some suggestions, but looks good.
Change:
both <start-time> and <stop-time> SHOULD be set to zero, e.g. "t=0 0". <del> An "a=msid-semantic:WMS" line MUST be added, as specified in I- D.ietf-mmusic-msid, Section 4. </del> <ins> An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. </ins> The next step is to generate m= sections, as specified in RFC4566 Section 5.14, for each MediaStreamTrack that has been added to the

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
The Registration Resource may also be used to inspect the registration resource using GET, update the registration link <del> contents using PATCH, or cancel the registration using DELETE. </del> <ins> contents using PATCH (as introduced in RFC8132), or cancel the registration using DELETE. </ins> These operations are described in this section.

Discussion:
The document uses the PATCH request method and the 4.09 response codes defined there. Closes: URL
This is needed for the 4.09 error code referenced.
Note to self: That draft is now
Looks good.
Change:
MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to <del> zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed. </del> <ins> zero and the "a=msid" line MUST be removed. </ins> If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the

Discussion:
a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.
Change:
Upon receipt, the Client handles the response and, if successful, deserializes the body values TokenResponse.evaluate_response and <del> TokenResponse.evaluate_proof.  If deserialization of any value fails, the Client aborts the protocol.  Otherwise, when deserialization yields "evaluated_msg" and "proof", the Client processes the response as follows: </del> <ins> TokenResponse.evaluate_proof, yielding "evaluated_element" and "proof".  If deserialization of either value fails, the Client aborts the protocol.  Otherwise, the Client processes the response as follows: </ins> <del> The Finalize function is defined in OPRF, Section 3.3.3.  If this </del> <ins> The Finalize function is defined in OPRF, Section 3.3.2.  If this </ins> succeeds, the Client then constructs a Token as follows: Otherwise, the Client aborts the protocol.

Discussion:
Since metadata can be bound to tokens via TokenChallenge.redemptioncontext, and the origin is ultimately the one who determines what metadata is supported, there's no more real need for the issuer_ to supply this metadata. So let's go with the simpler VOPRF protocol instead! Test vectors generated from the code here: URL cc NAME NAME NAME
LGTM
Change:
these parameters (hex encoded) An implementation should reproduce the output values given the input <del> values.  Encryption with the input values and the plaintext should produce the ciphertext.  Decryption with the input values and the ciphertext should produce the plaintext. </del> <ins> values: * An implementation should be able to encrypt with the input values and the plaintext to produce the ciphertext.  * An implementation must be able to decrypt with the input values and the ciphertext to generate the plaintext. </ins> Line breaks and whitespace within values are inserted to conform to the width requirements of the RFC format.  They should be removed

Discussion:
PR fixes URL PR also updates AES-CTR test vectors accordingly. PR clarifies that decryption ought to work but comparing encrypted data may sometimes fail.
The spec says: Counter Length (LEN): 3 bits This field indicates the length of the CTR fields in bytes. This probably means 000 is 1 byte, 001 is 2 bytes, and so on... It would be good to clarify this.
Change:
distinct tickets will be needed to prevent premature ticket invalidation by racing. <del> Connection priming: In some systems, connections may be primed or </del> <ins> Connection priming: In some systems, connections can be primed or </ins> bootstrapped by a centralized service or daemon for faster connection establishment.  Requesting tickets on demand allows such services to vend tickets to clients to use for accelerated

Discussion:
If they don't enforce a limit, clients can cause them to do a lot of work.
Fixed by .
Approved pending
Change:
mark them explicitly uncacheable (for example, using Cache-Control: no-store RFC7234 Section 5.2.2.3). <del> The URI SHOULD NOT contain an IP address literal. </del> <ins> The URI SHOULD NOT contain an IP address literal.  Exceptions to this might include networks with only one operational IP address family where DNS is either not available or not fully functional until the captive portal has been satisfied. </ins> Networks with no captive portals MAY explicitly indicate this condition by using this option with the IANA-assigned URI for this

Discussion:
Approved -- discussed on phone...
""" The URI SHOULD NOT contain an IP address literal. Why not, and how does it maintain interoperability to have this as SHOULD NOT, rather than MUST NOT? """
My recollection (possibly faulty), is that we could have made this a MUST NOT in large part because we want the URI to be identical across IPv4 and IPv6 -based options, but that going from SHOULD NOT to MUST NOT could be over-prescriptive. Is my recollection correct, and would such a move be over-prescriptive?
That is right. It is also somewhat more challenging to get a valid certificate for an IP address than a domain name.
Change:
7.2.8. This design has no impact on application layer protocol negotiation. <del> It only affects connection routing, server certificate selection, and </del> <ins> It may affect connection routing, server certificate selection, and </ins> client certificate verification.  Thus, it is compatible with multiple protocols.

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.
Change:
to DeriveKeyPair. For example, suppose there is a group with four members, with C an <del> unmerged leaf at node 5: </del> <ins> unmerged leaf at Z: </ins> If member B subsequently generates an UpdatePath based on a secret "leaf_secret", then it would generate the following sequence of path

Discussion:
This PR adds two clarifications suggested by NAME Clarifying some antecedents in UpdatePath processing Explaining how the example trees can come about in practice
Change:
1. <del> Words... </del> <ins> This document defines a simple format for representing an HTTP message (HTTP), either request or response.  This allows for the encoding of HTTP messages that can be conveyed outside of an HTTP protocol.  This enables the transformation of entire messages, including the application of authenticated encryption. This format is informed by the framing structure of HTTP/2 (H2) and HTTP/3 (H3).  In comparison, this format simpler by virtue of not including either header compression (HPACK, QPACK) or a generic framing layer. This format provides an alternative to the "message/http" content type defined in MESSAGING.  A binary format permits more efficient encoding and processing of messages.  A binary format also reduces exposure to security problems related to processing of HTTP messages. Two modes for encoding are described: a known-length encoding includes length prefixes for all major message components; and an indefinite-length encoding enables efficient generation of messages where lengths are not known when encoding starts. </ins> 2.

Discussion:
This is fully-featured, which is a little awkward. We can probably trim this down a little once we have a better handle on the requirements.
NAME is the idea here that padding might just be a separate field for each (un)known-length message?
Not sure if you meant to ask this on instead. The idea I had for padding is that the format as described is self-delimiting. (Actually, it was accidental, and I only realized that it worked that way after coming back and thinking about padding.) Therefore, you can just add padding at the end. We can mandate the use of zero bytes, which works for the truncated message syntax I suggest here.
The format I've sketched out for binary messages can be padded with zeros without needing a separate padding field. That's probably a feature worth mentioning in both drafts.
Padding is in the binary HTTP draft now.
Change:
encoded using the QUIC variable length integer scheme described in RFC9000. <ins> If at any point a session ID is received that cannot a valid ID for a client-initiated bidirectional stream, the recepient MUST close the connection with an H3_ID_ERROR error code. </ins> 4.1. Once established, both endpoints can open unidirectional streams.

Discussion:
NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!
Change:
Message lengths can be defined, and Messages can be partially reliable. <ins> Below, primitives in the style of "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL" (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of RFC8303.  For further implementation details, the description of these primitives in RFC8303 points to section 3, which refers back the specifications for each protocol.  This back-tracking method applies to all elements of I-D.ietf-taps-minset (see appendix D of I- D.ietf-taps-interface): they are listed in appendix A of I-D.ietf- taps-minset with an implementation hint in the same style, pointing back to section 4 of RFC8303. </ins> 9.1. Connectedness: Connected

Discussion:
(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.