jiebi/CodeConvo huggingface dataset:
Change:
properties, it should only keep branches that satisfy these requirements.  Finally, it should order branches according to preferred properties, and finally use avoided properties as a <del> tiebreaker. </del> <ins> tiebreaker.  When ordering branches, an implementation may give more weight to properties that the application has explicitly set than to properties that are default. As the available protocols and paths on a specific system and in a specific context may vary, the result of sorting and the outcome of racing may vary even given the same Selection and Connection Properties.  However, an implementation ought to aim to provide a consistent outcome to applications, e.g., by preferring protocols and paths that existing Connections with similar Properties are already using. </ins> 4.4.

Discussion:
In the , people found the normative language in too restrictive and agreed with the original suggestion in . Therefore, this PR moves the selection algorithm text to the implementation draft and removes some normative language in the interface draft. We still want to provide consistency to applications when possible, so there's a sentence in the implementation draft on this now as well.
LGTM modulo the suggestion from NAME which I would accept as-is Great with one minor knit.
Change:
protect different content.  A server MAY abort the connection if it detects that the client reset the packet number. <del> A server acknowledges the use of a Retry packet for a connection using the retry_source_connection_id transport parameter; see transport-parameter-definitions.  If the server sends a Retry packet, it also subsequently includes the value of the Source Connection ID field from the Retry packet in its retry_source_connection_id transport parameter. If the client received and processed a Retry packet, it MUST validate that the retry_source_connection_id transport parameter is present and correct; otherwise, it MUST validate that the transport parameter is absent.  A client MUST treat a failed validation as a connection error of type PROTOCOL_VIOLATION. </del> <ins> The connection IDs used on Initial and Retry packets exchanged between client and server are copied to the transport parameters and validated as described in cid-auth. </ins> 17.3.

Discussion:
Please review carefully, but I think we can replace these paragraphs with a reference.
Nice find, thanks NAME !
Change:
TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with <del> TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. </del> <ins> TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. </ins> For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS

Discussion:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:
Change:
header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. <del> 2.5. </del> <ins> 2.6. </ins> The connection ID in the QUIC packet headers allows routing of QUIC packets at load balancers on other than five-tuple information,

Discussion:
also to address issue
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN
Change:
4.2.1. <del> The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </del> <ins> The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule. </ins> IP Version of this address assignment.  MUST be either 4 or 6.

Discussion:
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
Change:
a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. <del> Any changes to the ICE candidate policy also affect the next gathering phase.  If the policy is being made more liberal (i.e., more permitted candidates), and an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  If the policy is being made more strict, no ICE restart is needed, and the bit will not be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </del> <ins> Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> Any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered;

Discussion:
Also making the "need-ice-restart" bit get set for ANY policy change, rather than just more restrictive changes, to go along with this warning.
Needs merge to master
LGTM
lgtm
LGTM
If a candidate is in use and Policy changes such that this candidate is not longer allowed, do we have text that says to stop using that candidate and restart ice?
yes, I think this is covered in the setConfiguration text. Do you want to look and see if there is anything missing?
The current text says no ICE restart happens here, and it's not clear it should, since the cat is already out of the bag. Eric is going to look at adding a warning mentioning this.
Discussed in Kirkland and we think it is simplest to trigger ICE restart regardless of which way the policy changes.
Change:
If the packet is a 0-RTT packet, the server MAY buffer a limited number of these packets in anticipation of a late-arriving Initial <del> Packet.  Clients are forbidden from sending Handshake packets prior to receiving a server response, so servers SHOULD ignore any such </del> <ins> packet.  Clients are not able to send Handshake packets prior to receiving a server response, so servers SHOULD ignore any such </ins> packets. Servers MUST drop incoming packets under all other circumstances.

Discussion:
Clients aren't forbidden from sending a Handshake packet before receiving the ServerHello, they just don't have the keys to do so.
LGTM
Change:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> 1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> zero or more different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build

Discussion:
WFM
Oops, I'd missed that. I will change that instance as well.
It should not preclude 0, 1 or 2, therefore: s/several/zero or more/
Maybe just "representations of different media types"?
Change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-11 Include subtree keys in parent hash (*) Pin HPKE to draft-07 (*) Move joiner secret to the end of the first key schedule epoch (*) Add an AppAck proposal Make initializations of transcript hashes consistent </ins> draft-10 Allow new members to join via an external Commit (*)

