jiebi/CodeConvo huggingface dataset:
Change:
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA <del> records.  Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non- intuitive manner, the challenge must be completed over HTTP, not HTTPS. </del> <ins> records, at its discretion.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. </ins> The string "http-01"

Discussion:
This reverts commit a5cb357a64ce5e46815544c9faaf94b97b3eba56 I think we did not reach consensus on the list about this feature.
Oh, it's a shame that this was removed. I was hoping to use this feature to help when my servers were behind a load balancer. We should probably remove this reference as well:
Change:
process those acknowledgments in order to detect lost Handshake packets. <ins> QUIC also needs access to keys that might not ordinarily be available to a TLS implementation.  For instance, a client might need to acknowledge Handshake packets before it is ready to send CRYPTO frames at that encryption level.  TLS therefore needs to provide keys to QUIC before it might produce them for its own use. </ins> 4.1.5. exchange-summary summarizes the exchange between QUIC and TLS for both client and server.  Each arrow is tagged with the encryption level used for that transmission. <ins> exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what incoming messages trigger different actions.  New handshake messages are requested after all incoming packets have been processed.  This process might vary depending on how QUIC implementations and the packets they receive are structured. </ins> 4.2. This document describes how TLS 1.3 TLS13 is used with QUIC.

Discussion:
URL a TLS stack. The canonical example being the Handshake keys, which are needed by a client to acknowledge partial server Handshake flights. TLS won't use those keys itself until it has the entire set of Handshake messages from the server. In doing this, I decided that it makes sense to reorder the sequence diagram to show what incoming packets trigger different events.
In order for the client to be able to acknowledge packets sent with Handshake encryption level, it needs to have access to the Handshake write key right after processing the ServerHello. URL states that the Handshake write key is exported after receiving the server's Finished message, which would make loss recovery of Handshake packets impossible. I found this fact non-obvious, and I think it should be documented in some way that we're deviating from the schedule in which a normal TLS 1.3 implementation would make new keys available.
I had the same realization a while ago, but failed to capture that in the spec. It's a fairly important point that - if ignored - would lead to bad outcomes, because a good part of the time you can get away with not exporting it early. You mostly just get transient errors... until the server can't fit its certificate into 3 packets, then you get a hard fail.
Change:
The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. <del> certificate_types has been present in TLS since SSLv3, but was </del> <ins> certificate_types has been present in TLS since SSL 3.0, but was </ins> somewhat underspecified.  Much of its functionality is superseded by supported_signature_algorithms.  The following rules apply:

Discussion:
Small editorial change: The document currently goes back and forth between "SSLv3" & "SSL 3.0". Stick with the latter for consistency and clarity.
Change:
forward the packets to that server without retaining connection state. <del> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </del> 9.2. While sufficiently robust connection ID generation schemes will

Discussion:
addresses issue
Is this something application designers need to think about or manage? I would hope QUIC implementations would handle this transparently. To the extent you have to configure something like QUIC-LB, that's a manageability thing.
Connection IDs are weird, in that they are important to both implementors / deployers (so applicability) as opposed to operators of networks that are not necessarily at the endpoints (so manageability)
There is text about Connection ID in both documents. We can double-check though that the text is well aligned and splitter correctly.
Well, implementors are explicitly out of scope according to the document's introduction. I would hope that apps didn't have to worry about Connection ID properties very much, or at all. Maybe there is knob or two for information exposure, at most, but I'd consider most of this text to be extraneous to the applicabilty draft.
I think we actually put some text in the wrong doc. PR moves this text from applicability to manageability.
Change:
1. This document describes how the W3C WEBRTC RTCPeerConnection <del> interface W3C.WD-webrtc-20140617 is used to control the setup, management and teardown of a multimedia session. </del> <ins> interface W3C.webrtc is used to control the setup, management and teardown of a multimedia session. </ins> 1.1.

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
in split DNS configurations RFC6950.  It logically follows that the server which is queried can influence the end result.  Therefore a client's choice of DNS server may affect the responses it gets to its <del> queries. </del> <ins> queries.  For example, in the case of DNS64 RFC6147, the choice could affect whether IPv6/IPv4 translation will work at all. </ins> The HTTPS channel used by this specification establishes secure two party communication between the DNS API Client and the DNS API

