jiebi/CodeConvo huggingface dataset:
Change:
19.3.1. <del> The ACK Ranges field consists of alternating Gap and ACK Range values in descending packet number order.  The number of Gap and ACK Range values is determined by the ACK Range Count field; one of each value is present for each value in the ACK Range Count field. </del> <ins> Each ACK Range consists of alternating Gap and ACK Range values in descending packet number order.  ACK Ranges can be repeated.  The number of Gap and ACK Range values is determined by the ACK Range Count field; one of each value is present for each value in the ACK Range Count field. </ins> ACK Ranges are structured as shown in ack-range-format. <del> The fields that form the ACK Ranges are: </del> <ins> The fields that form each ACK Range are: </ins> A variable-length integer indicating the number of contiguous unacknowledged packets preceding the packet number one lower than

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.
Change:
section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating an m= section for the added RtpTransceiver as if the m= <del> section were being added to the session description, placed at the same index as the m= section with a zero port. </del> <ins> section were being added to the session description (including a new MID value), and placing it at the same index as the m= section with a zero port. </ins> If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it.  This

Discussion:
BLOCKER: The second bullet on page 43 ("If an RtpTranceiver has been stopped and is associated..." is normative and redundant with (and slightly contradictory to) the bullet on page 44 starting "If any RtpTranceiver has been slopped...") which is also normative. Remove one.
Looks like an editorial oversight. I'm inclined to remove the second instance. NAME as FYI
BLOCKER: The bullet at the bottom of of page 42 ("If any RtpTranceiver has been added...") is normative and redundant with the bullet in the middle of page 44 ("If any RtpTranceiver has been added..."), which is also normative. Remove one.
Agreed. Let's remove the second one. NAME as FYI
Change:
of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and "Permitted KeyPurposeId" exists, the relying party or the relying <del> party software proresses each restriction on "Excluded </del> <ins> party software processes each restriction on "Excluded </ins> KeyPurposeId" first, and then processes each restriction on "Permitted KeyPurposeId".

Discussion:
Addressing Lars' .
Debating adding more context than just "document". Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/1T23l8-kN8pEMqnQvh1ir3MsGVw). Did you mean "documents" here instead of "Internet-Drafts"? All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. File types are normally capitalized. A period is needed after the abbreviation "etc.".
Change:
signatures on the messages under identity keys. [[ OPEN ISSUE: Signatures under the identity keys, while simple, have <del> the side-effect of preclude deniability.  We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a </del> <ins> the side-effect of precluding deniability.  We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a </ins> pairwise channel that provides deniability for the message contents.]]

Discussion:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thank you!
Change:
built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. <ins> All times are relative to the local clocks, indicated by an "a" (Attester), "v" (Verifier), or "r" (Relying Party) suffix. How and if clocks are synchronized depends upon the model. </ins> 15.1. The following example illustrates a hypothetical Passport Model

Discussion:
This pull request puts _X on all time points. Please review for accuracy.
I am neutral/okay with consistently adding suffixes to every event label
Change:
6. <del> This document specifies a Reno congestion controller for QUIC RFC6582. </del> <ins> This document specifies a congestion controller for QUIC similar to TCP NewReno RFC6582. </ins> The signals QUIC provides for congestion control are generic and are designed to support different algorithms.  Endpoints can unilaterally

Discussion:
Clarifies a few points and moves the initial window recommendation from the pseudocode to the text. I could take this a bit farther, but I'd like suggestions on what's currently missing in this PR.
LGTM
It starts like this: The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section. On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be? An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.
The intent is that the text is complete without reading the referenced RFCs or pseudocode, so I think this section needs more text and possibly some inlined pseudo-code.
Hi NAME I wrote which fixes some obvious errors I found, but I think more could be done. Can you take a look and tell me what other points you'd like added or moved up from the pseudocode?
Looks good! Thanks!
Change:
10.6. <del> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the 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 connection will still complete).  However, the client is still responsible for verifying the server's identity in its certificate. [[TODO: Some more analysis needed in this case, as it is a little odd, and probably some precise rules about handling ECH and no SNI uniformly?]] 10.7. </del> Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. padding describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage. <del> 10.8. </del> <ins> 10.7. </ins> This section describes the rationale for ECH properties and mechanics as defenses against active attacks.  In all the attacks below, the

Discussion:
The misrouting content no longer applies since the backend server sees the full CH, with the true SNI.
Change:
typically different than the HBH key for the incoming packet. The receiver can check the authentication of the initial and extra <del> envelope information.  This, along with the OBH, is used to construct </del> <ins> envelope information.  This, along with the OHB, is used to construct </ins> a synthetic packet that is should be identical to one the sender created and the receiver can check that it is identical and then decrypt the original payload.