Discussion:
Immediately after I published draft-11, NAME noticed that I had failed to update the change log. This PR adds it to the editor's copy, so that it will be included in future versions.
Change:
by the endpoint upon receipt. Connection IDs MUST NOT contain any information that can be used by <del> an external observer to correlate them with other connection IDs for the same connection.  As a trivial example, this means the same connection ID MUST NOT be issued more than once on the same connection. </del> <ins> an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same connection.  As a trivial example, this means the same connection ID MUST NOT be issued more than once on the same connection. </ins> Packets with long headers include Source Connection ID and Destination Connection ID fields.  These fields are used to set the

Discussion:
S 5.1. says At minimum this needs to be restricted to endpoints and other elements associated with them (like load balancers) because they need to be able to correlate connection IDs. But this is also a very strong condition, and in some cases will basically mandate encryption.
It should contain "by an external observer". I believe there is other text mentioning coordination with load balancers when constructing CID's. It is a strong condition - without it all other work on preventing linkage is more or less useless.
It feels strange to me that this is an RFC8174 MUST NOT, as it's unclear how to enforce it. That said, I agree that this text should be constrained to external observers - and clearly define who that is.
Maybe change to “Connection IDs MUST NOT expose”?
Tokyo conclusion: describe what the attack is and explain that anti-correlation text exists as an answer to this. The normative language is perhaps too strong, given that it might be possible to create smaller anonymity sets and still have a reasonable answer to the attack.
Discussed in London, NAME to resume work
NAME how is this progressing?
I believe this is an editorial issue, not design. We all know what we mean: it can encode information by use for itself and trusted intermediaries, but definitely is not correlatable. I agree that MUST is a little tricky unless we are mandating either true encryption or true randomness, which is a discussion I was hoping to defer until QUIC-LB is adopted.
Looks fine. This paragraph is wrapped to a shorter line-length than the standard for the document.
Change:
The "service-limit" is expressed in "quota-units" and has the following syntax: <del> where quota-units is a non-negative sf-integer. </del> <ins> where "quota-units" is a non-negative sf-integer. </ins> The "service-limit" SHOULD match the maximum number of acceptable requests.

Discussion:
clarify that quota-policy examples are not field values.
To clarify that examples in service-quota are not field-values
Change:
cryptographic keys for attachments is usually higher than for messages, hence slightly weakening the PCS guarantees for attachments. <ins> 4.2.2.4. In general we do not consider denial of service to be the responsibility of the protocol.  However, it should not be possible for anyone to perform a trivial denial of service from which it is hard to recover. --- back </ins>

Discussion:
As per Jan MLS meetup, malicious insiders should be considered as a potential threat, though perhaps in a restricted set of scenarios. It is probably bad if a malicious group member can trivially DoS people, for example, as in naïve ART.
Change:
Candidate Gathering, to identify the paths, protocols, and endpoints to use, and Candidate Racing, in which the necessary protocol handshakes are conducted so that the transport system can select <del> which set to use. </del> <ins> which set to use.  This document structures candidates for racing as a tree. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,

Discussion:
Restructure to address Rearrange to include Rendezvous and Environment Discovery text in connection establishment. Remove that previous section. was intended to check the ordering of sections against the other drafts and to merge . I have merged the Rendezvous text into Connection Establishment, but I haven't changed any of the text yet. I am a little concerned about creating an interdependancy in the text between derriving endpoints (name lookup) and the ICE/TURN stuff. More generally, I am not sure what to say about name resolution and proxies (ala ). TOR opens a can of privacy worms for name lookup and racing paths that I am not sure how to address.
Looks good apart from typo!
Having proxies to go through on a system (SOCKS, HTTP Connect, etc) or a set of TOR endpoints requires the implementation to do some nested/recursive work, and pass down endpoints correctly to protocol instances. The implementation document should describe this.
+1
There is already text in 4.1.3.3. Protocol Options. Is that sufficient or do we need more?
Review structure. What fits in pre-establishment. Relation system policy - cached state. Generalizes
Discussed in Singapore, we'll have more structure comments later, but we've done a lot of changes since then.
I like the change, as it makes the process much clearer and reduces the awkwardness of ICE/STUN. To model TOR, SOCKS, or other tunnelling protocols, I would refrain from seeing them as protocol stacks, but treat them as derived paths that only support these stacks. This removes the need for cupeling name resolution to the protocol stack, and looks quite natural to me as these derived paths may be available in the connection cache or need to be established for name resolution anyway before starting the real candidate racing. If we want to do so, it might be easier to talk about paths (that have one or more corresponding local endpoints), derived paths, derived remote endpoints (as result of name resolution on each path) and protocol stacks.
Change:
RTCIceCandidateStats dictionaries exposed to web pages do not contain any 'ip' member if related to a host ICE candidate. <del> 4.2. </del> <ins> 3.2. </ins> Dynamically generated names can be used to track users if used too often.  Conversely, registering too many names will also generate useless processing.  The proposed rule is to create and register a new generated name for a given IP address on a per execution context. <del> 4.3. </del> <ins> 3.3. </ins> <del> Privacy might also be breached if two execution contexts can identify whether they are run in the same device based on a successful peer- to-peer connection.  The proposed rule is to not register any name using Multicast DNS for any ICE agent belonging to: </del> <ins> As noted in IPHandling, privacy may be breached if a web application running in two browser contexts can determine whether it is running on the same device.  While the approach in this document prevents the application from directly comparing local private IP addresses, a successful local WebRTC connection can also present a threat to user privacy.  Specifically, when the latency of a WebRTC connection latency is close to zero, the probability is high that the two peers are running on the same device. </ins> <del> A third-party browser execution context, i.e. a context that is not same origin as the top level execution context. </del> <ins> To avoid this issue, browsers SHOULD NOT register Multicast DNS names for WebRTC applications running in a third-party browser execution context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. </ins> <del> A private browsing execution context. 5. </del> <ins> 4. </ins> The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate.

