jiebi/CodeConvo huggingface dataset:
Change:
each share in the candidate report set until the underlying VDAF moves into a terminal state, yielding an output share for all aggregators or an error.  This phase may involve multiple rounds of <del> interaction depending on the underlying VDAF parameters.  Each round trip is initiated by the leader. </del> <ins> interaction depending on the underlying VDAF.  Each round trip is initiated by the leader. </ins> 4.3.2.1.

Discussion:
The next VDAF draft is out. It includes some minor changes that we'll need to adopt here. URL
Change:
described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key. <del> %%% Record Layer struct { ContentType type; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; } fragment; } TLSCiphertext; </del> <ins> %%% Record Layer struct { ContentType opaque_type = application_data(23); /* see fragment.type _/ ProtocolVersion record_version = { 3, 1 }; /_ TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; ContentType type; } fragment; } TLSCiphertext; </ins> <del> The type field is identical to TLSPlaintext.type. </del> <ins> The outer opaque_type field of a TLSCiphertext record is always set to the value 23 (application_data) for outward compatibility with middleboxes used to parsing previous versions of TLS.  The actual content type of the record is found in fragment.type after decryption. </ins> The record_version field is identical to

Discussion:
This pull request has been updated to the current master
Consensus at meeting to merge this PR with updates and with the dummy type byte restored. NAME has action item to actually measure whether we can strip off the now fixed type, record.version bytes.
I've updated this with the expected changes: dummy external ContentType octet is restored, and URL is after fragment.content instead of the other way around (to make it easier to encrypt without having to shuffle buffers).
I agree with davegarrett's suggestion about field naming here, and have supplied a change implementing it.
TLSCiphertext.recordversion provides no useful information, encourages implementations to check it unnecessarily, and wastes two bytes per record. It should be removed entirely. This is effectively dependent on PR or similar changes. Filing this as a specific issue rather than just bringing it up in backwards compatibility discussion. Edited to add: Note that this value is called TLSCiphertext.version in TLS 1.2 and TLSCiphertext.recordversion as of TLS 1.3 draft 06. The TLSPlaintext equivalent of this version field cannot be removed as it is required for backwards compatibility, however it's only used with ClientHello at this point.
Defer pending measurements. Note that this fate shares with removing the cleartext content type
sgtm Amending issue title.
Mozilla is working on measurements.
Change:
Links that did not have an anchor attribute are therefore returned with the (explicitly or implicitly set) base URI of the registration <del> as the anchor.  Links whose href or anchor was submitted as an absolute URI are returned with respective attributes unmodified. </del> <ins> as the anchor.  Links whose href or anchor was submitted as a (full) URI are returned with respective attributes unmodified. </ins> Above rules allow the client to interpret the response as links without any further knowledge of what the RD does.  The Resource

Discussion:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.
Change:
"signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. <del> Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 ECDSA and FIPS 186-4 DSS, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </del> <ins> Indicates a signature algorithm using ECDSA DSS, the corresponding curve as defined in NIST SP 800-186 ECDP, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest

Discussion:
FIPS 186-4 is obsolete Curve definitions have moved to the new NIST SP 800-186 ANSI X9.62 is behind a paywall and should be avoided if possible. References behind paywall can not be accessed by most readers. This makes it harder to implement and to evaluate the security of the protocol. FIPS 186-5 removed the dependency on ANSI X9.62 and defines ECDSA itself. Point validation is defined in the new NIST SP 800-186.
Change:
QUIC begins every connection in slow start and exits slow start upon loss or upon increase in the ECN-CE counter.  QUIC re-enters slow <del> start anytime the congestion window is less than ssthresh, which typically only occurs after an PTO.  While in slow start, QUIC increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed. </del> <ins> start anytime the congestion window is less than ssthresh, which only occurs after persistent congestion is declared.  While in slow start, QUIC increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed. </ins> 7.3.

Discussion:
From a full read en route to Prague.
Thanks Jana, suggestions taken and "Clearer Loss Epoch" rewritten.
Change:
In the other direction, when a CONNECT-IP endpoint receives an IP packet, it checks to see if the packet matches the routes mapped for <del> a CONNECT-IP forwarding path, and performs the same forwarding checks as above before transmitting the packet over HTTP Datagrams. </del> <ins> a CONNECT-IP forwarding tunnel, and performs the same forwarding checks as above before transmitting the packet over HTTP Datagrams. </ins> Note that CONNECT-IP endpoints will decrement the IP Hop Count (or TTL) upon encapsulation but not decapsulation.  In other words, the

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 string "dns" <del> A random value with at least 128 bits of entropy.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </del> <ins> The value to be used in generation of validation record to be provisioned in DNS.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> In response to this challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. <del> 6. </del> <ins> 4.2. To prevent PSK Importers from being confused with standard out-of- band PSKs, imported PSKs change the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: Imported PSKs replace the string "ext binder" with "imp binder" when deriving "binder_key".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  As "binder_key" is a leaf key, changing its computation does not affect any other key. 5. </ins> If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they remove the corresponding KDF from the set of target KDFs used for importing keys.  This does not affect the KDF operation used to derive Imported PSKs. <del> 7. </del> <ins> 6. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
Servers receiving a "dnssec_chain" extension in the ClientHello, and which are capable of being authenticated via DANE, SHOULD return a <del> serialized authentication chain in the Certificate message associated with the end entity certificate being validated, using the format described below.  The authentication chain will be an extension to the certificate_list to which the certificate being authenticated belongs. </del> <ins> serialized authentication chain in the extension block of the Certificate message containing the end entity certificate being validated, using the format described below. </ins> The extension protocol behavior otherwise follows that specified for TLS version 1.2.

Discussion:
Draft 05. Tried to address all the outstanding comments during the WGLC. Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version.
Change:
Add a "Recommended" column to the cipher suite registry.  The cipher suites that follow in the two tables are marked as "Yes". <del> All other cipher suites are marked as "No". </del> <ins> All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards Track document RFC5226 is required to register a cipher suite with the value "Yes". Update the reference for this registry to also point to this document. </ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites

Discussion:
Addresses .
Also addresses .
LGTM
We need to update the registry's reference to point to this document if we require new CS definitions to indicate whether the Recommended column is Yes or No (see ).
The cipher suite "recommended" column needs to include something along the line of the following: Future cipher suites MUST define the value of the Recommended column. A Standards Track document [RFC5226] is required to register a cipher suite with the value “Yes”.
Change:
Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST <del> correct the requests (with the execption of 409 where no correction </del> <ins> correct the requests (with the exception of 409 where no correction </ins> is required) before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors.

Discussion:
NAME let me know if this fixes the issue
You'll want to link or close it, but yes, this is good.
This is a problem for our format. Please try to keep examples to 69 columns (or 72 in a pinch). These examples are free-form strings in JSON, so they can probably just be wrapped.
NAME take a look at PR URL and let me know if ok now.
Change:
Note that the URI parameter is not null terminated. <ins> The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 DHCP options. </ins> 2.3. This section describes the Captive-Portal Router Advertisement

Discussion:
Additionally, clarify recommended URI limit of 255 in each of DHCPv6 and IPv6 RA option description text.
Approved (text crafted on phone). The duplication of the warning length is intentional....
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.
Change:
with RFC2914.  Also note that reliability is usually combined with congestion control in protocol implementations, rendering "reliable but not congestion controlled" a request that is unlikely to succeed. <del> The recommended default is to Require that the Connection is congestion controlled. </del> <ins> The default is to Require that the Connection is congestion controlled. </ins> 5.2.10.

Discussion:
Added defaults for interface and PvD following . Also, I caught one leftover "recommended default".
We require implementations to have default but we don't provide any recommendation for interface and PvD.
For Interface, this would the default be to set "Ignore" on all available interfaces, right? This indicates that the application has no preferences of its own, so the implementation can apply some default system policy. Also, if the application specified some local endpoint, this might constrain the actual interfaces used (related to ). If we try to phrase this as (Preference, Enumeration), it reads a bit weird though: ("Ignore", "Cellular") and ("Ignore", "WiFi"), for example. So perhaps we should just write text saying that the default is to set no application preference.
I think text is fine as well but we need to say something.
Thanks!
Change:
inspect a copy of the information, usually mirrored by an optical splitter, making it an ideal pairing for DPI and Protocol Identification Weaver-2009 (this asynchronous version of a MITM is <del> ofen called a Man-on-the-Side (MOTS)).  RST Packet Injection also has the advantage of only requiring one of the two endpoints to accept the spoofed packet for the connection to be interrupted.  The </del> <ins> often called a Man-on-the-Side (MOTS)).  RST Packet Injection also has the advantage of only requiring one of the two endpoints to accept the spoofed packet for the connection to be interrupted.  The </ins> difficult part of RST Packet Injection is spoofing "enough" correct information to ensure one end-point accepts a RST packet as legitimate; this generally implies a correct IP, port, and (TCP)

Discussion:
A few more typos I found while I was reading this I-D.
Thanks again!
Change:
Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance <del> of either the peer's identity or of it's liveness (i.e., the </del> <ins> of either the peer's identity or of its liveness (i.e., the </ins> ClientHello might have been replayed). The key used to compute the finished message is computed from the

Discussion:
NAME NAME I would appreciate a sanity check here.
Maybe remove the "arguably" statement and the *
Change:
redemption, or the client redeeming the token and passing the result along to the target endpoint.  These two methods are described below. <ins> In the HTTP ecosystem, redemption contexts should generally be keyed by the same privacy boundary used for cookies and other local storage.  Generally this is the top-level origin.  Any redemption context should be built following the principles outlined in draft- ietf-privacypass-architecture and later in privacy. </ins> 6.1. <del> Inputs: - "server_id": The server ID to redeem a token against.  - "ciphersuite": The ciphersuite for this token.  - "public_key": The public key associated with this token.  - "redemption_token": A Privacy Pass token.  - "info": Additional data to bind to this token redemption. </del> <ins> Inputs: - "context": The request context to use.  - "server_id": The server ID to redeem a token against.  - "ciphersuite": The ciphersuite for this token.  - "public_key": The public key associated with this token.  - "redemption_token": A Privacy Pass token.  - "info": Additional data to bind to this token redemption. </ins> Outputs: - "result": The result of the redemption from the server. <ins> The client should check whether the "server_id" is present in the "context".  If it isn't and the size of the "context" is beneath the client's limit, it should be added. </ins> The client should call the "Redeem" function with "redemption_token" and additional data of "info" storing the resulting "data" and "tag".

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> The following entries are added to the "HTTP/2 Settings" registry established by RFC7540:

Discussion:
Chair: discussed during editors' call, plan is to go with Martin's simpler proposed encoding. We might want to discuss non-zero defaults later, but that'll be its own separate issue.
The document currently does not specify what the initial flow control windows are, nor how to change those. We have two options: Add WT_SETTINGS capsule Put those into headers
Discussed in editor's meeting, initial thinking is to put these values into the headers on the CONNECT message, rather than defining a new capsule or otherwise polluting HTTP/2's settings
Is there any reason that you want to avoid settings? The main thing that using settings would do is to provide the client with non-zero initial flow control limits on WT streams, so that it can send application data with zero latency. You can't get that without using settings. Functionally speaking, there is no real difference between a new capsule and a field, except that you can be a little more efficient with a capsule, modulo some issues regarding sequencing (do you allow it to appear anywhere? how do you manage changing values? etc...)
If we're talking about H2-connection level settings, then those are scoped to the entire connection. Using those would bring us closer to how H3 behaves (where connection-level stream configuration applies to WebTransport stream due to WT streams also being QUIC streams). On the other hand, we have designed WebTransport over HTTP/2 so that everything that happens within the CONNECT stream, so using headers/capsule instead of settings would be consistent with that. It would also mean you can transparently proxy WT-H2 to WT-H2 without parsing it (I do realize we currently say that you're not supposed to do that). Agreed. I have a mild preference for header fields since those are guaranteed to always arrive before any payload, making reasoning about their properties slightly easier.
The problem, as I see it, is that fields or capsules both lead to a situation where the client is unable to send any application data in its first flight (that is, along with the CONNECT-wossname request). What I want to avoid is the case where clients decide to improve performance by remembering initial values. I'm very much inclined to implement that caching, if only because it means that we can start using a session more quickly (for anything other than 0-RTT).

Perhaps the right answer is that we need some sort of way to encapsulate origin-wide per-resource configuration (that is, a baseline configuration that applies to all resources on the origin) and - until then - we stick with populating each resource with fields.
Chair: discussed during editors' call, see URL
Any reason why you did not do a single header field, like: Then at least the common repetitive stuff isn't repeated.
Change:
A Probe Timeout (PTO) triggers sending one or two probe datagrams when ack-eliciting packets are not acknowledged within the expected <del> period of time or the handshake has not been completed.  A PTO enables a connection to recover from loss of tail packets or acknowledgements. </del> <ins> period of time or the server may not have validated the client's address.  A PTO enables a connection to recover from loss of tail packets or acknowledgements. A PTO timer expiration event does not indicate packet loss and MUST NOT cause prior unacknowledged packets to be marked as lost.  When an acknowledgement is received that newly acknowledges packets, loss detection proceeds as dictated by packet and time threshold mechanisms; see ack-loss-detection. </ins> As with loss detection, the probe timeout is per packet number space. The PTO algorithm used in QUIC implements the reliability functions

Discussion:
The fact that PTO doesn't declare losses when it expires is quite important. It at the very end of the section, so I moved it to the first part. Also removed a section heading(pto-loss) which was never referenced.
A reasonable simplification.