jiebi/CodeConvo huggingface dataset:
Change:
TCP slow-start when restarting after idle requires multiple RTTs to re-establish a throughput at the network's available capacity. When the active transmission time for segments is substantially <del> shorter than the time between segments leaving an idle gap between segments that triggers a restart of TCP slow-start, the estimate of the successful download speed coming from the application- visible receive rate on the socket can thus end up much lower than the actual available network capacity, preventing a shift to the most appropriate bitrate.  RFC7661 provides some mitigations for this effect at the TCP transport layer, for senders who anticipate a high incidence of this problem. </del> <ins> shorter than the time between segments, leaving an idle gap between segments that triggers a restart of TCP slow-start, the estimate of the successful download speed coming from the application-visible receive rate on the socket can thus end up much lower than the actual available network capacity.  This in turn can prevent a shift to the most appropriate bitrate.  RFC7661 provides some mitigations for this effect at the TCP transport layer, for senders who anticipate a high incidence of this problem. </ins> Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a

Discussion:
This is in existing text, but I'd put a paragraph break after "Some receive-side ABR algorithms such as {{ELASTIC}} are designed to try to avoid this effect." and before "Another way to mitigate this effect is by the help of two simultaneous TCP connections, as explained in {{MMSys11}} for Microsoft Smooth Streaming. In some cases, the system-level TCP slow-start restart can also be disabled, for example as described in {{OReilly-HPBN}}."
Works for me. Updated...
The editors are 2:1 in favor of dropping ECN. Spencer is graciously in the rough. We should be talking more broadly about what happens when you lose any packets, If ECN belongs in the draft, it belongs somewhere else. "Coming improvements in transport behaviors" more broadly - we're talking about BBR and about end-to-end transport encryption now. Maybe we should talk about things like edge computing, etc ... but NAME will talk to the working group about this before we start a major refactor.
The point of these sections (4.3.1 Idle Time Between Segments and 4.3.2 Head of Line Blocking) was to explain how and why your bandwidth measurements can go wrong when you're trying to do ABR things with your bandwidth measurements. By name this seems like perhaps a better fit in the 4.4 Measurement Collection section, there might be a reason to merge some of the discussion there or reorganize the 2 sections together.
We maybe should also add a section along these lines on the wide variability in bitrates as things move, both for wi-fi and LTE and 5g. (or paths in general, with those as examples?)
Note also: "Refactor" here means provide a coherent story for why your ABR measurements can go wrong and what you can do about it.
Change:
validate each other's public value Y by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in <del> Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three </del> <ins> Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three </ins> steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve

Discussion:
The RFC editor found a few errors in a draft that used the same references. This updates the draft to use the automatically generated DOI references from URL rather than manual references. This isn't perfect, but it should help the RFC editor when it comes time to publish.
This changes: to LGTM (Dang is the author according to URL)
Change:
Certificate message.  Thus, the client will fail to decrypt the Certificate and abort the connection. <del> 10.10.2. </del> <ins> 10.11.2. </ins> This attack aims to exploit server HRR state management to recover information about a legitimate ClientHello using its own attacker-

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
4.3. <ins> HTTP/3 does not support the HTTP Upgrade mechanism (RFC7230, Section 6.7) or 101 (Switching Protocols) informational status code (RFC7231, Section 6.2.2). 4.4. </ins> Server push is an interaction mode introduced in HTTP/2 HTTP2 which permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request.  This trades

Discussion:
Is it worth adding a reference to RFC 8441? That's an alternative that covers what people looking for this functionality were probably trying to do.
That's a good point, let me craft something up and I'll update the PR soon.
Ping NAME unless you'd like me to take it over.
I'll get an update out tomorrow
I'm actually not convinced that referencing 8441 will help clarify things here because the extension is H2 specific. No H3-equivalent exists (or at least, no H3 setting to enable the equivalent CONNECT behaviour exists).
I agree. I think referencing 8441 might just add to the confusion - even if something like 8441 certainly can be introduced.
Some others have shown interest for defining/framing this capability in HTTP/3. I think that activity should consider ore broadly what text makes sense in the core document.
Fair enough. Let's merge the rebased version, then, and leave the right way to do this for an H3 extension.
HTTP/3 makes no explicit comment about this. HTTP/2 prohibits it. So I think that we might want to add equivalent text. URL informational status code ([RFC7231], Section 6.2.2). multiplexed protocol.
Change:
attacker or that the attacker is able to compromise these TLS connections. <del> The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. </del> <ins> The total number of messages affected by server key compromise can be limited by regular rotation of server keys. </ins> 6.8.

Discussion:
From NAME First and only time KeyConfig appear in the text. Section 6.7: Missing "to" after "used" Section 6.7: Remove the first "affected" Section 7: Missing "to" before prevent, remove "of"
Change:
generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client.  To allow the client to improve its RTT estimate, the new packet that it sends MUST be ack- <del> eliciting.  If Handshake keys are available to the client, it MUST send a Handshake packet, and otherwise it MUST send an Initial packet in a UDP datagram of at least 1200 bytes. </del> <ins> eliciting. </ins> Initial packets and Handshake packets could be never acknowledged, but they are removed from bytes in flight when the Initial and

Discussion:
This is what the pseudocode says, but I couldn't find anywhere in the text that clarified that if there were no ack-eliciting packets to arm PTO from, use Now().
Change:
picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If <del> downscaling cannot be applied, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. </del> <ins> downscaling cannot be applied, the attribute MUST NOT be used. </ins> If the encoder resolution is less than the minimum size permitted <del> by the attribute, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application; the encoder MUST NOT apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. </del> <ins> by the attribute, the attribute MUST NOT be used; the encoder MUST NOT apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. If the encoder resolution is within the maximum and minimum sizes, no action is needed. </ins> 3.7.

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:
If it occurs as a "filter-path" in an existence test, the function is defined to have result type "OptionalNodes" or one of its <ins> subtypes, or to have result type "OptionalBoolean" or one of its </ins> subtypes. If it occurs as a "comparable" in a comparison, the function is

Discussion:
Now we have switched to using function extensions for regexp filter matches, the current syntax requires the result to be compared against a boolean, as shown in this example from PR 330: This is consistent with the following statement in the "Existence Tests" section of the spec: If we wanted the following syntax to act as a regexp test: we would have to allow a function expression (returning a boolean result) to be treated as a (rather than an or a ). This would require (a) considerable rework of filter selectors and (b) making a special case of functions which return booleans. To be clear: I am not in favour of such a change. The reason for raising this issue was so that it doesn't come as a surprise to the WG. Thanks to NAME who spotted it when reviewing some draft input to PR 330.
This was fixed by the above PR.
Excellent!
Change:
intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP. <ins> observing updates RFC7641 for use with CoAP over reliable transports. RFC7641 is an extension to the CoAP core protocol that enables CoAP clients to "observe" a resource on a CoAP server.  (The client retrieves a representation of a resource and registers to be notified by the server when the representation is updated.) </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should.
URL Appendix A. Updates to RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) This needs to be referenced from the main body in some form.
Change:
when they receive the KeyPackage in an Add proposal. The field "leaf_node.capabilities" indicates what protocol versions, <del> ciphersuites, protocol extensions, and non-default proposal types are supported by the client.  (Proposal types defined in this document are considered "default" and not listed.)  This information allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del> <ins> ciphersuites, credential types, and non-default proposal/extension types are supported by the client.  (Proposal and extension types defined in this document are considered "default" and not listed.) This information allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group- creation), while still only advertising one version / ciphersuite per KeyPackage. </ins> The field "leaf_node.leaf_node_source" of the LeafNode in a KeyPackage MUST be set to "key_package".

Discussion:
This PR adds a way for the members of a group to indicate the credential types they support, and how to negotiate which credential types may be used in a group.
I discussed this offline with NAME and we arrived at: We might need multiple credentials later (as I suspect) If we do that (say in an extension), we will need to update this text We should capture the general theory that covers both single- and multiple-credential cases The proposed additions here just abstract the principle of universal compatibility (which we need in a single-credential world) to one of "at least something" compatibility (which is more compatible with a multi-credential world).> The types of credential that may be used in a group is restricted to what all I think this is too restrictive if we adopt PR . I think it is between the client and its AS if all the clients need to support every credential type used in the group. If you agree with the concept, I am happy to propose slight changes.I think this makes sense.
Change:
values over odd ones until the even code points are consumed to avoid conflicts with pre standard versions of EKT that have been deployed. <ins> All new EKT messages MUST be defined to have a length as second from the last element. </ins> 5.2. IANA is requested to create a new table for "EKT Ciphers" in the

Discussion:
EKTMsgLength All EKT message other that ShortEKTField must have a length as second from the last element. This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type.
Change:
is particularly useful when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. <del> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. </del> Datagrams sent using the DATAGRAM capsule have the same semantics as datagrams sent in QUIC DATAGRAM frames.  In particular, the restrictions on when it is allowed to send an HTTP Datagram and how

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
7.6.2. <del> A sender establishes persistent congestion on receiving an </del> <ins> A sender establishes persistent congestion after the receipt of an </ins> acknowledgement if at least two ack-eliciting packets are declared lost, and: <del> all packets, across all packet number spaces, sent between these two send times are declared lost; </del> <ins> all packets, across all packet number spaces, sent between the send times of two ack-eliciting packets are declared lost; </ins> the duration between the send times of these two packets exceeds the persistent congestion duration (pc-duration); and a prior RTT sample existed when both packets were sent. <ins> These two packets MUST be ack-eliciting, since a receiver is required to acknowledge only ack-eliciting packets within its maximum ack delay; see Section 13.2 of QUIC-TRANSPORT. </ins> The persistent congestion period SHOULD NOT start until there is at least one RTT sample.  Before the first RTT sample, a sender arms its PTO timer based on the initial RTT (pto-handshake), which could be