Discussion:
wrt mailing list thread DNS64 and DOH andrew sullivan suggests modifying an existing paragraph in operational considerations to have one new sentence: servers may provide different results to the same query: for instance in split DNS configurations [RFC6950]. It logically follows that the server which is queried can influence the end result. Therefore a client's choice of DNS server may affect the responses it gets to its queries. In the case of DNS64 [RFC6147], the choice could affect whether IPv6/IPv4 translation will work at all. in my opinion that's fine. We don't need to enumerate everything, but DNS64 was already called out as a non goal so we might as well note this implication of that.
PR
Change:
negotiated and conveyed using the Capsule Protocol; see datagram- capsule. <del> HTTP Datagrams MUST only be sent with an association to a stream whose HTTP semantics explicitly supports HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be sent associated with GET or POST request streams. If an HTTP Datagram associated with a method that has no known semantics for HTTP Datagrams is received, the receiver MUST abort the corresponding stream; if HTTP/3 is in use, the stream MUST be aborted with H3_DATAGRAM_ERROR.  HTTP extensions can override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams. </del> <ins> HTTP Datagrams MUST only be sent with an association to an HTTP request that explicitly supports them.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be sent associated with GET or POST request streams. If an HTTP Datagram is received and it is associated with a request that has no known semantics for HTTP Datagrams, the receiver MUST terminate the request; if HTTP/3 is in use, the request stream MUST be aborted with H3_DATAGRAM_ERROR.  HTTP extensions can override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams. </ins> 2.1.

Discussion:
... and indirectly associated with streams
Section 2: "HTTP Datagrams MUST only be sent with an association to a stream whose HTTP semantics explicitly supports HTTP Datagrams." I think the reference to "stream" is unclear here. Is the intention here to refer to "HTTP Message" or "HTTP Method" that would then in HTTP/2 and HTTP/3 map to a stream? Anyway align with next paragraph that uses "Method".
The subsequent use of "method" is not great. I would substitute both with "request" e.g. "HTTP Datagrams MUST only be sent with an association to an HTTP request that explicitly supports them." ... "If an HTTP Datagram is received and it is associated with a request that does not support HTTP Datagrams, the receiver MUST terminate the request...."
Agreed, switching to request would be clearer
Change:
too many times.  This is determined by the maximum number of times a batch can be queried, "max_batch_query_count".  Unless the query has been issued less than "max_batch_query_count" times, the Aggregator <del> MUST abort with error of type "batchLifetimeExceeded". </del> <ins> MUST abort with error of type "batchQueriedTooManyTimes". </ins> Finally, the Aggregator checks that the batch does not contain a report that was included in any previous batch.  If this batch

Discussion:
NAME please have another look
This seems useful, since it disambiguates "tasklifetime" and "batchlifetime". The former, as i understand it, is a timestamp; and the latter is a number of queries. cc/ NAME for thoughtful review here
Change:
KeyPackage, the leaf secret from which the Commit is built, and the intermediate key pairs along the direct path to the root. <del> A new member receiving a Welcome message can recognize group creation if the number of entries in the "members" array is equal to the number of leaves in the tree minus one.  A client receiving a Welcome message SHOULD verify whether it is a newly created group, and if so, SHOULD verify that the above process was followed by reconstructing the Add and Commit messages and verifying that the resulting transcript hashes and epoch secret match those found in the Welcome message. </del> 10. Over the lifetime of a group, its membership can change, and existing

Discussion:
As discussed on this removes the paragraph in the Group Creation section specifying that joiners SHOULD verify group creation if it is detected. A recent change to group creation - namely a random initial - makes it impossible to verify group creation.
URL Hi Eric, I agree with (2). I think the stuff that's in the spec right now about verifying group creation is mainly just a legacy of the fact that we used to have separate Init and Add operations. When those got coalesced into Welcome, it must have seemed appealing to enable recipients to continue to distinguish the cases. But as you point out, that's not really tenable. So please feel free to send a PR! Thanks, --Richard Cornelissen Eric wrote:
Change:
Welcome message at the same time, by taking the following steps: Construct an initial Commit object with the "proposals" field <del> populated from Proposals received during the current epoch, and empty "key_package" and "path" fields. </del> <ins> populated from Proposals received during the current epoch, and an empty "path" field. </ins> Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object, as described in

