jiebi/CodeConvo huggingface dataset:
Change:
3.1. Many industrial protocols assume that PSKs are distributed and <del> assigned by manually via one of the following approaches: typing the PSK into the devices, or via a web server masks (using a TOFU approach with a device completely unprotected before the first login did take place).  Many devices have very limited GUI functionalities.  For example, they only a numeric keypad or even only five buttons.  So when the TOFU approach is not suitable in a setting, entering the key would require typing it on a constrained HMI interface.  Moreover, PSK production lacks guidance, similar to user passwords. </del> <ins> assigned manually via one of the following approaches: typing the PSK into the devices, or via web server masks (using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place).  Many devices have very limited UI.  For example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </ins> Some devices are provisioned PSKs via an out-of-band, cloud-based syncing protocol. Secrets may be baked into or hardware or software device <del> components, such as secure enclaves.s </del> <ins> components, such as secure enclaves. </ins> 3.2.

Discussion:
Moved links in use cases sections to references and made the text somewhat more concise. Added some initial text on known attacks.
Change:
token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is <del> discarded.  A server MAY encode tokens provided with NEW_TOKEN </del> <ins> discarded.  A server SHOULD encode tokens provided with NEW_TOKEN </ins> frames and Retry packets differently, and validate the latter more strictly.

Discussion:
Although not super-important, the biggest decision in here is that the packet number of the response to a RETRY is 1. Based on interop experience, I believe this is the semi-consensus of implementers.
Should there be normative text mandating that the packet number be increased?
I think we need a new issue on that. The information about this is scattered around issuing CID's, path validation, retransmission of Initial. It would be good with a clear statement of when the packet number starts counting. I also believe that there is somewhere text to the effect that a CID cannot have the same PN twice, but that does not apply to Retry.
Change:
6.1. <del> When trying to follow typical IP routing, the simplest approach is to bind() the sockets used for peer-to-peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic.  STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. </del> <ins> When trying to follow typical IP routing, as required by Modes 2 and 3, the simplest approach is to bind() the sockets used for peer-to- peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic.  STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. </ins> 6.2. When binding to a wildcard address, some extra work is needed to <del> determine a suitable host candidate, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing). Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). </del> <ins> determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). </ins> First, the appropriate remote IPv4/IPv6 address is obtained by resolving the host component of the web application URI RFC3986.  If

Discussion:
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
Change:
A participant that is included in the shared state of a group, and has access to the group's secrets. <del> A short-lived Diffie-Hellman key pair used to introduce a new member to a group.  Initialization keys are published for individual participants (UserInitKey). </del> <ins> A short-lived HPKE key pair used to introduce a new member to a group.  Initialization keys are published for individual participants (UserInitKey). </ins> <del> A short-lived Diffie-Hellman key pair that represents a group member's contribution to the group secret, so called because the </del> <ins> A short-lived HPKE key pair that represents a group member's contribution to the group secret, so called because the </ins> participants leaf keys are the leaves in the group's ratchet tree. A long-lived signing key pair used to authenticate the sender of a

Discussion:
I'm approving these changes given the current state of the document, but I filed because the KDF stuff is broken. Please make HPKE a normative reference (since it's required to implement). Since it's an Internet-Draft, you don't need to add it to the references section, you can just reference it directly as and the Markdown processor will add the reference. (Change the to for an informative reference.)
Change:
permissible based on the Selection Properties passed by the application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no <del> longer available.  If the Protocol Stack includes a transport protocol that does not support multipath, but support migrating between paths, the update to available paths can be used as the trigger to migrating the connection.  For protocols that do not support multipath or migration, the Protocol Instances may be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable.  An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected. </del> <ins> longer available.  Pooled Connections pooled-connections may add or remove underlying transport connections in a similar manner.  If the Protocol Stack includes a transport protocol that does not support multipath, but support migrating between paths, the update to available paths can be used as the trigger to migrating the connection.  For protocols that do not support multipath or migration, the Protocol Instances may be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable.  An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected. </ins> 7.

Discussion:
This is a follow-up issue for – As we have the ready to support connection coalescing and connection pooling, we have to describe it more closely in the Implementation.
Thanks for the fixes - I think this can be merged now.LGTM And: thanks for doing this! This can make the transport system a lot more powerful, and it's good to tell people about these interesting implementation options this draft, IMO.
Change:
disabled by the server.  It SHOULD retry the handshake with a new transport connection and ECH disabled. <del> [[TODO: Key replacement is significantly less scary than saying that ECH-naive servers bounce ECH off.  Is it worth defining a strict mode toggle in the ECH keys, for a deployment to indicate it is ready for that? ]] </del> Clients SHOULD implement a limit on retries caused by "ech_retry_request" or servers which do not acknowledge the "encrypted_client_hello" extension.  If the client does not retry in

