jiebi/CodeConvo huggingface dataset:
Change:
maximum ack delay.  Packets that are not ack-eliciting are only acknowledged when an ACK frame is sent for other reasons. <del> When sending a packet for any reason, an endpoint should attempt to </del> <ins> When sending a packet for any reason, an endpoint SHOULD attempt to </ins> bundle an ACK frame if one has not been sent recently.  Doing so helps with timely loss detection at the peer.

Discussion:
I believe this always should have been normative, so this change is editorial, but I'll let the editors confirm that.
Change:
India was the country that saw the largest number of internet shutdowns per year in 2016 and 2017 Dada-2017. <ins> 5.3.3. Often, censors implement multiple techniques in tandem, creating "censorship in depth".  Censorship in depth can take many forms; some censors block the same content through multiple techniques (such as blocking a domain by DNS, IP blocking, and HTTP simultaneously), some deploy parallel systems to improve censorship reliability (such as deploying multiple different censorship systems to block the same domain), and others can use complimentary systems to limit evasion (such as by blocking unwanted protocols entirely, forcing users to use other filtered protocols). Trade-offs: Censorship in depth can be attractive for censors to deploy, as it offers additional guarantees about censorship: even if someone evades one type of censorship, they may still be blocked by another.  The main drawback to this approach is the cost to initial deployment, as it requires the system to deploy multiple censorship systems in tandem. Empirical Examples: Censorship in depth is present in many large censoring nation states today.  Researchers have observed China has deployed significant censorship in depth, often censoring the same resource across multiple protocols Chai-2019, Bock-2020b or deploying additional censorship systems to censor the same content and protocol Bock-2021b.  Iran also has deployed a complimentary protocol filter to limit which protocols can be used on certain ports, forcing users to rely on protocols their censorship system can filter Bock-2020. </ins> 6. 6.1.

Discussion:
Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!
Change:
the maximum permitted value of the SETTINGS_H3_DATAGRAM setting parameter is 1. <del> It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the SETTINGS_H3_DATAGRAM setting with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. </del> <ins> It is RECOMMENDED that implementations that support receiving HTTP/3 Datagrams always send the SETTINGS_H3_DATAGRAM setting with a value of 1, even if the application does not intend to use HTTP/3 Datagrams.  This helps to avoid "sticking out"; see security. </ins> 2.1.1.1.

Discussion:
Editorial suggestions from WGLC review
This protocol is being introduced with one use case, and that case is a generalisation that's capable of incorporating almost anything (datagrams). Is this a case of premature abstraction? While from an implementation standpoint this abstraction might not be expensive, adding a new abstraction to HTTP's core data model isn't something we should do lightly; the road is littered with failed and poorly-integrated attempts.
At the MASQUE Interim in April 2021, the WG reached consensus on strongly associating HTTP Datagrams with requests, and the fact that HTTP Datagrams would work across intermediaries. We also established that there was a need to register context semantics end-to-end. That same day, Ben Schwartz proposed the name capsule for such a system and we've kept it since. In the past year, we've thoroughly discussed capsules among the Working Group, and the possibility of premature optimization was discussed. The Working Group decided that this was a useful abstraction, and CONNECT-IP and WebTransport both started using the abstraction, confirming that it was useful. The final design of the Capsule Protocol came out of the HTTP Datagrams design team, was presented at the February 2022 MASQUE Interim and Working Group consensus was declared by the chairs . Unless you have any new information that would warrant revisiting this consensus, I'd suggest closing this issue with no action.
Closing this based on the comment above since today marks the end of WGLC
LGTM, thanks! Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric
Change:
a peer of the maximum amount of data that can be sent on a stream. A MAX_STREAM_DATA frame can be sent for streams in the Recv state; <del> see stream-send-states.  Receiving a MAX_STREAM_DATA frame for a </del> <ins> see stream-recv-states.  Receiving a MAX_STREAM_DATA frame for a </ins> locally-initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR.  An endpoint that receives a MAX_STREAM_DATA frame for a receive-only

Discussion:
Tommy points out that we accidentally cited the sending parts, but these are receive states.
Very editorial nit: The section has the following text: The states referenced here are in fact receive stream states, not send stream states. Should this be: The same goes for MAXSTREAM_DATA:
Change:
not a threat in their environment.  Clients MUST be prepared to do a cookie exchange with every handshake. <ins> With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS always provides order protection and non-replayability, DTLS does not provide order protection and may not provide replay protection. </ins> Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection.

