jiebi/CodeConvo huggingface dataset:
Change:
defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on DPLPMTUD.  In this scenario, the proxy SHOULD drop the UDP payload <del> and send an ICMP "Packet Too Big" message to the target ICMP6. </del> <ins> and send an ICMP "Packet Too Big" message to the target, see ICMP6. </ins> 6.2.

Discussion:
With the CONNECT UDP, a proxy will send and receive UDP datagrams on behalf of a client. However, in addition to these UDP datagrams, it could also receive ICMP messages. The current draft does not discuss how these ICMP messages should be handled by a proxy and how they would need to be conveyed to the client. It probably makes sense to at least discuss how ICMP destination/network/port unreachable should be handled by the proxy (ignore, terminate the HTTP connection, ...)
I agree. I'm not yet sure what the best solution is (closing the stream on port unreachable would improve reliability but does introduce a way for an attacker to deny service) but we should figure that out and provide guidance in the doc.
FWIW, the way TURN handles this is by having a way for the server to forward ICMP indications. URL Obviously, in order to have this in MASQUE we would need to have some sort of type indicator in the datagram.
I do want the relevant information in the ICMP to make it to the client. However, ICMP falls into the asynchronous information that is not directly associated with a forwarded packet. It can clearly be a forwarded packet per EKR's suggestion. We have other cases where we have information that is related to the associated packet, for example ECN. So I think this there is an important high level design choice here that we need to sorted out. I think for the general extensibility lets consider a content identifier so that just UDP payloads can be separated from additional types with additional fields.
Change:
types. A QUIC endpoint MUST NOT reuse a packet number within the same packet <del> number space in one connection (that is, under the same cryptographic keys).  If the packet number for sending reaches 2^62 - 1, the sender MUST close the connection without sending a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send a Stateless Reset (stateless-reset) in response to further packets that it receives. </del> <ins> number space in one connection.  If the packet number for sending reaches 2^62 - 1, the sender MUST close the connection without sending a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send a Stateless Reset (stateless-reset) in response to further packets that it receives. </ins> A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet

Discussion:
The deleted parenthetical is not accurate, and is unnecessary: 0-RTT and 1-RTT with various key phases share a PN space without sharing keys. I prefer the MUST NOT in coalescing, but if there are objections I can revert it.
Thanks Martin.
All good apart from the MUST NOT. I'm with Martin -- everything else looks fine.
Change:
"active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in <del> RFC5761, Section 5.1.1. </del> <ins> RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5.