Discussion:
Make sure double can work with future FEC schemes that do HBH repair and have state that could be corrupted by non authenticated packets
resolved in latest draft
Change:
Selectors of different kinds may be combined within a single child segment. <del> The resulting nodelist of a child segment is the concatenation of the nodelists from each of its selectors in the order that the selectors appear in the list.  Note that any node matched by more than one selector is kept as many times in the nodelist. </del> <ins> For each node in the input nodelist, the resulting nodelist of a child segment is the concatenation of the nodelists from each of its selectors in the order that the selectors appear in the list.  Note that any node matched by more than one selector is kept as many times in the nodelist. </ins> Where a selector can produce a nodelist in more than one possible order, each occurrence of the selector in the child segment may

Discussion:
Add clarifications that the input nodelist provides the outer order, the segments provide a middle-level order, and selectors (if multiple) provide the inner order. This may have been obvious to some readers, but now should be obvious to more, including yours truly.
I don't think the example for in Table 17 is right. URL It says: It should be: Note that the descendants list puts out before and . The wildcard selector then has no choice but outputting , , , .
Nice catch! The example needs fixing as does the ordering note below Table 17.
I let the computer do the catching :-) Do you want to make these changes? I'd do a new issue then. (And wait a bit for Greg to catch up.)
NAME Yes, I'm happy to do that and please do create a new issue. I won't be able to fix it before the weekend at the earliest though.
URL
LGTM thanks. Semantics unchanged, but hopefully a lot clearer.
Change:
Error handling: Place a SHOULD around the likely cases, and make the previous "MUST to the best of their capabilities" a "must". <ins> Registration: Wording around "mostly mandatory" has been improved, conflicts clarified and sector default selection adjusted. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Discussion:
This also answers the repeated questions that were asked about conflicts between recognized and given ep names, and brings the wording in line with the more consistent application of the security glossary.
Change:
"illegal_parameter" alert. TLS 1.3 server implementations which respond to a ClientHello with a <del> client_version indicating TLS 1.2 or below MUST set the first eight </del> <ins> client_version indicating TLS 1.2 or below MUST set the last eight </ins> bytes of their Random value to the bytes: TLS 1.2 server implementations which respond to a ClientHello with a <del> client_version indicating TLS 1.1 or below SHOULD set the first eight </del> <ins> client_version indicating TLS 1.1 or below SHOULD set the last eight </ins> bytes of their Random value to the bytes: TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check <del> that the top eight octets are not equal to either of these values. </del> <ins> that the last eight octets are not equal to either of these values. </ins> TLS 1.2 clients SHOULD also perform this check if the ServerHello indicates TLS 1.1 or below.  If a match is found, the client MUST abort the handshake with a fatal "illegal_parameter" alert.  This

Discussion:
The sentinel value was chosen to avoid conflicting with any valid TLS 1.2 value, but this is not actually desirable. We need to avoid conflicting with any non-TLS-1.3 server but still be a valid TLS 1.2 value. A TLS 1.3 server must still correctly implement TLS 1.2 to interoperate with existing TLS 1.2 clients. In particular, placing it at the front clobbers TLS 1.2's server timestamp. Putting this in the random was silly and 1.3 rightfully removes it, but some software depends on servers sending a timestamp. The tlsdate program uses this as a secure-ish time synchronization protocol. Silly as it is, it exists and it arguably was following the letter of the TLS 1.2 spec, even if we don't like that timestamp very much... Move the sentinel to the end so servers may implement this downgrade protection (which will be needed in the short term given the current version negotiation as it forces browsers to implement the version fallback again) without breaking any tlsdate instances which may still exist.
Change:
where <del> edhoc_aead_id is an int or tstr containing the algorithm identifier of the EDHOC AEAD algorithm in the selected cipher suite encoded as defined in I-D.ietf-cose-rfc8152bis-algs.  Note that a single fixed edhoc_aead_id is used in all invocations of EDHOC-KDF, including the derivation of KEYSTREAM_2 and invocations of the EDHOC-Exporter (see exporter). </del> <ins> selected_suite is an int containing the selected cipher suite. </ins> transcript_hash is a bstr set to one of the transcript hashes TH_2, TH_3, or TH_4 as defined in Sections asym-msg2-form, asym-

Discussion:
This simplify things. The selected cipher suite also covers more than just the aead algorithm. I think the "suite = int" definition can be removed. It does not add much in the current version. In older versions suite was a more advances construction.
The selected cipher suite covers the aead and more.
selectedsuite is always included in transcripthash and could be removed. I.e. an equally secure info would be info = ( transcript_hash : bstr, label : tstr, context : bstr, length : uint, )
Agree, we can close this.
This has been merged to master.
Change:
All connection IDs use the following format: <ins> The First Octet field serves one or two purposes, as defined in first-octet. The Server ID field encodes the information necessary for the load balancer to route a packet with that connection ID.  It is often encrypted. The server uses the Nonce field to make sure that each connection ID it generates is unique, even though they all use the same Server ID. </ins> 4.2. The configuration agent assigns a server ID to every server in its

Discussion:
In (Section 4.1](URL), these fields are not defined: They probably should be.
Change:
flows, congestion controllers that are not window-based, such as BBR, can perform well with very few acknowledgements per RTT. <del> New sender startup mechanisms, such as paced chirping, will need a way for the sender to increase the frequency of acknowledgements when fine-grained feedback is required. </del> <ins> New sender startup mechanisms will need a way for the sender to increase the frequency of acknowledgements when fine-grained feedback is required. </ins> QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every

Discussion:
by removing references to slow start, hystart, and paced chirping. Slow start and BBR startup aren't quite the same as NAME mentioned, hystart isn't specified for QUIC, and paced chirping is not an IETF draft to my knowledge.
"Starting a connection up quickly without inducing much queue is important for latency reduction, for both short and long flows. The sender often needs frequent acknowledgments during this phase; see slow start and hystart." There's no description of them in this doc. Slow start is in the recovery draft, but hystart is not, so we'd have to reference a non-QUIC RFC?
Maybe paced chirping too.
An added nit to this: congestion controllers like BBR do not have a slow start / hystart phase exactly, but are still sensitive to ACKs early in the flow during "Startup". With a BBR congestion controller the ACKing interval early in the flow has a measurable effect on the time it takes to find the bottleneck bandwidth. More generally I suspect this is true of pretty much every congestion controller that's trying to find an optimal congestion window. Given that, perhaps we need more general language here about the benefit of ACKs early in a flow, and then referencing slow start and hystart specifically?
BBR has 'Startup', which is quite similar to slow start, so maybe flow startup a better general purpose term? I think we can remove the reference to hystart entirely, since I wouldn't expect decreasing ACK frequency to have a negative impact on it, particularly given QUIC's explicit ack delay.
Change:
Abstract <del> This document describes best practices for Working Groups that use GitHub for their work. </del> <ins> This document describes best practices for Working Groups that choose to use GitHub for their work. </ins> Note to Readers

Discussion:
I agreed to change from DISCUSS to Abstain if this change was made - email thread for the curious / archives: URL A PR is close enough to integrated for me...
NAME I'm curious why this change is adequate; it's effectively just a rewording. It doesn't address the issue of the group choosing to adopt the policies.
NAME Yes, it is just a rewording -- but (for me at least) it made it enough clearer that this was optional (WGs can choose to use GH, not WGs are expected to use GH) that I was willing to move to Abstain instead. The WG has consensus, and the charter sent us down the "GH FTW!" path - it isn't appropriate for me to block this just because I don't like it / think there is a better way of using RCS tooling / GH. The process was followed, and the document is valuable - I don't like the tone, I don't like the implication, but it now falls into the "Well, that's just, like, your opinion, man..." territory. (There isn't a technical objection, nor do I think it is specifically dangerous to the IETF / IETF stream, so...)
NAME - OK. This is made moot by the other changes that Martin made to the draft, but to be clear, I don't think that's a good line of argumentation. The WG was charted to an explicit scope - that WGs had to opt into the practices it documented. If it were producing a document that exceeded that scope (which is arguably did before the recent change referenced above), saying that the WG "has consensus" to violate its charter is meaningless, and letting that stand is damaging. That's because charters allow people to decide whether or not they're going to follow a WG. If a WG can violate its charter and justify that with "but we had consensus to do so", charters are meaningless, and the check that requiring IETF consensus places upon WGs is seriously diminished. Thank you -- I would even be OK with just changing to Abstract to be: "This document describes best practices for Working Groups that choose to use GitHub for their work." and leave it as BCP. Would that work better for everyone?

It would be enough for me to no longer feel that this is saying that WGs using GitHub is a BCP, but rather that if a WG decided to use GitHub, this is the best way to do so (I'm still not sure that this really is the best way, but that's just my opinion, and I'm OK being in the rough) W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Change:
semantics of datagrams associated with this stream.  Its Capsule Data field consists of: <del> A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. </del> <ins> See context-ext. </ins> Note that this registration is unilateral and bidirectional: the client unilaterally defines the semantics it will apply to the

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks
Change:
flow is using QUIC based upon a UDP port number may therefore not hold; see also RFC7605 section 5. <ins> While the second most significant bit (0x40) of the first octet is always set to 1 in QUIC packets of the current version, this is not a recommended method of recognizing QUIC traffic, as it only provides one bit of information and is quite prone to collide with UDP-based protocols other than those that this static bit is meant to allow multiplexing with. </ins> 3.1.1. An in-network observer assuming that a set of packets belongs to a

Discussion:
Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.
Change:
An Application combines its ECDH private key with the public key provided by the User Agent using the process described in ECDH; on receipt of the push message, a User Agent combines its private key <del> with the public key provided by the Application Server in the "dh" </del> <ins> with the public key provided by the Application Server in the "keyid" </ins> parameter in the same way.  These operations produce the same value for the ECDH shared secret.

Discussion:
/cc NAME Not sure about "parameter of that same header" phrasing. Not a fan of duplicating the text about the content coding header either. Suggestions?
Yep, these are both correct. Thanks.