jiebi/CodeConvo huggingface dataset:
Code change:
Base values are listed below for CSM Options.  These are the values for the Capability and Setting before any Capability and Settings <del> messages sends a modified value. </del> <ins> messages send a modified value. </ins> These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty

Related discussion:
text: NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.
Michel Veillette points out that a peer that wants to use a new connection has an uncertainty whether a CSM message with capability indications will come or not, so it is hard to decide when to send the first request (either based on default capabilities or waiting for the CSM to come in). One way out of having to do arbitrary waits would be to require the exchange of a CSM message (even an option-less one) after connection setup. The burden is very low, as a minimal implementation would just need to send a constant message of 0x00 0xe1 at setup. This requirement could be stated without giving a sequence, effectively allowing both sides to send the initial CSM in parallel, or it could give the listener the opportunity to not send its CSM until the connection opener has sent theirs, trying to avoid the need to answer right away to a connection setup -- this makes it too easy to scan for ports (OK, we also have a default port, and making scanning harder does not by itself provide any security, but it sure makes life a little harder for the attacker). (To avoid deadlock, the connection opener would not have the opportunity to wait sending the CSM.)
+1 ... especially for Maximum-Message-Size. HTTP/2 has a similar flow for SETTINGS during connection including potentially empty settings: URL URL
No objections. I will create a pull request for review by the WG.
Code change:
not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. <ins> If the ICE candidate policy is "relay", as defined in JSEP, ignore the candidate. </ins> Otherwise, resolve the candidate using mDNS.  The ICE agent SHOULD set the unicast-response bit of the corresponding mDNS query message; this minimizes multicast traffic, as the response is

Related discussion:
text: Fixes URL
See URL for details
I added a step where we ignore the candidate in that case. The term 'ignore' should probable be refined as it is used both here and in the context of URL We might want to update ignore in URL context.
LGTM
Code change:
To generate the report, the client begins by sharding its measurement into a sequence of input shares as specified by the VDAF in use.  To <del> encrypt an input share, the client first generates an HPKE RFC9180 context for the aggregator by running </del> <ins> encrypt an input share, the client generates an HPKE RFC9180 ciphertext and encapsulated key for the aggregator by running </ins> <del> where "pk" is the aggregator's public key and "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper).  In general, the info string for computing the HPKE context is suffixed by two bytes, the first of which identifies the role of the sender and the second of which identifies the role of the intended recipient. "enc" is the HPKE encapsulated key and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as where "input_share" is the aggregator's input share and "nonce" and "extensions" are the corresponding fields of "Report".  Clients MUST NOT use the same "enc" for multiple reports. </del> <ins> where "pk" is the aggregator's public key; "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper); "task_id", "nonce", and "extensions" are the corresponding fields of "Report"; and "input_share" is the aggregator's input share. </ins> The leader responds to well-formed requests to "[leader]/upload" with HTTP status code 200 OK and an empty body.  Malformed requests are

Related discussion:
text: For example, if we stuff the context in , then it influences the derivation of the AEAD key; but depending on the AEAD, it might be feasible for an attacker to find a find two keys that decrypt the same ciphertext. (See URL) More analysis will be needed to say for sure whether this weakness in the AEAD amounts to an attack against our protocol. In the meantime, sticking the "context" in seems like a more conservative choice to me.
Given your concern, your approach SGTM. It sounds like this may be a concern worth raising with the folks working on the HPKE spec, given the advice to "use the Setup info parameter for specifying auxiliary authenticated information", but I'm not going to chase this down currently.
So I think there's two tasks for this issue: Move task ID from to Use single-shot APIs for HPKE Anything else?
Yep, I think that's it.
(reopening for now as the fix PR has been reverted temporarily)
Perfect, great work!
Code change:
(request-response). Multiplexing of requests is performed using the QUIC stream <del> abstraction, described in Section 2 of QUIC-TRANSPORT.  Each request and response consumes a single QUIC stream.  Streams are independent </del> <ins> abstraction, described in Section 2 of QUIC-TRANSPORT.  Each request- response pair consumes a single QUIC stream.  Streams are independent </ins> of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams.

Related discussion:
text: Lest some readers get the impression that each request consumes a single QUIC stream and each response consumes a single QUIC stream.
Code change:
If the type is not correct for the current state, processing MUST stop and an error MUST be returned. <ins> The SessionDescription is then checked to ensure that its contents are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in sec.modifying-sdp; otherwise, processing MUST stop and an error MUST be returned. </ins> Next, the SessionDescription is parsed into a data structure, as described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be