Discussion:
Justin, this isn't done, but PTAL and see if you think it's going in the right direction.
looks on right path to me
My only issue with this is what happens if you get an offer that does not do mux, I think it should be accepted regardless of what this is set to. I think this should be purely about what is generated in offer. Other than that it looks good.
We should discuss this on today's call. Justin and I spent a while on it last time and one of the relevant arguments was consistency. Specifically, say you have two endpoints, one of which is old (i.e., pre-WebRTC) and doesn't support mux at all and the other of which is set to "require", i.e., only do mux. With the current text, any attempt between these two to communicate will fail. If you only apply these polices to the offer, however: If the old endpoint is the offerer, then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed. If the new endpoint is the offerer, then it will only provide mux candidates and the call will fail in a fairly ugly fashion. The point being that the current text allows you to fail fast.
lgtm
Push -f due to rebase screwup. Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set "require". In the interest of landing the rest of this, I have added an issue and an open issue section in the draft. URL Cullen, Justin, if this is acceptable LMK and I will merge this PR in.
This seems fine to me - good topic to discuss in Dallas, if we are still of two minds at that point.
NAME can you confirm this matches your expectations?
LGTM and this open issue is not a huge deal one way or the other
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed
Change:
determine whether to use one address or the other. Each component has an ID assigned to it, called the component ID. <del> For RTP-based media data streams, unless RTCP is multiplexed in the same port with RTP, the RTP itself has a component ID of 1, and RTCP a component ID of 2.  If an agent is using RTCP without multiplexing, </del> <ins> For RTP/RTCP data streams, unless RTCP is multiplexed in the same port with RTP, the RTP itself has a component ID of 1, and RTCP a component ID of 2.  If an agent is using RTCP without multiplexing, </ins> it MUST obtain candidates for it.  However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used.

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
status 200 and an empty body.  Malformed requests are handled as described in pa-error-common-aborts. <ins> 3.3.3. Each PAUploadReq carries a list of extensions that clients may use to convey additional, authenticated information in the report.  Each extension is a tag-length encoded value of the following form: "extension_type" indicates the type of extension, and "extension_data" contains information specific to the extension. </ins> 3.4. [TODO: Decide if and how the collector's request is authenticated.]

Discussion:
One possible extension would be an opaque blob to carry client attestation information (for ), if desired. The current set is empty, but I suspect we'll need freedom to extend here as this gets used without totally changing the protocol version. If folks are generally supportive of this, it should probably land after , which touches and renames PDAUploadReq to PDAReport.
Both (1) and (2) are external to the protocol. The purpose of extensions is to allow whatever mechanism exists for addressing them to be bound to the report, as is done here. This is done in the change. This is not meant to close the attestation issue. It's meant to give us the mechanics to address it later.
Right you are. What threw me off was the following statement: The "then these extensions are required to be echoed..." makes it sound as if they're not echoed, which they are. I'm happy with this PR modulo fixing this statement.
Change:
1.1. <del> The following terms are used throughout this document. Server: A service that provides the server-side functionality required by the protocol documented here (typically denoted S). Client: An entity that seeks authorization from a server that supports interactions in the Privacy Pass protocol (typically denoted C). Key: The secret key used by the Server for authorizing client data. Commitment: Alternative name for Server's public key corresponding to the secret key that they hold. </del> <ins> We use the same definition of Server and Client that is used in draft-davidson-pp-protocol and draft-davidson-pp-architecture. </ins> We assume that all protocol messages are encoded into raw byte format before being sent.  We use the TLS presentation language RFC8446 to

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()
Change:
10.3. <ins> During the period in which there are multiple deployed configuration IDs (see config-rotation), there is a slight increase in linkability. The server space is effectively divided into segments with CIDs that have different config rotation bits.  Entities that manage servers SHOULD strive to minimize these periods by quickly deploying new configurations across the server pool. 10.4. </ins> A simple deployment of QUIC-LB in a cloud provider might use the same global QUIC-LB configuration across all its load balancers that route to customer servers.  An attacker could then simply become a

Discussion:
Erik Fuller points out via email: He's right. We should just call it a configuration ID and be clearer on what's what.
Change:
Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with <del> DNS queries.  Sections 10.6 (Compression) and 10.7 (Padding) of RFC7540 provide some further advice on mitigations within an HTTP/2 context. </del> <ins> DNS queries.  HTTP/2 provides further advice about the use of compression (Section 10.6 of RFC7540) and padding (Section 10.7 of RFC7540). </ins> The HTTPS connection provides transport security for the interaction between the DNS API server and client, but does not inherently ensure

Discussion:
In section 9 of DOH, it makes the following references: This isn't one of the formats that the tools process will convert into deep links. Instead, the "10.6" becomes a link to section 10.6 of DOH (which doesn't exist), while 10.7 doesn't become a link at all.
thanks. ugh.
HTTP/2 provides further advice about the use of compression (see Section 10.6 of [RFC7540]) and padding (Section 10.7 of [RFC7540]). That removes the "mitigations" word.
Fixed in PR
Change:
stream.  Receipt of a second instance of either stream type MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR. <del> These streams MUST NOT be closed.  Closure of either unidirectional stream type MUST be treated as a connection error of type H3_CLOSED_CRITICAL_STREAM. </del> <ins> The sender MUST NOT close either of these streams, and the receiver MUST NOT request that the sender close either of these streams. Closure of either unidirectional stream type MUST be treated as a connection error of type H3_CLOSED_CRITICAL_STREAM. </ins> An endpoint MAY avoid creating an encoder stream if it will not be used (for example, if its encoder does not wish to use the dynamic

Discussion:
builds on .
URL stream type MUST be treated as a connection error of type H3CLOSEDCRITICALSTREAM. I'd like to clarify that whether this effectively says that receiver is not allowed to send STOPSENDING. STOPSENDING is elicit RESETSTREAM that closes a stream. MUST send a RESETSTREAM frame if the stream is in the "Ready" or "Send" state. STOPSENDING itself does not close a stream, but it is an action to request a closure. I found in interop runner test, one implementation sends STOPSENDING to QPACK streams. My implementation sends RESETSTREAM when it is received as mandated by spec, and upon stream closure, the connection is closed because QPACK streams are closed, then the test fails. HTTP draft explicitly says that requesting closure for the control stream is prohibited: request that the sender close the control stream. It would be nice to add the similar statement to QPACK streams.
It's super-late in the process, but maybe the editors can see a way to squeeze an editorial change in.
Thanks Tatsuhiro. I agree, IMO the intention was always for consistent treatment of open control streams and open qpack streams when it comes to not closing them. Finding a way to address this during AUTH48 would be nice.
I agree, this was the intention -- closing the stream is treated as an error, and being asked to commit an error is itself an error. One could squint and say it's covered by the existing text -- upon receipt of the STOP_SENDING, the send is required to close the stream; closure of the stream is already required to be treated as an error. It's technically a normative change, but there's no effective change in behavior.
If it's a normative change, is it still OK to change in auth48 just with a WG consensus call or is more process required?
The AD has to decide what to do and approve this change to the RFC editor.
Since the fix includes a gentle normative change, marking this as a design issue and we'll put out a consensus call to the list.
Consensus was declared, so was merged.
Change:
by only including the Chosen Version in the Other Versions field of the Version Information Transport Parameter. <del> If the server does not find a compatible version, it will use the original version if it supports it, and if it doesn't then the server will perform incompatible version negotiation instead, see incompat- vn. </del> <ins> If the server does not find a compatible version (including the client's chosen version), it will perform incompatible version negotiation instead, see incompat-vn. Note that it is possible to have incompatible version negotation followed by compatible version negotiation.  For instance, if A and B are compatible and versions C and D are compatible, the following scenario may occur: In this example, the client selected C from the server's Version Negotiation packet, but the server preferred D and then selected it from the client's offer. </ins> 2.4. QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document (see compat-vn) is performed as part of a single QUIC connection; <del> that is, the packets with the original version are part of the same connection as the packets with the negotiated version. </del> <ins> that is, the packets with the client's chosen version are part of the same connection as the packets with the negotiated version. </ins> In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn)