Discussion:
Suggested pull request related to issue
The Abstract states that: "The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees." This is not true when it comes to Order protection/non-replayability which is states as a guarantee in Appendix E.2 of RFC 8446. DTLS does not provide order protection and may not provide replay protection. I suggested this statement "equivalent security guarantees" is deleted (or rewritten) in the abstract and that some short text describing this is added to the Security Considerations.
Fixed.
Change:
allows only older frame pithing a short interval to support out of order delivery. <del> 4.3.5. Because the E2EE keys could be rotated during the call when people join and leave, these new keys are exchanged using the same E2EE secure channel used in the initial key negotiation.  Sending new fresh keys is an expensive operation, so the key management component might chose to send new keys only when other clients leave the call and use hash ratcheting for the join case, so no need to send a new key to the clients who are already on the call.  SFrame supports both modes 4.3.5.1. When SFrame decryptor fails to decrypt one of the frames, it automatically ratchets the key forward and retries again until one ratchet succeed or it reaches the maximum allowed ratcheting window. If a new ratchet passed the decryption, all previous ratchets are deleted. 4.3.5.2. SFrame will set the key immediately on the decrypts when it is received and destroys the old key material, so if the key manager sends a new key during the call, it is recommended not to start using it immediately and wait for a short time to make sure it is delivered to all other clients before using it to decrease the number of decryption failure.  It is up to the application and the key manager to define how long this period is. </del> 4.4. Every client in the call knows the secret key for all other clients

Discussion:
This PR attempts to capture the spirit of the original key management provisions with a little more clarity about assumptions. It also adds a more more explicit construction for connecting SFrame to MLS.
Change:
4.2.10.1. <ins> The client's view of the age of a ticket is the time since the receipt of the NewSessionTicket message.  Clients MUST NOT attempt to use tickets which have ages greater than the "ticket_lifetime" value which was provided with the ticket.  The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add" value that was included with the ticket, see NSTMessage modulo 2^32.  This addition prevents passive observers from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds. 4.2.10.2. </ins> The PSK binder value forms a binding between a PSK and the current handshake, as well as between the handshake in which the PSK was generated (if via a NewSessionTicket message) and the handshake where

Discussion:
…s , , .
NAME if you want to propose some revised text, I will TAL.
From Nikos's comment:
This is relating to . I will try to resolve both issues.
It is hard to understand the current text of Section 4.2.9.3 (Replay Properties). NAME explained me that a server should check: The server can tell: serverrecvtime == now serversendtime == one parameter in the ticket clientsendtime - clientrecvtime == ticketage == obfuscatedticketage + ticketage_add If this understanding is correct, I would suggest to add more explanation to the section.
Yes, that's correct. PRs welcome
I made a tweak to avoid referring to the "base value", in , though more changes may still be helpful.
Change:
enabling applications written to a single API to make use of transport protocols in terms of the features they provide; <del> Unified interface to datagram and connection-oriented transports, allowing use of a common API for connection-establishment and closing; </del> <ins> A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection- establishment and closing; </ins> Message-orientation, as opposed to stream-orientation, using application-assisted framing and deframing where the underlying