Discussion:
Privacy text was moved to ip-handling, so no longer needed here. Update some surrounding sections accordingly.
LGTM. Let's merge this one, we will correct RFC6762 in the PR that is already doing that or as an editorial commit.
As discussed at IETF 101, ip-handling should define the problems, and this document should present the mDNS solution.
See URL
LGTM
Change:
This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., <del> the quickly varying channel conditions use-case. </del> <ins> the quickly varying channel conditions use-case where ACM may not be reacting quickly enough. </ins> 4.3.

Discussion:
section 4.1 - PEP is Enhancing, not Enhancement. PEPs usually split... section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well. ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist
Thanks for the nits on the PEP. For the comment on ACM, we have updated the text (PR ) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough." We have updated the conference in PR and PR
Change:
data for a terminated connection is to use the stateless reset process (stateless-reset). <del> An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the existence of the error to its peer. </del> 11.2. If an application-level error affects a single stream, but otherwise

Discussion:
If we get one, rely on the back-off that we require endpoints to implement when they enter the closing state. No need for any additional special processing rules (as mentioned in ).
Section 11.1 says: "An endpoint that receives an invalid CONNECTIONCLOSE frame MUST NOT signal the existence of the error to its peer." Editorially, it is not clear to me whether I am to suppress the error code in the CONNECTIONCLOSE frame or the error I generate when I receive an invalid frame. Moreover, I am not sure what constitutes an invalid CONNECTION_CLOSE frame. The words don't occur elsewhere. Section 19.19 doesn't define any fatal errors for this type. I can imagine a Reason Length that overruns the packet, or perhaps an undefined error code? A bogus frame type? We should probably define those in 19.19. Perhaps this sentence is an artifact from before we were throwing away Initial keys agressively?
If you suppress the error, does it matter which error you do not send?
I'm not sure what the intent of the sentence is. Do I send PROTOCOL_VIOLATION but not the error code in the frame? Do I send nothing?
As I read it, you should not send anything if you see CONNECTION_CLOSE. As to the motivation, I'm not quite sure, but if the peer closes but does it badly, chances are that anything you send just results in stateless resets. Maybe there can also be some malicious intend, especially in early handshake, but I don't think that is the reason.
I think this is addressing the injected packet case -- if you ignore an injected CONNECTION_CLOSE, you shouldn't send the real peer anything about it, or you've just allowed an attacker to inject authenticated traffic in the connection.
This is more about the looping case: sending CONNECTIONCLOSE in response to CONNECTIONCLOSE. But it is badly worded.
From the current text in 10.3 After sending a CONNECTIONCLOSE frame, endpoints immediately enter the closing state. During the closing period, an endpoint that sends a CONNECTIONCLOSE frame SHOULD respond to any packet that it receives with another packet containing a CONNECTION_CLOSE frame. To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet.

This will be a loop since the same invalid packet will be sent again by the sender ....
I'm going to request that this be re-assessed. When looking into Roni's comment, I realize that we aren't really clear enough about this invalid case and some (small amount of) discussion might be necessary to confirm that this change is OK.