Discussion:
The misrouting content no longer applies since the backend server sees the full CH, with the true SNI.
Change:
deployment in satellite systems. X1 embodies the source coding techniques that could be used at <del> application level for instance within QUIC or other video streaming applications.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </del> <ins> application level for instance within QUIC.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </ins> X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited).

Discussion:
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR
Change:
specifying unidirectional communication may cause a transport stack that supports bidirectional communication to be selected. <del> 5.2.14. </del> <ins> 5.2.15. </ins> Name: :retransmit-notify

Discussion:
Address
API should allow a preconnection property to specify if a private (IPv6) address is preferred. Outbound connections should prefer this. Listeners should avoid this.
Thank you! I was really missing this one .LGTM!
Change:
application.  This requires the implementation to understand where messages end, either via a supplied deframer or because the top-level protocol in the established Protocol Stack preserves message <del> boundaries; if, on the other hand, the top-level protocol only supports a byte-stream and no deframers were supported, the application must specify the minimum number of bytes of Message content it wants to receive (which may be just a single byte) to control the flow of received data. </del> <ins> boundaries.  If the top-level protocol only supports a byte-stream and no framers were supported, the application can control the flow of received data by specifying the minimum number of bytes of Message content it wants to receive at one time. </ins> If a Connection becomes finished before a requested Receive action can be satisfied, the implementation should deliver any partial

Discussion:
As described in , I removed the condition that requires the application to specify the length upon receiving from this example.
Impl draft section 5.2 Receiving Messages: "if, on the other hand, the top-level protocol only supports a byte-stream and no deframers were supported, the application must specify the minimum number of bytes of Message content it wants to receive (which may be just a single byte) to control the flow of received data." This text says the application MUST specify minIncompleteLength, however, the API draft says that this values is optional. This should be further clarified and more guidance given in case the value is not set.
Having looked at this and the API carefully, my suggestion would be to turn the semicolon preceding this statement into a full stop and remove all of this "if, on the other hand, ...." text in the implementation draft.
WFM.
This was a long text block - I had a few editorial NiTs you may like to address.
Change:
An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs.  Endpoints store received <del> connection IDs for future use.  An endpoint uses the active_connection_id_limit transport parameter to advertise the number of connection IDs it can store for future use.  An endpoint SHOULD NOT provide more connection IDs than the peer's limit.  If an endpoint has provided its peer with the maximum number of connection IDs, it SHOULD only provide a new connection ID when the peer retires one.  An endpoint MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs (see reset-token). </del> <ins> connection IDs for future use and advertise the number of connection IDs they are willing to store with the active_connection_id_limit transport parameter.  An endpoint SHOULD NOT provide more connection IDs than the peer's limit. An endpoint SHOULD supply a new connection ID when it receives a packet with a previously unused connection ID or when the peer retires one, unless providing the new connection ID would exceed the peer's limit.  An endpoint MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs; see reset-token. </ins> An endpoint that initiates migration and requires non-zero-length connection IDs SHOULD ensure that the pool of connection IDs

Discussion:
Reword the text to be a bit more clear about what's expected from a CID issuer.
I believe this is editorial, since it does not change any normative text.
This inverts the form of the recommendation, but doesn't really change the design.
We previously had text: In adding text for the TP (activeconnectionid_limit), we kept the same idea, but lost a little bit of the text: We still need the SHOULD replace used CIDs in the event that we haven't provided the peer with the maximum number of CIDs.
Putting together a PR for this
Change:
stateless reset allows a peer to more quickly identify when a connection becomes unusable. <del> Packets that are matched to an existing connection, but for which the endpoint cannot remove packet protection, are discarded. </del> <ins> Packets that are matched to an existing connection are discarded if the packets are inconsistent with the state of that connection.  For example, packets are discarded if they indicate a different protocol version than that of the connection, or if the removal of packet protection is unsuccessful once the expected keys are available. </ins> Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, MAY be discarded.  An endpoint MUST generate a

Discussion:
by discarding packets which are "inconsistent with the state of the connection." Previously, this was only a failure to remove packet protection; incorrect version is added as another example inconsistency. Note that this phrasing doesn't rule out upward-VN like , since receiving an expected upgrade is not inconsistent with your local state.
I'm wondering if there is a difference between failed decryption and version number. If the versions differ, it doesn't really make sense to try to read a subsequent coalesced packet, unless you want to do trial and error since the concepts of coalescing and length fields are not defined in the general case. Even if you understand the version, two version can not (or should not?) exist in the same datagram. If packet protection fails on the same version, it might just be a timing issue, or the (to me) dreaded path probe with prefixed knowingly invalid handshake.
That's an interesting question. The Length field is version-specific. If you include it, you can have no expectation that a peer which doesn't speak that version will even be able to find anything further in the datagram -- as far as it knows, the remainder of the datagram is that connection. But that actually has a potential use. On receipt, if the logic first attempts to chunk up the datagram and the subsequent packet is the correct version for the connection, then acknowledging that second coalesced packet implies that you support the first packet's version.
Change:
D.ietf-ice-trickle, Section 4, is only included if such an option was present in the offer. <del> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one referenced RtpTransceiver, a group of type "LS" MUST be added that contains the mid values for each RtpTransceiver added with that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification.  [[OPEN ISSUE: This is still under discussion.  See: https://github.com/rtcweb-wg/jsep/issues/162.]] </del> <ins> The next step is to generate session-level lip sync groups as defined in RFC5888, Section 7.  For each group of type "LS" present in the offer, determine which of the local RtpTransceivers identified by that group's mid values reference a common local MediaStream (as specified in the addTrack and addTransceiver methods).  If at least two such RtpTransceivers exist, a group of type "LS" with the mid values of these RtpTransceivers MUST be added.  Otherwise, this indicates a difference of opinion between the offerer and answerer regarding lip sync status, and as such, the offered group MUST be ignored and no corresponding "LS" group generated. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For

Discussion:
Replaces URL
NAME this just flattens all the changes in last PR to the final thin and puts it onto new base with no merge issue. Still needs changes to align with new sender / receiver objects
PTAL
LGTM
LGTM
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> [[TODO: Clean up this glossary]] </del> The following terms are used: <del> Aggregation function: The function computed over the users' inputs. Aggregator: An endpoint that runs the input-validation protocol and accumulates input shares. Batch: A set of reports that are aggregated into an output. Batch size: The minimum number of reports in a batch. Batch window: The minimum time difference between the oldest and newest report in a batch (in seconds). Client: The endpoint from which a user sends data to be aggregated, e.g., a web browser. Collector: The endpoint that receives the output of the aggregation function.  It also specifies the parameters of the protocol. False input: An input that is valid, but incorrect.  For example, if the data being gathered is whether or not users have clicked on a particular button, a client could report clicks when none occurred. Input: The measurement (or measurements) emitted by a client, before any encryption or secret sharing scheme is applied. Input share: one of the shares output by feeding an input into a secret sharing scheme.  Each share is to be transmitted to one of the participating aggregators. Input validation protocol: The protocol executed by the client and aggregators in order to validate the client's input without leaking its value to the aggregators. Invalid input: An input for which the input validation protocol fails.  For example, if the input is meant to be a bit vectors, then "[2, 1, 0]" is invalid. Measurement: A single value (e.g., a count) being reported by a client.  Multiple measurements may be grouped into a single protocol input. Leader: A distinguished aggregator that coordinates input validation and data collection. Output: A reduction over the inputs, for instance a statistical aggregation, which is of interest to a collector.  This is the output of the aggregation function. Output share: The share of an output emitted by an aggregator. Output shares can be reassembled by the leader into the final output. Prio v1: Mozilla's Origin Telemetry project [1]. Prio v2: Contact tracing project by Apple, Google, and ISRG. Proof: A value generated by the client and used by the aggregators to verify the client's input. Proof share: A share of a proof, used by an aggregator during the input-validation protocol. Report: Uploaded to the leader from the client.  A report contains the secret-shared and encrypted input and proof. Server: An aggregator or collector. </del> This document uses the protocol definition language of RFC8446. 2.

Discussion:
This is just converting to defn. list format. I'm going to submit a separate PR to clean up the contents.
Change:
tampering.  The component that is implicitly trusted is often referred to as a Root of Trust. <ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the following properties exists: The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the Attesting Environment(s) that collected claims about the Target Environment(s). All unprotected Evidence that is conveyed is supplied exclusively by the Attesting Environment that has the key material that protects the conveyance channel The Root of Trust protects both the conveyance channel key material and the Attesting Environment with equivalent strength protections. </ins> In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data

Discussion:
replace pull request with one we can edit. This attempts to establish the architectural basis for implicit trust as a result of links.
new text from requires some new Security Considerations text.
Change:
7.3. <del> Note that the hidden server has no way of knowing what the SNI was, </del> <ins> Note that the backend server has no way of knowing what the SNI was, </ins> but that does not lead to additional privacy exposure because the <del> hidden server also only has one identity.  This does, however, change the situation slightly in that the hidden server might previously have checked SNI and now cannot (and an attacker can route a connection with an encrypted SNI to any hidden server and the TLS </del> <ins> backend server also only has one identity.  This does, however, change the situation slightly in that the backend server might previously have checked SNI and now cannot (and an attacker can route a connection with an encrypted SNI to any backend server and the TLS </ins> connection will still complete).  However, the client is still responsible for verifying the server's identity in its certificate.

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.