Discussion:
Suggested sentence to unambiguously explain datagram v. connection opening.
For me at least, it would be nice for the implementation draft to also initially remind readers that the Connection objects are relevant to all transports, including those that are not themselves connection-oriented.
Thought to be fixed in
Fixed in
Looks good! Thank you!
Change:
PATH_STATUS Frames contain the following fields: <del> Path Identifier: An identifier of the path, which is formatted as shown in fig-path-identifier-format.  Exactly the same as the definition of Path Identifier in {#path-abandon-frame}. </del> <ins> The identifier of the path that the status update correspondes to. </ins> <del> Path Status sequence number: A variable-length integer specifying the sequence number assigned for this PATH_STATUS frame.  The sequence number MUST be monotonically increasing generated by the sender of the Path Status frame in the same connection.  The receiver of the Path Status frame needs to use and compare the sequence numbers separately for each Path Identifier. </del> <ins> A variable-length integer specifying the sequence number assigned for this PATH_STATUS frame.  The sequence number MUST be monotonically increasing generated by the sender of the Path Status frame in the same connection.  The receiver of the Path Status frame needs to use and compare the sequence numbers separately for each Path Identifier. </ins> Available values of Path Status field are:

Discussion:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
From PR by NAME
Looks good to me
Change:
filtering on groups would return a list of endpoints that are in the specified groups. <ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource observation (RFC7641), or any future mechanism that might allow more efficient observations of collections.  These are advertised, detected and used according to their own specifications and can be used with the lookup interface as with any other resource. </ins> The lookup interface is specified as follows: Client -> RD

Discussion:
Observe, ETag and possible future mechanisms are stated to be generally usable, but phrased as a "like with any other resource", because there is no need to actually define something new here.
Merged as agreed in the last call. NAME I'll address your comments in a different issue as I think they don't relate directly to that PR.
It would be good to provide a way for clients to receive notifications upon updates of an RD.
Is this something we need to specify? IMO it'd be orthogonal to the interface description -- if the RD advertises a , any client can try to observe the presence of endpoints.
So we should just say that such a lookup can be tried with observe, and that the link attribute "obs" is a good way to provide a hint. Any future optimized collection observe would probably use RD as a prominent example, so we can expect RD implementers to pick this up later.
Change:
demultiplexing layer.  Additionally, this document defines how to convey datagrams over prior versions of HTTP. <ins> This document is structured as follows: multiplexing presents core concepts for multiplexing across HTTP versions. datagram-contexts defines datagram contexts, an optional end- to-end multiplexing concept scoped to each HTTP request. datagram-formats defines datagram formats, which are scoped to contexts.  Formats communicate the format and encoding of datagrams sent using the associated context. Contexts are identified using a variable-length integer. Requirements for allocating identifier values are detailed in context-id-alloc. format defines how QUIC DATAGRAM frames are used with HTTP/3. setting defines an HTTP/3 setting that endpoints can use to advertise support of the frame. capsule introduces the Capsule Protocol and the "data stream" concept.  Data streams are initiated using special-purpose HTTP requests, after which Capsules, an end-to-end message, can be sent. The following Capsule types are defined, together with guidance for defining new types: REGISTER_DATAGRAM_CONTEXT REGISTER_DATAGRAM_NO_CONTEXT CLOSE_DATAGRAM_CONTEXT DATAGRAM </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
err'ing on the side of succinct
There's now several different concepts to wrangle in this document. Reading from the top, we first tackle multiplexing (the major motivation for the document), then the frame, then capsules. Capsules underpin the mechanics of multiplexing. I don't think we can fix this chicken and egg problem but adding a brief overview of the concepts and terms before they are tackled in the prose could help readability.
I think that sounds like a great idea!
Thanks for doing this!
Change:
generous in supporting many different key formats to allow different types of client software and client instance deployments. <ins> 12.34. An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of this document, but the use of GNAP to protect a system does not absolve the resource server of following best practices.  GNAP generally considers a breach can occur, and therefore advises to prefer key-bound tokens whenever possible, which at least limits the impact of access token leakage by a compromised or malicious RS. </ins> 13. The privacy considerations in this section are modeled after the list

Discussion:
fix typos
Built To edit notification comments on pull requests, go to your .
Removing the editorial label after the last change (which is normative)
This discovery method is great for usability but worrying from a security POV. The RS is telling the Client to create a request to an arbitrary AS using an arbitrary access specification and the Client's credentials. The Client doesn't have any way to understand, validate or filter anything in the RS's response, so it cannot protect itself. By the way, shouldn't we use a semicolon before the parameter? A possible workaround is to add something analogous to a parameter to the AS access request containing the RS address, require the Client to include it, and require that the AS validate that the request is indeed to that RS.
In this scenario the client is explicitly looking to the RS to provide a pointer to which AS to talk to. In most cases this is pre-configured (the client knows which AS protects which RS). In some cases this will be communicated at runtime, using this mechanism. There are both security and privacy ramifications for this choice, which we've covered at least some of in the current text. I'm sure this can be expanded.
GNAP is a delegation protocol that enables separation of control from processing with obvious advantages to all three parties (subject, controller, processor). The RS is typically a processor. The choice of AS as delegated controller SHOUlD lie with the subject in order to better represent their interest. This perspective is, of course, not absolute but it the should makes it the preferred path.
NAME I don't see anything explicit about this call. The client just makes a normal-but-unauthenticated call to the RS, with no special indication that it's doing discovery. In fact a malicious RS can redirect the client anyway, even if the client is in fact authenticated. And I don't see anything in the text about the threat vector of a malicious RS. Please also respond to my syntactic comment above.
I've got a few comments on wording. Mostly though: I'm not sure about changing the field to , since it's not just ANY opaque value but specifically an opaque value for use in the access section of the request. As such, I think is too generic in this use. If we change the parameter name back I think this is OK.
Change:
Section 5.3. If present in the offer, an "a=rtcp-mux" line, as specified in <del> 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. </del> <ins> RFC5761, Section 5.1.1.  Otherwise, an "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0" (because no candidates have yet been gathered). </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5.

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
5. <ins> In order to facilitate extensibility of contexts, the REGISTER_DATAGRAM_CONTEXT, REGISTER_DATAGRAM_NO_CONTEXT, and the CLOSE_DATAGRAM_CONTEXT capsules carry a Context Extensions field. That field contains a sequence of context extensions: Each context extension is encoded as a (type, length, value) tuple: Context Extension Types are registered with IANA, see iana-ext-types. The Context Extension Length field contains the length of the Context Extension Value field in bytes.  The semantics of the Context Extension Value field are defined by the corresponding Context Extension Type. 5.1. The CLOSE_CODE context extension type (type=0x00) allows an endpoint to provide additional information as to why a datagram context was closed.  This type SHALL only be sent in CLOSE_DATAGRAM_CONTEXT capsules.  Its Context Extension Value field consists of a single variable-length integer which contains the close code.  The following codes are defined: This indicates that the registration was closed without any additional information. This indicates that the sender has rejected the context registration based on its local policy.  The endpoint that had originally registered this context MUST NOT try to register another context with the same context extensions on this stream. This indicates that the context was closed to save resources.  The recipient SHOULD limit its future registration of resource- incentive contexts. Receipt of an unknown close code MUST be treated as if the NO_ERROR code was present.  Close codes are registered with IANA, see iana- close-codes. 5.2. The DETAILS context extension type (type=0x01) allows an endpoint to provide additional details to context capsules.  It is meant for debugging purposes.  Its Context Extension Value field consists of a human-readable string encoded in UTF-8. 6. </ins> Implementations of HTTP/3 that support this mechanism can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks