jiebi/CodeConvo huggingface dataset:
Change:
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer. <ins> 3.2.4. The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix.  This capsule uses a Capsule Type of 0xfff103.  Its value uses the following format: IP Version of this route withdrawal.  MUST be either 4 or 6. IP address of the withdrawn route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. The number of bits in the IP Address that are used to define the prefix of the withdrawn route.  This MUST be lesser or equal to the length of the IP Address field, in bits. The Internet Protocol Number for traffic for this route.  If the value is 0, all protocols are withdrawn for this prefix. Upon receiving the ROUTE_WITHDRAWAL capsule, an endpoint MUST stop routing IP packets in that prefix to its peer.  Note that this capsule can be reordered with DATAGRAM frames, and therefore an endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. </ins> 4. IP packets are sent using HTTP Datagrams I-D.ietf-masque-h3-datagram.

Discussion:
The current version of the draft contains the ROUTEADVERTISEMENT capsule but is missing the ROUTEREJECTION capsule. It's very common for networks to want to advertise routes such as "I can handle all of IPv4 space minus RFC 1918 space" and that becomes incredibly painful if you don't have a way to subtract prefixes. An alternate solution is to use an address start/address end encoding like , but if we want to use a prefix-based encoding we need a way to cut out holes from prefixes.
Oh, is that what the rejection capsule was for? I guess I'd just rather have the route advertisement itself provide a list of exceptions, rather than tying it to a separate capsule?
Yes, that would also work. This is just a matter of encoding.
The nice thing about the rejection capsule is it allows you to remove announcements that were previous present without having to re-send a full routing table. I would prefer keeping it, as it allows for more efficient transmission of information. (I disagree it's just a matter of encoding.)
Actually sending a full routing table seems like the safer way to go. And given you don’t do that very often, I don’t think we need to worry about overhead.
I will disagree with my co-author. I think the basic case for what in most cases are the equivalent to the default route for a host on a LAN segment would be good to have in a reasonable compact form. I think the question to ask here is if we in general need a mechanism to specify an IP prefix with one or more carved out sub-prefixes. I that requirement may apply to both advertising and rejecting/removing a prefix. In the removing maybe it is possible to specify the whole prefix without carve out sub-prefixes.
Maybe call with ROUTE_WITHDRAW instead of reject
ROUTE_WITHDRAW sounds good to me.
Change:
resolution when needed, or may be locked to a specific output resolution. <del> For each encoding being produced by the RtpSender, the following rules are applied to determine what should be transmitted: First, the most suitable "a=imageattr recv" attribute is selected. This is performed by taking the attribute with the highest "q=" value from the set of attributes that reference the media format that has been selected for the specified encoding.  If multiple attributes have the same "q=" value, the one that appears first in the m= section is used.  Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. If there is an applicable "a=imageattr recv" attribute for the encoding, the limits from the attribute are then compared to the encoder resolution.  Only the specific limits mentioned below are </del> <ins> For each encoding being produced by the RtpSender, the set of "a=imageattr recv" attributes in the corresponding m= section of the remote description is processed to determine what should be transmitted.  Only attributes that reference the media format selected for the encoding are considered; each such attribute is evaluated individually, starting with the attribute with the highest "q=" value.  If multiple attributes have the same "q=" value, they are evaluated in the order they appear in their containing m= section.  Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. For each "a=imageattr recv" attribute, the following rules are applied.  If this processing is successful, the encoding is transmitted accordingly, and no further attributes are considered for that encoding.  Otherwise, the next attribute is evaluated, in the aforementioned order.  If none of the supplied attributes can be processed successfully, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. The limits from the attribute are compared to the encoder resolution.  Only the specific limits mentioned below are </ins> considered; any other values, such as picture aspect ratio, MUST be ignored.  When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the

Discussion:
Still LGTM
NAME we have consensus on this from the editor team, but please comment here if you see anything else and I'll take a look.
Thanks, I think it looks good in general. Regarding the "par" question NAME raised the current text promotes some picture over correct picture aspect ratio. Having a bullet that one selects one that has PAR that the sending side supports to send can result in more optimal choice but also may result in a slight increase in blocked video where a stretched video may be shown instead.
Change:
with the example resource look-up locations discovered in example- discovery: <ins> The same lookup using the CBOR Link Format media type: </ins> The following example shows a client performing an endpoint type lookup:

Discussion:
See individual commit messages
As we support the alternative serializations from draft-ietf-core-links-json, I'd like to add at least the numbers in the RD lookup examples.
Use TBD64 etc., as discussed in the call.
Change:
4.7. QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's <del> RTO computation.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout.  QUIC does not collapse the congestion window until persistent congestion (persistent-congestion) is declared, unlike TCP, which collapses the congestion window upon expiry of an RTO.  Instead of collapsing the congestion window and declaring everything in-flight lost, QUIC allows probe packets to temporarily exceed the congestion window whenever the timer expires. In doing this, QUIC avoids unnecessary congestion window reductions, </del> <ins> RTO computation; see RFC6297.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout. Similar to the RACK-TLP loss detection algorithm for TCP (RACK), QUIC does not collapse the congestion window when the PTO expires, since a single packet loss at the tail does not indicate persistent congestion.  Instead, QUIC collapses the congestion window when persistent congestion is declared; see persistent-congestion.  In doing this, QUIC avoids unnecessary congestion window reductions, </ins> obviating the need for correcting mechanisms such as F-RTO (RFC5682). Since QUIC does not collapse the congestion window on a PTO expiration, a QUIC sender is not limited from sending more in-flight

Discussion:
and part of
Alissa Cooper said:
NAME said:
Good point, also 4.7 currently has TLP in the title, but doesn't use it anywhere else in the section, so I'll add some text on TLP too. URL
Please also update the RACK reference to version 14. draft-ietf-tcpm-rack-14
The version update is part of the toolchain we use, so the newest version of RACK should be referenced automatically.
Change:
Multiple QUIC packets may be coalesced into a UDP datagram, with a datagram carrying one or more long header packets followed by zero or one short header packets.  When packets are coalesced, the Length <del> fields in the long headers are used to separate QUIC packets.  The length header field is variable length and its position in the header is also variable depending on the length of the source and destination connection ID.  See Section 4.6 of QUIC-TRANSPORT. </del> <ins> fields in the long headers are used to separate QUIC packets; see Section 12.2 of QUIC-TRANSPORT.  The length header field is variable length, and its position in the header is also variable depending on the length of the source and destination connection ID; see Section 17.2 of QUIC-TRANSPORT. </ins> 2.3.

Discussion:
The ops drafts often reference the core drafts by section number; make sure these section number references are correct for the WGLC drafts.
Correcting overcorrections regarding capitalization, but this seems benign.
Change:
introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry keys to identify clients. <del> If none of the values provided in "retry_keys" contains a supported version, the client can regard ECH as securely disabled by the server.  As below, it SHOULD then retry the handshake with a new </del> <ins> If none of the values provided in "retry_configs" contains a supported version, the client can regard ECH as securely disabled by the server.  As below, it SHOULD then retry the handshake with a new </ins> transport connection and ECH disabled. If the field contains any other value, the client MUST abort the

Discussion:
Addresses
The spec uses both and when referring to the contents of . These should be made consistent (preferably using the former).
Agreed -- let's unify around ! Would you be able to propose text?
( is a remnant of the old name. I guess we missed a few.)
Thanks!
Change:
A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4) <del> "The resolver is located on the same machine as the program that requests the resolver's services, but it may need to consult name servers on other hosts."  (Quoted from RFC1034, Section 5.1) A resolver performs queries for a name, type, and class, and </del> <ins> A resolver performs queries for a name, type, and class, and </ins> receives answers.  The logical function is called "resolution". In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding

Discussion:
There is one typo at "Authoritative data:". Other differences are OK. | , Section 2, defines "Authoritative RRset" which is related | to authoritative data [bu] has a more precise definition. ("bu"is "but" ?)
I missed to change branch and I commited to this branch. please review "f172affe0f5d111af23f8c48f9ed5715e7b314d0".
Change:
This structure is intended to prevent an attack on previous versions of TLS in which the ServerKeyExchange format meant that attackers <del> could obtain a signature of a message with a chosen, 32-byte prefix. The initial 64 byte pad clears that prefix. </del> <ins> could obtain a signature of a message with a chosen 32-byte prefix (ClientHello.random).  The initial 64 byte pad clears that prefix. </ins> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client <del> CertificateVerify". </del> <ins> CertificateVerify".  It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </ins> For example, if Hash(Handshake Context + Certificate) was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by

Discussion:
minor additions, the context string wasn't explained anywhere as well so I thought a mini-line would help.
Change:
amount of redundancy to add, as a function of the transport layer protocol and application requirements. <del> For the FEC within transport case, the addition of coding may hide congestion losses and proposing methods to signal such events to end point could be propose. </del> <ins> For the FEC within transport case, recovering lost symbols may hide congestion losses to the congestion control.  Some existing solutions already propose to disambiguate acked packets from rebuilt packets QUIC-FEC.  New signalling methods and FEC-recovery-aware congestion controls could be proposed. </ins> For the FEC below transport case, there are opportunities for introducing interaction between congestion control and coding schemes

