jiebi/CodeConvo huggingface dataset:
Change:
each such Connection must be established separately.  Changes to the parameters of a Preconnection entangled with a Preconnection from which a Connection has already been established will fail.  Calling <del> Clone on a Preconnection may be taken by the system an implicit sign that protocol stacks supporting efficient connection group usage are preferred by the application. </del> <ins> Clone on a Preconnection may be taken by the system an implicit signal that protocol stacks supporting multiplexed connections for efficient connection grouping are preferred by the application. </ins> There is only one Protocol Property that is not entangled, i.e., it is a separate per-Connection Property for individual Connections in

Discussion:
The API document says: I'm not sure I follow this. The text doesn't seem to match the option name: it isn't saying use connection groups efficiently or not, it's specifying whether connection groups can be used at all. It's also not clear why prioritisation is given as an example. Would it be clearer written something more like the following?
yep. Although you still have to explicitly entangle connections by cloning them if you want them to be guaranteed to be within a connection group.
URL makes me question why we need this parameter?
To explicitly prefer multistreaming protocols during selection, because you wrote your app to clone connections instead of cloning preconnections.
(see )
Change:
generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". </del> <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". </ins> In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer:

Discussion:
says: The string is not registered in . Presumably, this text should say .
Opened PR .
Fixed in
Change:
Each m= section, provided it is not being bundled into another m= section, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Otherwise, it MUST use the same <del> ICE credentials and candidates that were used in the m= section that it is being bundled into.  Note that this means that for offers, any m= sections which are not bundle-only MUST have unique ICE credentials and candidates, since it is possible that the answerer will accept them without bundling them. </del> <ins> ICE credentials and candidates as the m= section into which it is being bundled.  Note that this means that for offers, any m= sections which are not bundle-only MUST have unique ICE credentials and candidates, since it is possible that the answerer will accept them without bundling them. </ins> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they <del> MUST all have the same RFC4572fingerprint value, or this value MUST </del> <ins> MUST all have the same RFC4572 fingerprint value, or this value MUST </ins> be a session-level attribute. Each m= section should be generated as specified in RFC4566,

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
field.  A DNS forwarder which already acts as a completely blind forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows <del> the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients of the unencrypted resolver to use the SVCB information opportunistically. </del> <ins> that the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients of the unencrypted resolver to use the SVCB information opportunistically. </ins> Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR

Discussion:
Yeah, we want the trailing dot in official DNS records, but I think it's unnecessary elsewhere (IMO).
I assume the trailing dot is unnecessary for domain names in the non-example text because it can be more human friendly and not exact format? Assuming yes to that, LGTM
Change:
4.3. <ins> Issue 2, Original text: Issue 2, Proposed replacement text: </ins> The above diagram shows a simple flow of messages through a DMARC- aware system.  Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to

Discussion:
Proposed updated ASCII art for mail flow. Proposed stripped down description of ASCII art. Proposed new text for Domain Owner actions.
Change:
versions of TLS will increase the number of PSKs derived from an external PSK. <ins> ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a channel binding for the deriving protocols RFC5056.  If any secrets are agreed in earlier protocols they SHOULD be included in ImportedIdentity.context CCB. </ins> A unique and imported PSK (IPSK) with base key 'ipskx' bound to this identity is then computed as follows:

Discussion:
To make external psk importers more featureful it makes sense to take advantage of the HKDF already in use. By providing a field for extra context we can avoid protocol layering attacks. For example this change allows us to securely bind one TLS session to another, providing layered context.
See: URL
This was addressed with the slot via and . Closing!
Thanks! This is much more understandable than the previous PR. :-)LGTM with the suggested name change!
Change:
connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 13. </del> <ins> 14. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
The requested value of the notAfter field in the certificate, in the date format defined in RFC3339. <ins> The error that occurred while processing the order, if any.  This field is structured as a problem document RFC7807. </ins> For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see identifier-authorization).  For final orders, the authorizations

