jiebi/CodeConvo huggingface dataset:
Change:
opening.  If the transport parameter is absent, streams of that type start with a flow control limit of 0. <del> A client MUST NOT include an original connection ID, a stateless reset token, or a preferred address.  A server MUST treat receipt of any of these transport parameters as a connection error of type </del> <ins> A client MUST NOT include server-only transport parameters (original_connection_id, stateless_reset_token, or preferred_address).  A server MUST treat receipt of any of these transport parameters as a connection error of type </ins> TRANSPORT_PARAMETER_ERROR. 19.

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:
Session resumption allows servers to link activity on the original connection with the resumed connection, which might be a privacy issue for clients.  Clients can choose not to enable resumption to <del> avoid creating this correlation.  Client SHOULD NOT reuse tickets as </del> <ins> avoid creating this correlation.  Clients SHOULD NOT reuse tickets as </ins> that allows entities other than the server to correlate connections; see Section C.4 of TLS13.

Discussion:
Too fast! Thanks.
This will require rewrapping, which I can do if you prefer.
Change:
various shorthands in terms of bracket notation.  Examples and descriptions use shorthands where convenient. <del> 1.3.3. </del> <ins> 1.4.3. </ins> A wildcard "*" (wildcard) in the expression "[*]" selects all children of an object or an array and in the expression "..[*]"

Discussion:
The text will be adjusted in a future PR.
This github bug is slowing me down a bit:
Huh! I'm not seeing that.
I'm only seeing it every second time I try to pull the repo state (issues, PRs) into emacs, which seems to use a graphql API. Annoying. This used to work well...
Thanks!
Change:
transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and createAnswer.  Note that setCodecPreferences does not directly affect <del> which codec the implemtation decides to send.  It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer.  Even when a codec is excluded by </del> <ins> which codec the implementation decides to send.  It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer.  Even when a codec is excluded by </ins> setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it.

Discussion:
NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm
Change:
A "connect-udp" request requests that the recipient proxy establish a tunnel over a single HTTP stream to the destination target identified <del> by the "target_host" and "target_port" variables of the URI template </del> <ins> by the "target_host" and "target_port" variables of the URI Template </ins> (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa until the tunnel is closed.  Tunnels are commonly used to create an

Discussion:
-> a URI Template
but also is it "URI Template" or "URI template"? this seems inconsistent through the document
Change:
behavior admits a handful of UDP packets and then makes a decision to whether or not filter later packets in the same connection.  QUIC applications are encouraged to fail over to TCP if early packets do <del> not arrive at their destination I-D.ietf-quic-applicability, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec- udp-1312).  Admitting a few packets allows the QUIC endpoint to determine that the path accepts QUIC.  Sudden drops afterwards will result in slow and costly timeouts before abandoning the connection. </del> <ins> not arrive at their destination QUIC-APPLICABILITY, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec-udp-1312). Admitting a few packets allows the QUIC endpoint to determine that the path accepts QUIC.  Sudden drops afterwards will result in slow and costly timeouts before abandoning the connection. </ins> 4.6.

Discussion:
as well
There are some outdated references those I goes will go away with further revisions. However, there are duplicate references those I believe need to be fixed manually. -- Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'. -- Duplicate reference: RFC8899, mentioned in 'RFC8899', was also mentioned in 'DPLPMTUD'.
I noticed that there are references to QUIC I-Ds. Applicability even references both -34 and RFC9000 :smile:
Change:
In any case, risk of starvation <del> 7.1. </del> <ins> 8.1. </ins> With this approach, the server ensures that incoming messages are added to an ordered queue and outgoing messages are dispatched in the

Discussion:
This PR adds a pretty complete description of the protocol. The only major thing that's missing is , which should be straightforward-ish to construct. NAME want to take a stab at that?
Change:
9.2. <ins> QUIC requires that endpoints generate fresh connection IDs for use on new network paths.  Choosing values that are unlinkable to an outside observer ensures that activity on different paths cannot be trivially correlated using the connection ID. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination

Discussion:
launches right into discussion of how linkability protections might be inadequate without really establishing what the requirements are or why they exist. This needs an introduction paragraph.
Note sure how much more we want to say here or can say at this point in time.... NAME if you have a more concrete idea what we should say here, can you give it a try and propose a PR?
Something like: Then launch into the existing discussion.
Sounds good to me. I can add that after you PR landed or you can add it to your PR.
Change:
in the range -256 to -1 are reserved for testing and use in closed environments (see iana-private-use).  Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software <del> ID Link Relationship Values" registry (see iana-link-rel).  If a </del> <ins> Tag Link Relationship Values" registry (see iana-link-rel.  If a </ins> string value is used it MUST be either a private use name as defined in iana-private-use or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/ link-relations/link-relations.xhtml as defined by RFC8288.  When a <del> string value defined in the IANA "Software ID Link Relationship </del> <ins> string value defined in the IANA "Software Tag Link Relationship </ins> Values" registry matches a Relation Name defined in the IANA "Link <del> Relation Types" registry, the index value in the IANA "Software ID Link Relationship Values" registry MUST be used instead, as this relationship has a specialized meaning in the context of a CoSWID tag.  String values correspond to registered entries in the "Software ID Link Relationship Values" registry. </del> <ins> Relation Types" registry, the index value in the IANA "Software Tag Link Relationship Values" registry MUST be used instead, as this relationship has a specialized meaning in the context of a CoSWID tag.  String values correspond to registered entries in the "Software Tag Link Relationship Values" registry. </ins> media-type (index 41): A link can point to arbitrary resources on the endpoint, local network, or Internet using the href item.  Use

Discussion:
Removed IANA registrations for swid and swidpath and updated text to note these are not technically URIs but just expressions using URI syntax.
Change:
least 1200 bytes. The crypto retransmission timer is not set if the time threshold <del> time-threshold loss detection timer is set.  When the crypto retransmission timer is active, the probe timer (pto) is not active. </del> <ins> time-threshold loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the crypto retransmission timeout and be less likely to spuriously retransmit data.  The Initial and Handshake packet number spaces will typically contain a small number of packets, so losses are less likely to be detected using packet-threshold loss detection. When the crypto retransmission timer is active, the probe timer (pto) is not active. </ins> 6.2.1.

Discussion:
Adds some explanation about why it's better to arm/fire the time threshold alarm before the crypto retransmission timeout. Hopefully clarifies comments from
Thanks for the explanation. It's much clearer. Can i ask for one more clarification? In DetectLostPackets, shouldn't the for-loop have been something like this:
Thanks for catching the pseudocode error in DetectLostPackets. PTAL.
lgtm. thank you!
In both SetLossDetectionTimer() and OnLossDetectionTimeout(), the losstime based timer setup and loss detection happens before the crypto loss recovery logics. That seems at the cross road with the idea that crypto packets having higher priority in loss recovery. In fact in OnLossDetectionTimerou(), if losstime is present and we go into DetectLostPackets(), then we will only decect loss of one packet number space between Initial and Handshake. Plus the losstime used to set the timer is the earliest among all possible values, which means even if only one of Initial and Handshake space has inflight packets, we may still not retransmit all the inflight packets when this timer fires. So this current code really doesn't follow the idea that when crypto is inflight and loss timer fires, all inflight crypto needs to be retransmitted. If we change the code so that crypto is handled first, we can also reduce the states need to be maintained and simplify some of the functions. In current draft there are 3 losstimes, one per packet number space. By always handling crypto first, we will need such loss_time for AppData space only, and no need to have the helper function to GetEarliestLossTime(). (I'm more than happy to cook up a PR if people think this makes sense.)
It's been a few days. I sent PR .
This was introduced as a fix to URL, and fixed in URL I don't think we should revert that fix.
+1 to NAME comment. Timers are necessary when you have no information about what might be lost, but if you do have information, there's no reason not to use that instead.
I sent out an editorial PR to clarify why time based loss detection has higher priority.
Change:
by the token_type and corresponding issuance protocol. The authenticator value in the Token structure is computed over the <del> token_type, nonce, context, and token_key_id fields. </del> <ins> token_type, nonce, challenge_digest, and token_key_id fields. </ins> When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-