Discussion:
Added some precisions on the research section. When authors improve throughput by hiding the congestion signal, I propose to compare using FEC to hide the congestion signal with replacing the current congestion control by one that similarly ignores the loss signal without using any FEC. Concerning the solutions proposing to disambiguate the ACKs from the recoveries, I cited QUIC-FEC. We should also cite TENTET. NAME do you have a reference of an article about TENTET ? Do not hesitate to suggest changes before merging.
That looks very fine to me! We may just be missing the reference to tentet before merging the branch
Change:
is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re- <del> ordering than traditional TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </del> <ins> ordering than typical TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </ins> Note that the 5-tuple of a QUIC connection can change due to migration.  In this case different flows are observed by the path and

Discussion:
Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" Term "invalid"; alternatives might be "not valid", "unenforceable", "not binding", "inoperative", "illegitimate", "incorrect", "improper", "unacceptable", "inapplicable", "revoked", "rescinded"
Change:
normal SRTP or SRTCP processing takes place including replay protection. <del> 2.2.2.1. </del> <ins> 2.3. </ins> The value of the EKTCiphertext field is identical in successive packets protected by the same EKT parameter set and the same SRTP

Discussion:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
Change:
When the server responds with an error status, it SHOULD provide additional information using problem document I-D.ietf-appsawg-http- <del> problem.  The "type" and "detail" fields MUST be populated.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): </del> <ins> problem.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): </ins> This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers

Discussion:
These fields are not required by draft-ietf-appsawg-http-problem-03.
Change:
However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP and be serialized out to SDP.  If future <del> specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. </del> <ins> specifications agree on a JSON format for session descriptions, this object could be enhanced to generate and consume that JSON. </ins> As detailed below, most applications should be able to treat the SessionDescriptions produced and consumed by these various API calls <del> as opaque blobs; that is, the application will not need to read or change them. </del> <ins> as opaque blobs; that is, the application will not need to parse or understand them. </ins> 3.4. In order to give the application control over various common session parameters, JSEP provides control surfaces that tell the JSEP <del> implementation how to generate session descriptions.  This avoids the need for JavaScript to modify session descriptions in most cases. </del> <ins> implementation how to generate session descriptions.  In most cases, this removes the need for applications to modify session descriptions after they are created. </ins> Changes to these objects result in changes to the session descriptions generated by subsequent createOffer/createAnswer calls.

Discussion:
Explain more about use of max-bundle by implementations Explain sess-id limits Remove use of "we" throughout
Change:
aborts the connection with a "decrypt_error" alert rather than continuing the handshake with the second ClientHelloOuter. <ins> When decrypting the second ClientECH.payload, the client-facing server performs a corresponding process to client-hrr: ClientHelloOuterAAD is computed from the second ClientHelloOuter as described in authenticating-outer.  The "info" parameter to SetupPSKR is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig. </ins> [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified integration with the backend server.  Stateful HRR on the client-

Discussion:
Now that we have separate client HRR and server HRR sections, move some server text to the server section. Also clarify that the second ClientHelloOuterAAD is computed from the second ClientHelloOuter, not reusing the first value. (Some cleanup in advance of writing up the HPKE context reuse version.)
Can we merge this? The number of PRs is getting confusing. NAME
Change:
With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns.  In order to prevent this, implementations SHOULD attempt to use fresh connection IDs whenever they change local addresses or ports (though this is not always possible to detect). </del> <ins> privacy concerns. </ins> Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a

Discussion:
This is pretty trivial, but the first use of CID in the draft isn't mated to the expanded "connection ID". Probably more seriously, that first mention is actually to cite a struct: The structure is called .
Change:
Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with its AggregateInitializeReq message as the payload.  The media type is <del> "message/dap-aggregate-initialize-req". </del> <ins> "application/dap-aggregate-initialize-req". </ins> 4.4.1.2.

Discussion:
In IANA all media types seem to be of "application" type instead of "message" type, this PR is to align the mismatch in the protocol description and adapt to the media types specified in IANA.
Nice catch!
Change:
3.1.3. <del> It is typically expected for users within Group to own different </del> <ins> It is typically expected for users within a Group to own different </ins> devices. <del> A new device can be added to a group by sharing of an existing client secrets or be considered as a new client by the protocol.  This client will not gain access to the history even if it is owned by someone who owns another member of the Group.  Restoring history is typically not allowed at the protocol level but applications can </del> <ins> A new device can either be added to a group by sharing secrets of an existing client or be considered as a new client by the protocol. This client will not gain access to the history even if it is owned by someone who owns another member of the Group.  Restoring history is typically not allowed at the protocol level but applications can </ins> elect to provide such a mechanism outside of MLS. 3.1.4.

Discussion:
There were some odd formulations in section 3.1.3. I hope I addressed those issues without changing the intended meaning.