Related discussion:
text: In Section 5.4, JSEP says: " The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription." However in Section 5.8, it says: "First, the parsed parameters are checked to ensure that they are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in Section 5.4; otherwise, processing MUST stop and an error MUST be returned." [BA] So is any change to URL unacceptable (e.g. must be byte for byte identical)? Or is the text trying to say that the parsed representation must be the same (e.g. "a=" lines appearing in a different order shouldn't matter)?
I believe the expectation was that the description is entirely immutable. Verifying isomorphism in the face of minor modifications seems like something that is not entirely trivial, and TBH I don't quite understand why it would be needed.
Thanks. PR URL assumes that URL is immutable.
I will update 5.8 accordingly.
Code change:
3.1. <ins> This section outlines how mDNS should be used by ICE agents to conceal local IP addresses.  Naturally, if the ICE agent does not want to conceal its IPs, e.g., if it has a priori knowledge that its addresses are in fact public, this processing is unnecessary. </ins> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows:

Related discussion:
text: Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM
Code change:
be routed to a server instance with more resources available for new connections. <ins> If a server receives a client Initial that can be unprotected but contains an invalid Retry token, it knows the client will not accept another Retry token.  The server can discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client.  A server MAY proceed with the connection without verifying the token, though the server MUST NOT consider the client address validated.  If a server chooses not to proceed with the handshake, it SHOULD immediately close (immediate-close) the connection with an INVALID_TOKEN error. Note that a server has not established any state for the connection at this point and so does not enter the closing period. </ins> A flow showing the use of a Retry packet is shown in fig-retry. 8.1.2.

Related discussion:
text: If the Retry token is known to be invalid by the server, then the server can close the connection with INVALID_TOKEN instead of waiting for a timeout. Came out of discussion of Issue Related to
You need to update the "Transport Error Codes" section too.
Thanks NAME I did that in a subsequent update. Refresh and tell me if it looks correct.
NAME you're missing the section that gives some text to each error code .
NAME do you have a suggestion about what the client should do? Clearly it could start a new connection, but it would't want to do that an unlimited number of times, and it may depend upon whether a TCP fallback is available. Given that, it wasn't clear I should recommend something. And I agree making them distinguishable should be a MUST, as stated in
I think that the best thing we can say is "the connection attempt failed". The first version of the PR strongly suggested that making another connection attempt was the right thing to do, but that gets into lots of difficult questions about identifying why. Given that this is an error that only happens if a Retry is spoofed, then I think that all we can say is: !
When the server receives a Token that is corrupted, it may want to close the connection quickly. This issue suggests adding a new error code to indicate the token is corrupted, INVALID_TOKEN.
This is - I believe - a design issue. The PR seems to have approval, we just need the appropriate process run.
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
Code change:
be routed to a server instance with more resources available for new connections. <ins> If a server receives a client Initial that can be unprotected but contains an invalid Retry token, it knows the client will not accept another Retry token.  The server can discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client.  A server MAY proceed with the connection without verifying the token, though the server MUST NOT consider the client address validated.  If a server chooses not to proceed with the handshake, it SHOULD immediately close (immediate-close) the connection with an INVALID_TOKEN error. Note that a server has not established any state for the connection at this point and so does not enter the closing period. </ins> A flow showing the use of a Retry packet is shown in fig-retry. 8.1.2.

Related discussion:
text: Depending how the server distinguishes them, a change of method / confusion about what server you're sending it to could make you appear to be presenting a Retry token instead of a regular token. This error code enables the client to recover and retry quickly, but there's no language about what the client should do when it receives the code.Rereading the changes, I have the following editorial suggestion.
Code change:
the lower bound and which is the upper bound: The slice expression selects elements with indices between the lower <del> and upper bounds.  In the following pseudocode, the "a(i)" construct expresses the 0-based indexing operation on the underlying array. </del> <ins> and upper bounds.  In the following pseudocode, "a(i)" is the "i+1"th element of the array "a" (i.e., "a(0)" is the first element, "a(1)" the second, and so forth). </ins> When "step = 0", no elements are selected and the result array is empty.

Related discussion:
text: Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.
Code change:
14.1. A client MUST expand the payload of all UDP datagrams carrying <del> Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </del> <ins> Initial packets to at least the smallest allowed maximum datagram size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </ins> datagram of this size ensures that the network path from the client to the server supports a reasonable Path Maximum Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification

Related discussion:
text: Addresses . NAME points out in that we use in the transport draft and in the recovery draft. In reading carefully, I realized that in the transport draft was actually historical, and is the more appropriate term. This is an entirely editorial PR, and it's largely simple changes, despite the fact that it looks a bit big. It is a bit subtle though. Sorry about that.
This issue will list a number of minor editorial things that should be checked and likely addressed with some editorial fixes: Section 5.3: "These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of [QUIC-TRANSPORT]." This text implies that the computation of the delay is described in Section 19.3 of QUIC-TRANSPORT. However, I don't think it is described the calculation, only the definition of the field. Please reformulate to imply only field definition not calculation. Section 5.3: "On the first RTT sample for the network path, that sample is used as rttsample. This ensures that the first measurement erases the history of any persisted or default values." I think this intended to cover cases where path changes are detected. But it is not well expressed. Does this need a reformulation and a reference into QUIC-TRANSPORT where it states when such a reset should occur? Section 6.1: "Either its packet number is kPacketThreshold smaller than an acknowledged packet" Nitpicking, assuming no PN gaps in transmission. Does that need a note? Section 6.2.4: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces." This last part, I assume intended to generate additional datagrams to prevent single loss to impact. However, due to coalescing this is unclear in this context. Section 7: "Endpoints can unilaterally choose a different algorithm to use, such as Cubic ([RFC8312])." I think this sentence should be explicit that in needs to be sender-based algorithms. I think we need to have the requirement on performing congestion control on the sender unless there has been explicit agreement with the receiver that they will do it.
Code change:
14.1. A client MUST expand the payload of all UDP datagrams carrying <del> Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </del> <ins> Initial packets to at least the smallest allowed maximum datagram size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </ins> datagram of this size ensures that the network path from the client to the server supports a reasonable Path Maximum Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification

Related discussion:
text: Section 7.2: "Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (maxdatagramsize), limited to the larger of 14720 bytes or twice the maximum datagram size." "maximum datagram size" is not used in Transport there need to be alignment here of what name to use. Transport has Maximum Packet Size, which appears to match the definition in the appendix of maxdatagram_size.
Thanks for your careful review, NAME -- these are good finds! I've addressed your comments below and in . I'll address point 6 in a separate PR. Section 19.3 has the following text, which does tell how to compute acknowledgement delay from the ACK Delay field: I've replaced "computed" with "decoded" in the recovery document to make it clearer. Coalescing applies to packets, not to datagrams. We've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing. I think the text is pretty clear on this: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets". I've added "sender-side" to make the controller more explicit. To your point about making this a sender requirement, that is covered in the transport doc (end of ):
Based on and , labeling this as "editorial"
I think these issues are resolved once the two PRs are completely ready.
Except for the one erronous exchange of packet this looks good.
Code change:
presentation and wire format) is a relative URI Template RFC6570, normally starting with "/".  If the "alpn" SvcParamKey indicates support for HTTP, clients MAY construct a DNS over HTTPS URI Template <del> by combining the prefix "https://", the service name, the port from the "port" key if present, and the "dohpath" value.  (The DNS service's original port number MUST NOT be used.) </del> <ins> by combining the prefix "https://", the authentication name, the port from the "port" key if present, and the "dohpath" value.  (The binding authority's port number MUST NOT be used.) </ins> Clients SHOULD NOT query for any "HTTPS" RRs when using the constructed URI Template.  Instead, the SvcParams and address records

Related discussion:
text: This should help with the case in DDR. See URL
Much better. Thanks for indulging me.
Code change:
9.1. A file of this type contains one or more certificates encoded with <del> the PEM textual encoding, according to RFC 7468 RFC7468.  In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> the PEM textual encoding, according to RFC 7468 RFC7468.  The textual encoding of certificates in this file MUST use the strict encoding and MUST NOT include explanatory text.  The ABNF for this format is as follows, where "stricttextualmsg" and "eol" are as defined in Section 3 of RFC 7468: In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> The "Media Types" registry should be updated with the following additional value:

Related discussion:
text: In addition to forbidding explanatory text, this PR restricts the PEM-certificate-chain structure to the "strict" production defined in RFC 7468, Figure 3.
s/Figure 3 of RFC 7468/Section 3 of RFC 7468/