Discussion:
Original version was defined as the version a client attempts prior to a VN packet. If there is a VN packet, I think that it is still possible to do a compatible upgrade from the version in the client's second attempt. In that case, "original version" isn't the right term to use when talking about compatible upgrades.
We can sidestep this particular issue by removing the "unless..." clause. That clause isn't helping because the client's chosen version MUST already be present in the compatible versions list. However, this issue raises a good point: it's possible for incompatible VN to happen and then be followed by compatible VN. We should clarify that this is allowed, and clearly define what the "original version" is in that scenario.
Consider the case where the client and server both support v1 and v2 and prefer v2. In the current draft, if the client puts v1 in the long header and the server responds with v2, that's called "compatible version negotiation". OTOH, if the client puts v2 in the long header and the server responds with v2, that's called, well, I'm not quite sure what. I guess not negotiation? I think a better way to think about this is that the client is sending an Initial that is compatible with both versions and so both of these cases are compatible version negotiation.
In the scenario where the client starts with v2 and the server responds with v2, I think of that as just "creating a v2 connection" without compatible version negotiation involved. Let's discuss this with the WG at IETF 113.
Change:
MAX_DATA frame, which indicates the maximum of the sum of the absolute byte offsets of all streams.  A receiver maintains a cumulative sum of bytes received on all streams, which is used to <del> check for flow control violations.  A receiver might use a sum of bytes consumed on all streams to determine the maximum data limit to be advertised. </del> <ins> check for violations of the advertised connection or stream data limits.  A receiver might use a sum of bytes consumed on all streams to determine the maximum data limit to be advertised. </ins> Once a receiver advertises a limit for the connection or a stream, it MAY advertise a smaller limit, but this has no effect.