Discussion:
Suspect the prose is not aligned with the structure, it says but there is no field in .
Yup, that should say . The name changed.
Change:
max_early_data_size bytes of 0-RTT data SHOULD terminate the connection with an "unexpected_message" alert. <del> 4.5.2. </del> <ins> 4.6.2. </ins> The server is permitted to request client authentication at any time after the handshake has completed by sending a CertificateRequest

Discussion:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.
Change:
among a user's devices so that each user appears as a single client. <del> A short-lived HPKE key pair used to introduce a new client to a group.  Initialization keys are published for each client (UserInitKey). </del> <ins> A short-lived HPKE I-D.irtf-cfrg-hpke key pair used to introduce a new client to a group.  Initialization keys are published for each client (ClientInitKey). </ins> A long-lived signing key pair used to authenticate the sender of a message.

Discussion:
Addressed SV's comments Remove the client fanout concept (because of TreeKEM's handshake ordering requirements) Rename UserInitKeys to ClientInitKeys Minor editorial edits
drop client fanout specify why (policy enforcement, metadata protection) incorporated comments from SV check if it is necessary to define server-to-server message formats only one domain is responsible for a group
I'm very interested in the details of this, but was unable to attend the interim meeting. Does this mean that we are explicitly ruling out client fanout entirely? What metadata are we trying to protect here? You could in theory protect all the metadata with client fanout over Tor for example. Does domain here mean domain name? Why is that relevant? (I'd expect MLS to be independent of DNS) The kind of federated delivery service I'm hoping to be able to use with MLS is logically an append only list of messages published by each member. Where each member can read any other members queue and pull messages they don't have into their own queue (they push their own messages to their own queue only). This allows for diverse P2P topologies, and bandwidth efficient routing. This would be compatible with both and .
TreeKEM has the requirement of total ordering of handshake messages which doesn't work with client fanout. Therefore we drop the idea of client fanout until we have a better proposal on how to solve this. is more conceptual, it doesn't have to be an actual domain name.
Addressed in .
Change:
When a SessionDescription is supplied to setLocalDescription, the following steps MUST be performed: <del> First, the type of the SessionDescription is checked against the current state of the PeerConnection: </del> <ins> If the description is of type "rollback", follow the processing defined in sec.rollback and skip the processing described in the rest of this section. Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: </ins> If the type is "offer", the PeerConnection state MUST be either "stable" or "have-local-offer".

Discussion:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM
Change:
K_4 and IV_4 are defined in <del> PLAINTEXT_4 = ( ? PAD, ? EAD_4 ) </del> <ins> PLAINTEXT_4 = ( ? PAD_4, ? EAD_4 ) </ins> <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del> <ins> PAD_4 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext. EAD_4 - external authorization data, see AD.

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
Often, the various supported encrypted DNS protocols will be accessible using the same hostname.  In the example above, both DoH and DoT use the name "resolver.example.com" for their TLS <del> certficates.  If a deployment uses a different hostname for one </del> <ins> certificates.  If a deployment uses a different hostname for one </ins> protocol, but still wants clients to treat both DNS servers as designated, the TLS certificates MUST include both names in the SubjectAlternativeName fields.  Note that this name verification is