Discussion:
Removes dnssec error type for a broader "dns" error type. It's very hard to split out dnssec errors from regular dns problems, because recursive resolvers can only return SERVFAIL. The new dns error type also subsumes "unknownHost." Introduces a new "incorrectResponse" error type for cases where connection and request were both successful, but the content didn't match. This also puts the validation-related errors at the bottom of the table so they can be viewed in context with each other. Introduces an error field for orders. Orders can fail independent of authorizations because of last-minute CAA checking, failure to submit to CT logs, timeouts, etc.
Change:
Further, if UDP traffic is desired to be throttled, it is recommended to block individual QUIC flows entirely rather than dropping packets indiscriminately.  When the handshake is blocked, QUIC-capable <del> applications may fail over to TCP.  However, blocking a random </del> <ins> applications may fall back to TCP.  However, blocking a random </ins> fraction of QUIC packets across 4-tuples will allow many QUIC <del> handshakes to complete, preventing a TCP failover, but these </del> <ins> handshakes to complete, preventing TCP fallback, but these </ins> connections will suffer from severe packet loss (see also sec- filtering).  Therefore, UDP throttling should be realized by per-flow policing, as opposed to per-packet policing.  Note that this per-flow

Discussion:
Per Al Morton's opsdir review, review the use of these three terms and correct where appropriate.
Change:
ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the HelloRetryRequest.  If either of these values differ, the client MUST <del> abort the connection with a fatal "handshake_failure" alert. </del> <ins> abort the connection with a fatal "illegal_parameter" alert. </ins> 4.2.

Discussion:
Noticed these while reviewing the negotiation PR: handshakefailure means "the sender was unable to negotiate an acceptable set of security parameters given the options available", but these are all protocol errors that should only occur with a buggy server. Switch them to more appropriate ones: If the HelloRetryRequest makes no sense, it is an illegalparameter. If we get a second HelloRetryRequest, it's an unexpectedmessage (the client is in a state where it expects a ServerHello and will likely just fall through to the generic message-mismatch codepath). If HelloRetryRequest and ServerHello are inconsistent, it is an illegalparameter. If an anonymous server sends a CertificateRequest, it's an unexpected_message (this too will likely use the generic message-mismatch codepath).
Change:
5.2. <del> The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540. </del> <ins> HTTP/2 RFC7540 is the minimum RECOMMENDED version of HTTP for use with DOH. </ins> The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs

Discussion:
what motivates this? Is it just the word minimum? It changes from normative to non-normative which is a pretty big change and doesn't reflect, imo, the consensus we had in singapore.
I see NAME s mail now - but I think its in the rough at least with the current text being too strong (rewording welcome). There was considerable discussion about h2 really being necessary to make this work well - there are just practical considerations to being able to always deploy that.. therefore SHOULD (and the reason you wouldn't is its impractical to know or enforce version levels across a chain of infrastructure).
This sounds significant enough to be discussed on the list.
Change:
prevents additional reports from being aggregated after its batch has already been collected. <del> Check if the report has already been aggregated.  If this check fails, the input share is marked as invalid with the error "report-replayed".  This is the case if the report was used in a previous aggregate request and is therefore a replay.  An aggregator may also choose to mark an input share as invalid with the error "report-dropped" under the conditions prescribed in anti-replay. </del> <ins> Check if the report has already been aggregated with this aggregation parameter.  If this check fails, the input share is marked as invalid with the error "report-replayed".  This is the case if the report was used in a previous aggregate request and is therefore a replay.  An aggregator may also choose to mark an input share as invalid with the error "report-dropped" under the conditions prescribed in anti-replay. </ins> If both checks succeed, the input share is not marked as invalid.

Discussion:
Previously, report-replayed would be returned if the same client report was aggregated more than once. However, some VDAFs (e.g. poplar1) will require repeatedly aggregating a given client report with varying aggregation parameters. This commit relaxes the condition on which report-replayed will be returned to allow aggregating the same client report multiple times, as long as each aggregation has a distinct aggregation parameter.
This is odd because the aggregation parameter is opaque and it's not clear if any change to it should allow aggregating a report again. For example, if aggregation is allowed only once for privacy reasons but some kind of shared random number is needed as agg_param this will be an issue. I think checking if another aggregation is allowed has to be done depending on the VDAF and the task.
There is a separate check, under the section "Validating Batch Parameters", that each report is used in at most aggregate shares. This should be set to 1 for Prio3 and VDAFs like you describe. If for a task is 1, then the present change will make no difference, but if for a task is greater than one, we need this change in order to allow that second batch.
Currently, the report share error is returned "if the report has already been aggregated" (). Some VDAFs, like , will require repeatedly aggregating the same client reports with a varying aggregation parameter. I think the specification language would effectively block this use-case currently. I think the fix is to return a error if the report has already been aggregated with the same aggregation parameter. Note that this change would not allow a malicious leader to potentially aggregate a different set of reports with a different aggregation parameter: the existing error would be returned if a client attempted to upload another report after the first collection attempt. (Given the small size of the proposed fix, I'll send a PR shortly, but discussion on this issue/the WG mailing list takes precedence -- I'll update the PR to follow any changes from discussion.)
Thanks NAME -- this change LGTM.
Change:
The value of the Destination Connection ID field from the first Initial packet sent by the client.  This transport parameter is <del> only sent by a server.  A server MUST include the original_connection_id transport parameter if it sent a Retry packet. </del> <ins> only sent by a server.  This is the same value sent in the "Original Destination Connection ID" field of a Retry packet (see packet-retry).  A server MUST include the original_connection_id transport parameter if it sent a Retry packet. </ins> The idle timeout is a value in milliseconds that is encoded as an integer; see (idle-timeout).  If this parameter is absent or zero

Discussion:
Note that may want to change the phrasing of the ODCID field, depending on which PR lands first.
End of section 18, transport It seems the term is "initial connection ID" not "original connection ID", at least I can't find it defined anywhere in transport.
Two different things, but you're probably right that they should both be explicitly defined: The "Original destination connection ID" is the DCID used in the client's very first Initial packet. If the server responded with a Retry, the server needs to: include the ODCID in the Retry packet to verify the Retry packet came from something on-path include the ODCID in the eventual handshake's transport parameters to verify that the Retry packet originated from the server or something cooperating with it, not a MITM The "Initial connection ID" is the DCID used in the client's Initial packet to which the server responded with an Initial. This CID determines the keys used for Initial packets throughout the handshake. (But see .) This CID might have been server-chosen (from a Retry) or client-chosen (no Retry). If there's no Retry packet, they refer to the same CID, but I don't think there's a reference to the ODCID outside the context of a Retry.
I think that we already concluded this in .
This is a separate issue, about definition of these terms; is about whether these need to be separate concepts depending on the outcome of other issues. NAME notes that the term "original connection ID" appears only to say that a client MUST NOT send one, and that literal string appears nowhere else in the document except the changelog. This refers to the transport parameter , whose definition matches the description of the "Original Destination Connection ID" field in Retry and references Retry, but doesn't use that term. I'd suggest using the names of the prohibited TPs in stating the client restriction, and referencing the "Original Destination Connection ID" field by name from the TP definition.
Change:
Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senmlc </ins> Macintosh file type code(s): none

Discussion:
Why is there no sensml+cbor? (I can't really find where sensml+json is actually defined.) Is that really TODO?
sensml+json is defined in "Multiple Datapoints". Perhaps could be improved. That TODO was fixed in URL
That is an example, no? Where is the definition?
(In CBOR, SensML would just be a CBOR sequence. No need even for an array around that.) See also RFC 7464...
Change:
[11] mailto:webtransport@ietf.org <ins> [12] https://www.iana.org/assignments/http-fields </ins> Index P

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:
4.1.4. As keys for new encryption levels become available, TLS provides QUIC <del> with those keys.  Separately, as TLS starts using keys at a given encryption level, TLS indicates to QUIC that it is now reading or writing with keys at that encryption level.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </del> <ins> with those keys.  Separately, as keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </ins> TLS provides QUIC with three items as a new encryption level becomes available:

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:
Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages. <del> 12. </del> <ins> 10. Application data messages are carried by the record layer and are fragmented and encrypted based on the current connection state.  The messages are treated as transparent data to the record layer. 11. </ins> Security issues are discussed primarily in I-D.ietf-tls-tls13.

Discussion:
This pull request aims to address the open issues regarding sequence number encryption. The approach chosen follows the design used in QUIC.