Discussion:
It looks like in Commit was moved to in UpdatePath, but some docs didn't get updated.
Change:
Values, or membership in a set of Reference Values, or a check against values in other Claims, or any other test. <ins> The actual data format and semantics of any Appraisal Policy is implementation specific. </ins> 3.2. Reference Values used in appraisal come from a Reference Value

Discussion:
Signed-off-by: Dave Thaler
While Reference Values have a strong focus on conveyance and data format, Appraisal Policies do not. Is there a specific reason for this asymmetry? Additionally, there is a statement on scope on the Reference Value that does not exist for Appraisal Policies. Does that imply something?
Add some additional words to Appraisal policy like: URL
Agreed to also move to section 6, about appraisal/etc. combinations.
Change:
the status field. A CSR encoding the parameters for the certificate being requested <del> RFC2986.  The CSR is sent in the Base64url-encoded version of the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) </del> <ins> RFC2986.  The CSR is sent in the base64url-encoded version of the DER format.  (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) </ins> The requested value of the notBefore field in the certificate, in the date format defined in

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
The client's stream terminated without containing a fully-formed request. <del> The remainder of the client's request is not needed to produce a response.  For use in STOP_SENDING only. </del> The connection established in response to a CONNECT request was reset or abnormally closed.

Discussion:
Does it matter if the the STOPSENDING error code is something other than EARLY RESPONSE? Originally posted by NAME in URL Moving this out to a separate issue to avoid complicating ; my inclination is to propose the following rules: When a STOPSENDING is received, if the error code has semantics in the context in which you received it, follow the semantics. If the error code has no semantics in that context (or is unknown), then it has no direct effect on the viability of the request or the response. If resetting your request stream causes the server to be unable to generate a response, it will reset its stream. If it sends a complete response, the server clearly got everything it needed; the response is usable. If a response stream is reset after all bytes have been received, the response remains usable; no takebacks.
Several of these are already in the draft: Perhaps the clarification that's needed is to keep the "MAY abort reading," but separately say that "H3EARLYRESPONSE SHOULD be used as the error code"? (Which does raise the question of whether it needs to be a separate error code from H3NOERROR....)
I think a normal transport assumption is that a change of path implies a (potential) loss of congestion state, and that the endpoint should reset the path CC parameters. Transport-ID: “On confirming a peer's ownership of its new address, an endpoint SHOULD immediately reset the congestion controller and round-trip time estimator for the new path.” • Does the "reset" require setting the CC to the initial window value for a connection? I think so. • Why not MUST? Transport-ID: “An endpoint MUST NOT return to the send rate used for the previous path unless it is reasonably sure that the previous send rate is valid for the new path. “ This could therefore be seen as a “significant” departure from conventional approaches considered safe - and extends this to “reasonably sure”. • Is there a rationale for extending this to “reasonably sure”, because this seems bolder than permitted for a new TCP connection. How do people quantify reasonably sure, and why not just in this case grow from the Initial window?
Yes. We should articulate this better though. To allow for pre-existing knowledge, such as stored values.

I think this can be changed to say "unless an endpoint has other knowledge, it MUST reset" (or some such). Fair point. The intent here again was to allow pre-existing knowledge to be used, but I think the wording can be changed to reflect that more explicitly.
Discussed in London: NAME to provide a PR
Re-opening issue. This needs a bit more work.
Change:
3.2. <del> Unless otherwise specified, the RS protects its calls to the AS using any of the signature methods defined by GNAP.  This signing method MUST cover all of the appropriate portions of the HTTP request </del> <ins> Unless otherwise specified, the RS MUST protect its calls to the AS using any of the signature methods defined by GNAP.  This signing method MUST cover all of the appropriate portions of the HTTP request </ins> message, including any body elements, tokens, or headers required for functionality. <del> The AS MAY require an RS to pre-register its keys or could alternatively allow calls from arbitrary keys, in a trust-on-first- use model.  The RS MAY present its keys by reference or by value in the same fashion as a client instance calling the AS in the core protocol of GNAP I-D.ietf-gnap-core-protocol. </del> <ins> The RS MAY present its keys by reference or by value in a similar fashion to a client instance calling the AS in the core protocol of GNAP, described in I-D.ietf-gnap-core-protocol.  In the protocols defined here, this takes the form of the resource server identifying itself using a "key" field or by passing an instance identifier directly. or by reference: The AS MAY require an RS to pre-register its keys or could allow calls from arbitrary keys in a trust-on-first-use model. </ins> 3.3.