Discussion:
This addresses the remaining portions of not address by a prior PR
Migrated from original DEER issue: URL
The Special Use Domain Name (SUDN) URL needs more clarification. Specifically: Queries against the .arpa nameservers The draft should mention that .arpa is a delegated zone, currently served by the root nameservers. Clients that query a resolver that is unaware of this requirement will "leak" queries to the root nameservers. When URL is not present in a resolver configuration Section 6.1 discusses how a forwarder should behave and suggests that results should not be cached other than for Equivalent Encrypted Resolvers under their control. How is that determined? There is no discussion around a non-forwarding resolver's behaviour. Should it return NODATA? Forwarding queries to URL will attempt to attach a client to an upstream resource's equivalent resolver. If that equivalent resolver's cert doesn't include the forwarder, the client must reject the answer. Is it not therefore the case that the forwarder caching behaviour is irrelevant? All valid responses to this query must be equivalent to the forwarder itself. When URL is present in a resolver configuration I would suggest some clarification wording something like this: The expectation is that this record set will detail equivalent resolvers. A client that chooses not to interact with any of these equivalent resolvers SHOULD continue to use the unencrypted resolver, honouring the SVCB TTL. When the SVCB TTL expires, the client may choose to re-query in an attempt to discover newly available equivalents. I would suggest (prefer?) changing the SUDN behaviour so that queries against it are never sent upstream. Resolvers (and forwarders) that do not have a configured URL RRset should return NODATA. This would mean that URL SUDN RRsets are always specific to the IP queried.
It may be good to model the advice after RFC8880, which defines URL
I am leaving this open so I can re-review the text after addressing other PRs; PR 14 addressed some of the points raised in this issue but not all of them.
Change:
All endpoints MUST send keepalives for each media session.  These keepalives serve the purpose of keeping NAT bindings alive for the <del> media session.  The keepalives SHOULD be sent using a format that is supported by its peer.  ICE endpoints allow for STUN-based keepalives for UDP streams, and as such, STUN keepalives MUST be used when an agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full). </del> <ins> media session.  These keepalives MUST be sent even if ICE is not being utilized for the session at all.  The keepalive SHOULD be sent using a format that is supported by its peer.  ICE endpoints allow for STUN-based keepalives for UDP streams, and as such, STUN keepalives MUST be used when an agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full). If the peer does not support ICE, the choice of a packet format for keepalives is a matter of local implementation.  A format that allows packets to easily be sent in the absence of actual media content is RECOMMENDED.  Examples of formats that readily meet this goal are RTP No-Op I-D.ietf-avt-rtp-no-op, and in cases where both sides support it, RTP comfort noise RFC3389.  If the peer doesn't support any formats that are particularly well suited for keepalives, an agent SHOULD send RTP packets with an incorrect version number, or some other form of error that would cause them to be discarded by the peer. </ins> If there has been no packet sent on the candidate pair ICE is using for a media component for Tr seconds (where packets include those defined for the component (RTP or RTCP) and previous keepalives), an <del> agent MUST generate a keepalive on that pair.  ICE endpoints SHOULD use a Tr value of 15 seconds, but MAY use another value, e.g. based on configuration or network/NAT characteristics.  For example, if an agent has a dynamic way to discover the binding lifetimes of the intervening NATs, it can use that value to determine Tr. Administrators deploying ICE in more controlled networking environments SHOULD set Tr to the longest duration possible in their environment.  ICE endpoints MUST NOT use a Tr value smaller than 15 seconds. When STUN is being used for keepalives, a STUN Binding Indication is </del> <ins> agent MUST generate a keepalive on that pair.  Tr SHOULD be configurable and SHOULD have a default of 15 seconds.  Tr MUST NOT be configured to less than 15 seconds.  Alternatively, if an agent has a dynamic way to discover the binding lifetimes of the intervening NATs, it can use that value to determine Tr.  Administrators deploying ICE in more controlled networking environments SHOULD set Tr to the longest duration possible in their environment. If STUN is being used for keepalives, a STUN Binding Indication is </ins> used RFC5389.  The Indication MUST NOT utilize any authentication mechanism.  It SHOULD contain the FINGERPRINT attribute to aid in demultiplexing, but SHOULD NOT contain any other attributes.  It is

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.