Discussion:
(Broken out of .) >A receiver maintains a cumulative sum of It would have helped me, had this explained what was intended by “control violations” - I think it means to detect when the sender sends more than permitted by the flow control limit. I think the control part comes in a later sentence? (Is this measured against the largest advertised offset, or the current offset? … given what is written about reducing the advertised value?)
Change:
sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up. <ins> An endpoint might consistently record RTT samples as 0 in extremely low latency networks, leading to a smoothed_rtt of 0.  Consequently, the endpoint could declare all earlier packets as lost immediately upon receiving an acknowledgement for a later packet.  That is, the endpoint would not provide any reordering tolerance.  To avoid declaring packets as lost too early, the time threshold MUST be set to at least kGranularity (defined in ld-consts-of-interest). </ins> Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT variance.  Smaller thresholds reduce reordering resilience and

Discussion:
PTO works out fine, but loss_delay becomes weird. We should probably handle that.
In some environments, Kerberos integration (for server and client authentication) might be preferable to authentication via server certificates and SPNEGO.
Outside of this WG charter. A version of QUIC could be defined which does this, hypothetically, but our charter is to use TLS as the handshake for the version of QUIC we define.
One small suggestion, but LG
Change:
a reference to an active connection <del> a set of certificate chains and associated extensions (OCSP, SCT, etc.) </del> <ins> an identity, such as a set of certificate chains and associated extensions (OCSP, SCT, etc.) </ins> <del> a signer (either the private key associated with the certificate, or interface to perform private key operations) for each chain </del> <ins> a signer (either the private key associated with the identity, or interface to perform private key operations) for each chain </ins> an authenticator request or certificate_request_context (from 0 to 255 bytes)

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2. <ins> I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol that is used to encapsulate HTTP/3, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic.  It discusses what network operators can consider in some detail. More broadly, RFC 9065 RFC9065, "Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols" describes the impact of increased encryption of transport headers in general terms. </ins> 7.2. Although the IETF has put considerable emphasis on end-to-end

Discussion:
From NAME Authors may also want to refer to drafts about the same considerations (i.e., end-to-end crypto hindering operations).
Agree, will reference (was draft-ietf-tsvwg-transport-encrypt) Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
Change:
A sender SHOULD restart its PTO timer every time an ack-eliciting packet is sent or acknowledged, when the handshake is confirmed (Section 4.1.2 of QUIC-TLS), or when Initial or Handshake keys are <del> discarded (Section 9 of QUIC-TLS).  This ensures the PTO is always </del> <ins> discarded (Section 4.9 of QUIC-TLS).  This ensures the PTO is always </ins> set based on the latest estimate of the round-trip time and for the correct packet across packet number spaces.

Discussion:
So there are a couple of section references in the doc that points the wrong section in other documents. Section 6.2.1: "A sender SHOULD restart its PTO timer every time an ack-eliciting packet is sent or acknowledged, when the handshake is confirmed (Section 4.1.2 of [QUIC-TLS]), or when Initial or Handshake keys are discarded (Section 9 of [QUIC-TLS])", should that last ref be to section 4.9 in QUIC-TLS?"Section 6.4: "see Section 4.8 of [QUIC-TLS])" This is now Section 4.9.Section B.2: maxdatagramsize: The sender's current maximum payload size. Does not include UDP or IP overhead. The max datagram size is used for congestion window computations. An endpoint sets the value of this variable based on its PMTU (see Section 14.1 of [QUIC-TRANSPORT]), with a minimum value of 1200 bytes." Should that Section 14.1 reference be to 14.2.
Thank you for catching these, NAME