Discussion:
Removes the word ack-eliciting in the descriptive text to persistent congestion. It also contains minor text changes in the following of that section.
I'm taking the suggested changes and this PR. Thanks, NAME !
On the mailing list Timo Völker asked some questions about persistent congestion and why it was only applicable to in-flight packets. During the explanation, I realized that it should probably be ack-eliciting packets, not in-flight. UPDATE: It already is ack-eliciting in all but one spot. I wrote PR to fix that one spot.
To have the context, I quote your explanation. I think ack-eliciting makes more sense here than in-flight. At least, I understand that for the persistent congestion detection the first and the last packet need to be ack-eliciting. But why does this have to be true for packets sent between these two ack-eliciting packets? Here is an example for the edge case. The loss of three out of 50 packets let the sender consider this a persistent congestion. In general, I don't see a real issue here. But, I would like to understand why it is helpful to ignore the fact that non-ack-eliciting packets, sent between two lost ack-eliciting packets, have been acknowledged.
This absolutely should not be in flight packets. This may not cause a major issue as it stands but it is not technically correct.
The text is largely correct(ack-eliciting, not in-flight) already, based on my reading. Unfortunately, the very first description is incorrect, which is potentially confusing, so see
Looking good, one further suggestion.
Change:
The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names <del> where one or more of the earliest labels in the ordered list are omitted (for example, a name of "www" derived from "www.example.net").  Such relative names are understood only by context. </del> <ins> where one or more of the last labels in the ordered list are omitted (for example, a domain name of "www" relative to "example.net" identifies "www.example.net").  Such relative names are understood only by context. </ins> This term and its equivalent, "hostname", have been widely used but are not defined in RFC1034, RFC1035, RFC1123, or RFC2181.  The

Discussion:
cc NAME NAME Ref 92efaf05a13690953c3123bef664fcd96d2b07c7 Ref URL :
This is an improvement over the existing text and is formally more correct, I think. That means, however, that it is technically a substantive change. I think it is not a substantive change that would make any difference to any DNSOP participant so I think this is ok without going back to the WG.
Change:
path from the updated leaf using the information contained in the Update message <del> The update secret resulting from this change is the path secret for the root node of the ratchet tree. </del> <ins> The "update_secret" resulting from this change is the "path_secret[i+1]" derived from the "path_secret[i]" associated to the root node. </ins> 9.4.

Discussion:
"The update secret resulting from this change is the path secret for the root node of the ratchet tree." is suspicious because in the derivation, the index for both the and is the same as the level of the node. It should be the "above the root" and not "for the root" (which is the one used to derive the of the root)...
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
3. <ins> This extension is only supported with TLS 1.3 and newer; if TLS 1.2 or earlier is negotiated, the peers MUST ignore this extension. </ins> This document defines a new extension type (compress_certificate(TBD)), which can be used to signal the supported compression formats for the Certificate message to the peer.  Whenever it is sent by the client as a ClientHello message <del> extension (RFC5246, Section 7.4.1.4), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates.  Note that CertificateRequest messages are not supported by TLS versions prior to 1.3. </del> <ins> extension (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates. </ins> By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use

Discussion:
We already had the understanding that no one will attempt to deploy the extension for TLS 1.2 and earlier, since it would be plagued with middlebox compatibility issues that TLS 1.3 already faces. However, it was left as supported because there was no cost to supporting it. On the list, David Benjamin has pointed out that: clients have no way to ask for "compress only in TLS 1.3" policy, meaning that they have to assume that a TLS 1.2 connection could attempt to use this extension; clients have to support certificate compression in TLS 1.2 as a result. This adds complexity for no reason, and the problem is easily solved by restricting the extension to 1.3 or higher.
:+1: LGTM
Change:
coupled and one single protocol may be exploited.  In both cases, the receiver can differentiate source packets and repair symbols.  The receiver may indicate both the number of source packets received and <del> repaired symbols that were actually useful in the recovery process of </del> <ins> repair symbols that were actually useful in the recovery process of </ins> packets. <del> QUIC may require a specific type of frame to transport such information between receiver and sender. </del> 6.3.3. The congestion control may not know what is going on in the network

Discussion:
Small changes, nothing urging, should be easy to merge if you are ok with it :-)
Change:
little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates <del> are used in a session.  In addition, administrators may also wish to control the set of ICE candidates, and so the browser SHOULD also allow control via local policy, with the most restrictive policy prevailing. </del> <ins> are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- D.shieh-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime

Discussion:
Not sure if this is done but what is there LGTM
Yes, I think this is complete.
LGTM
URL talks about browser local policy. It should make this more concrete by referring to URL as the source of this policy.
Do you see it as normatively depending on that or more just "useful implementor advice can be found in ..."
I guess it depends on what we think the purpose of the ip-handling draft is. If we think all browsers should implement this, then it should be a normative dependency. I'll make a PR as such and we can debate the details there.
I think if it is something all browser need to implement, then we probably just want to move the normative text into this draft.
I think there is enough text that it warrants being in its own document.