jiebi/CodeConvo huggingface dataset:
Code change:
layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. <ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc.  The initial secret is simply a string of

Related discussion:
text: Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).
Code change:
to the PA protocol: The helper handles each sub-request "PAAggregateSubReq" as follows. <del> It first checks that checks that "PAAggregateSubReq.proto == PAParam.proto".  If not, it aborts and alerts the leader with "incorrect protocol for sub-request".  Otherwise, it computes the HPKE context as where "sk" is its HPKE key and computes the body of the "PAAggregateSubResp".  It then updates its state according to the PA protocol.  After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </del> <ins> It first looks up the HPKE config and corresponding secret key associated with "helper_share.config_id".  If not found, then the sub-response consists of an "unrecognized config" alert.  [TODO: We'll want to be more precise about what this means.  See issue#57.] Next, it attempts to decrypt the payload with the following procedure: where "sk" is the HPKE secret key.  If decryption fails, then the sub-response consists of a "decryption error" alert.  [See issue#57.] Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PA protocol. After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </ins> 3.4.2.1.1.

Related discussion:
text: For each , do: Choose blinding factor from at random. Let . Set . Derive field element from (e.g., seed a PRNG with and map the output to a field element by rejection sampling on chunks of the output). Generate the proof using and . Split into shares . For each send to the -th verifier.
Yes, this looks right to me!
As of URL, the upload start request no longer exists. When we're ready to specify Prio, we'll want to include the Fiat-Shamir approach for protocols that use joint randomness. I've noted this and am closing the issue.
Code change:
configured not to perform a cookie exchange.  The default SHOULD be that the exchange is performed, however.  In addition, the server MAY choose not to do a cookie exchange when a session is resumed or, more <del> generically, when the DTLS handshake uses a PSK-based key exchange. Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.  A server SHOULD limit the amount of data it sends toward a client address before it verifies that the client is able to receive data at that address.  A client address is valid after a cookie exchange or handshake completion.  A server MAY apply a higher limit based on heuristics, such as if the client uses the same IP address as the connection on which the cookie was created.  Clients MUST be prepared to do a cookie exchange with every handshake. </del> <ins> generically, when the DTLS handshake uses a PSK-based key exchange and the IP address matches one associated with the PSK.  Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.  A server SHOULD limit the amount of data it sends toward a client address to three times the amount of data sent by the client before it verifies that the client is able to receive data at that address.  A client address is valid after a cookie exchange or handshake completion.  Clients MUST be prepared to do a cookie exchange with every handshake.  Note that cookies are only valid for the existing handshake and cannot be stored for future handshakes. </ins> If a server receives a ClientHello with an invalid cookie, it MUST terminate the handshake with an "illegal_parameter" alert.  This

Related discussion:
text: The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL
Code change:
9. <del> Running DNS over https:// relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS this protocol expects to use current best practices for secure </del> <ins> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure </ins> transport. Session level encryption has well known weaknesses with respect to

Related discussion:
text: I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.
Code change:
related to the JSON literals "true" and "false" and have no direct syntactical representation in JSONPath. <del> "NodesType" is an abstraction of a "filter-path" (which appears in a test expression or as a function argument).  Members of </del> <ins> "NodesType" is an abstraction of a "filter-query" (which appears in a test expression or as a function argument).  Members of </ins> "NodesType" have no direct syntactical representation in JSONPath. The abstract instances above can be obtained from the concrete

Related discussion:
text: XPath terminology is a bit weird, because XPath has a somewhat competing standard XQuery... XPath is based on DSSSL, which had a complex expression language for building paths in the XML trees that was based on the Scheme language. (Which is the experience that makes me hesitant just jumping headlong into another expression language...)
LGTM with that change. Thanks!
Code change:
meanings. Readers are expected to be familiar with the terms and concepts <del> described in RFC7252 and RFC7641.  Readers are also expected to be familiar with RFC7049 and understand I-D.greevenbosch-appsawg-cbor- cddl.  Terminology for constrained environments, such as "constrained device", "constrained-node network", is defined in RFC7228. </del> <ins> described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE I-D.ietf-cose-msg, CBOR RFC7049, CDDL I-D.greevenbosch-appsawg-cbor- cddl, and constrained environments RFC7228. </ins> 2.

Related discussion:
text: UTF-8 über alles.
Abstract: Explain that OSCOAP works across intermediaries and over any layer.Intro: Explain that OSCOAP works for Observe and Blockwise.Intro: Move details on replay and freshness to some other section.Terminology: Explain the references and add COSE.
Code change:
old key.  The "outer" JWS represents the current account holder's assent to this request. <del> On receiving keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </del> <ins> On receiving a keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </ins> Validate the POST request belongs to a currently active account, as described in message-transport.

Related discussion:
text: Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:
Code change:
of the following octets.  Note that the first two octets indicate the extension type ("supported_groups" extension): <ins> As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client.  If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences.  Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake, but MAY use the information learned from a successfully completed handshake to change what groups they offer to a server in subsequent connections. </ins> [[TODO: IANA Considerations.]] 6.3.2.3.

Related discussion:
text: You'll also need to update the last paragraph of the MTI Extensions section (currently section 8.2). Now that we're going to be down to only one client-only extension defined in this document, that whole paragraph can probably be cut in favor of a one-off note in the remaining extension's section (signature_algorithms will be the last).
So that the clients can learn about what groups a server supports. The idea here is to allow a client to offer P256 but then learn that a server supports 25519 for next time without the server having to reject.
Code change:
The status of the Connection, which can be one of the following: Establishing, Established, Closing, or Closed. <ins> Whether the connection can be used to send data.  A connection can not be used for sending if the connection was created unidirectional receive only or if a message with the final property was sent over this connection. Whether the connection can be used to receive data.  A connection can not be used for reading if the connection was created unidirectional send only or if a message with the final property received was received.  The latter is only supported by certain transport protocols, e.g., by TCP as half-closed connection. </ins> Transport Features of the protocols that conform to the Required and Prohibited Transport Preferences, which might be selected by the transport system during Establishment.  These features

Related discussion:
text: As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far.
Code change:
The status of the Connection, which can be one of the following: Establishing, Established, Closing, or Closed. <ins> Whether the connection can be used to send data.  A connection can not be used for sending if the connection was created unidirectional receive only or if a message with the final property was sent over this connection. Whether the connection can be used to receive data.  A connection can not be used for reading if the connection was created unidirectional send only or if a message with the final property received was received.  The latter is only supported by certain transport protocols, e.g., by TCP as half-closed connection. </ins> Transport Features of the protocols that conform to the Required and Prohibited Transport Preferences, which might be selected by the transport system during Establishment.  These features

Related discussion:
text: We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.
Code change:
implementation level only -- they do not influence the result of the evaluation.) <del> A function argument is a "filter-path" or a "comparable". </del> <ins> A function argument is a "filter-query" or a "comparable". </ins> According to filter-selector, a "function-expr" is valid as a <del> "filter-path" or a "comparable". </del> <ins> "filter-query" or a "comparable". </ins> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath

Related discussion:
text: XPath terminology is a bit weird, because XPath has a somewhat competing standard XQuery... XPath is based on DSSSL, which had a complex expression language for building paths in the XML trees that was based on the Scheme language. (Which is the experience that makes me hesitant just jumping headlong into another expression language...)
LGTM with that change. Thanks!
Code change:
packets arrive.  If a peer could timeout within an Probe Timeout (PTO, see Section 6.2.2 of QUIC-RECOVERY), it is advisable to test for liveness before sending any data that cannot be retried safely. <ins> Note that it is likely that only applications or application protocols will know what information can be retried. </ins> 10.3.

Related discussion:
text: What data can and cannot be retried safely?
That's not something that QUIC knows. HTTP does though. As advice, I don't think that this needs much more expansion, but I'd be happy to take a PR.
I'm not so sure this is a HTTP-only issue. Unlike TLS 1.3, there is QUIC data being sent under encryption, and that might have side effects.
LGTM, one nit. ("using applications" is fine, it's just a bit awkward.)
Code change:
simplifications are available.  Instead of being configured with (or discovering) the service registration domain, the (proposed) special- use domain name (see RFC6761) "default.service.arpa" is used.  The <del> details of how SRP server(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </del> <ins> details of how SRP registrar(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </ins> mechanism here. <del> SRP clients on constrained networks are expected to receive from the network a list of SRP servers with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP server addresses.  It is the responsibility of the SRP server supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </del> <ins> SRP requestors on constrained networks are expected to receive from the network a list of SRP registrars with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP registrar addresses.  It is the responsibility of the SRP registrar supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </ins> 2.1.3.

Related discussion:
text: This is part of the previous pull request, but I missed it because it was interleaved with some unrelated changes.
Code change:
acknowledgement is received that establishes loss or delivery of packets. <del> When an ACK frame is received that establishes loss after a threshold number of consecutive PTOs (pto_count is more than kPersistentCongestionThreshold, see cc-consts-of-interest), the network is considered to be experiencing persistent congestion, and the sender's congestion window MUST be reduced to the minimum congestion window (kMinimumWindow).  This response of collapsing the congestion window on persistent congestion is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. </del> <ins> When an ACK frame is received that establishes loss of all in-flight packets sent prior to a threshold number of consecutive PTOs (pto_count is more than kPersistentCongestionThreshold, see cc- consts-of-interest), the network is considered to be experiencing persistent congestion, and the sender's congestion window MUST be reduced to the minimum congestion window (kMinimumWindow).  This response of collapsing the congestion window on persistent congestion is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. </ins> 7.6.

Related discussion:
text: The implication here is that any packet that was received but not acked can cause the RTO to be labeled spurious, even if there were more packets that were in fact lost. This is not always right. Consider the following example: Packets 5, 6, 7 are sent Packet 5 is received, but 6 and 7 are dropped Ack of 5 is dropped TLPs (packets 8 and 9) are sent and dropped RTO (packet 10) is sent and received ACK acks 10 and 5 Since 5 was sent prior to RTO, RTO is marked spurious. A crisp definition of spurious RTO may be useful to continue. Here's what I think is sensible: A spurious RTO is an unnecessary RTO. If the RTO timer had not gone off, things would have been fine. Based on this definition, clearly the RTO was necessary in the example, and therefore not spurious. We need to change the mechanism for detecting spurious RTOs, and I'll propose the following. An RTO is spurious if an ack is received after the RTO fires that acks only packets sent prior to the RTO. In other words, RTO is spurious if ack is received after the RTO, and (instead of , as the draft currently states).
This was recently changed because Lars ran into an issue() where the RTO'd packet was acknowledged for the first time in the same ACK as the pre-RTO packets. In that case, I think it was due to an overly aggressive MinRTO and some pretty coarse grained timers, but I think we want to declare that RTO spurious, since everything would have been fine if it hadn't been sent?
NAME : does not change the semantics substantively of what was in the draft. The intent was always to declare spurious RTO if (packet prior to RTO was newly acked). I'm proposing that we change that to (no packet sent after RTO was newly acked).
In light of , I think this is OBE?
Yes, this is OBE. Closing.