Discussion:
Expands discussion of RS authentication, with examples. Re-uses structures from client instance auth used in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 71b0e6f2bdaa5a34903865e3130160be29eefc4b :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Change:
set of allowable protocol features without changing the core implementation. <ins> To control these specialized features, the application can declare its preference - whether the presence of a specific feature is prohibited, should be avoided, can be ignored, is preferred, or is required in the Pre-Establishment phase.  An implementation of a Transport Services API would honor this preference and allow the application to query the availability of each specialized feature after a successful establishment. </ins> 3.3. A Transport Services implementation can select Protocol Stacks based

Discussion:
URL If an application wishes to use a special feature then if might need to adjust itself if that special feature is not applicable to the Connection Object it gets/ gets created for. Should there be no requirement(at least recommendation) on getting this information back? The application can ask a specialized feature in a way that it gets what it wants or the communication MUST fail. In such case the should be a requirement on the application to be specific about it or?
The API solves this in two ways: We have a preference-type that allows the application to explicitly state that it requires/prefers/does-not-care/wants-to-avoid/prohibits each feature. After the establishment, the application can query each feature and gets a boolean back whether it is present or not. Should we add this as a forward reference here or at least hint at the solution?
Hint at the solution sounds like a very good approach to me.
Change:
7.8. <del> Group keys are derived using the HKDF-Extract and HKDF-Expand functions as defined in RFC5869, as well as the functions defined below: </del> <ins> Group keys are derived using the "Extract" and "Expand" functions from the KDF for the group's ciphersuite, as well as the functions defined below: </ins> <del> The Hash function used by HKDF is the ciphersuite hash algorithm. Hash.length is its output length in bytes.  In the below diagram: </del> <ins> The value "KDF.Nh" is the size of an output from "KDF.Extract", in bytes.  In the below diagram: </ins> <del> HKDF-Extract takes its salt argument from the top and its IKM </del> <ins> KDF.Extract takes its salt argument from the top and its IKM </ins> argument from the left <del> Derive-Secret takes its Secret argument from the incoming arrow </del> <ins> DeriveSecret takes its Secret argument from the incoming arrow </ins> When processing a handshake message, a client combines the following information to derive new epoch secrets:

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
partial or even complete replay protection, which could be used to manage replay risk. <del> 3.3. </del> <ins> 3.2. </ins> Because QUIC is encapsulated in UDP, applications using QUIC must deal with short network idle timeouts.  Deployed stateful middleboxes

Discussion:
This cuts a section heading and coalesces a few paragraphs. It adds a point of comparison with TLS 1.3.
Section 3 talks about the challenges of 0-RTT, but seems to ignore that very similar challenges exist when TLS 1.3 Early Data is used over TCP. I think I'd reword this to talk about the similarity, and that while QUIC gives Early Data more visibility, the same cautions and mitigations still apply. (I'd also probably find a more technical title than "Here There Be Dragons," but that's purely stylistic.)
I agree that challenges are similar to TLS1.3 over TCP. However, given this document is scoped to the use of QUIC, I'm not sure what mentioning TCP in this section gets you. I find the section actually quite clear without mentioning anything about TCP. Or did I miss the point you are making?
Otherwise PRs are always welcome! :-)
Change:
supported by all members. Initialize a one-member group with the following initial values <del> (where "0" represents an all-zero vector of size Hash.length): </del> <ins> (where "0" represents an all-zero vector of size KDF.Nh): </ins> Ratchet tree: A tree with a single node, a leaf containing an HPKE public key and credential for the creator

Discussion:
For the record: I asked NAME whether we could just update DeriveTreeSecret so that it always produces octets. But he pointed out that DeriveTreeSecret is also used to produce keys and nonces. Might be something to clean up later.