jiebi/CodeConvo huggingface dataset:
Change:
Negative caching Negative response Next closer name <ins> Non-recursive query </ins> O OPT

Discussion:
…erative resolution
Agree with your fix to the definition.
During the lead-up to RFC 7719, Tony Finch asked for four terms to be defined: Recursive query Non-recursive query Iterative query Iterative resolution The were not in RFC 7719 but could be in the -bis.
Updated the document in URL
I don't think iterative query is a synonym. I think an iterative query is a non-recursive query that happens to be a query in a series of recursive queries but that is itself not a recursive query. No? That seems more consistent with the iterative resolution definition that follows.
Change:
Message by passing the same MessageContext, until the endOfMessage flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does <del> not support delivering discontiguous partial Messages. </del> <ins> not support delivering discontiguous partial Messages.  If, for example, Message A is divided into three pieces (A1, A2, A3) and Message B is divided into three pieces (B1, B2, B3), the ReceivedPartial may deliver them in a sequence like this: A1, B1, B2, A2, A3, B3, because the messageContext allows the application to identify the pieces as belonging to Message A and B, respectively. However, a sequence like: A1, A3 will never occur. </ins> If the minIncompleteLength in the Receive request was set to be infinite (indicating a request to receive only complete Messages),

Discussion:
says: What happens if a ReceivedPartial event is dispatched on an unreliably connection, but the rest of the message never shows up? Is it the case that another call to Receive will result in two events being sent: Received (or ReceivedPartial) for the new message, and a ReceiveError for the original message? Or can two messages effectively be interleaved and delivered in whatever order the constituent packets arrive?
Could you elaborate on the error case that's on your mind? Because it's unclear to me - I would say that ordering obviously needs to be preserved within a message, while inter-message ordering is a different issue (controlled by the msgOrdered Message Parameter). How is this not clear from saying that delivering discontiguous partial Messages is not supported?
Let's say you send the following: M1 M2 M3 N1 N2 N3 where M=M1.M2.M3 is one message and N=N1.N2.N3 is another message. The receiver subsequently gets: M1 N1 N2 N3 My reading of the draft is that the receiver will see ReceivedPartial ReceivedPartial ReceivedPartial Received If M2 and M3 subsequently arrive, it sounds like the receiver will never get ReceivedPartial or Received because "this event does not support delivering discontiguous partial Messages." But what makes the receiving TAPS logic decide not to wait for M2 or M3 and to start delivering N?
This is not how I would have interpreted the sentence. It talks about the message itself being discontiguous - so, e.g., delivering M1 followed by M3 would never happen. I don't see a reason why a different message couldn't be delivered, in pieces or not, after a ReceivedPartial call - every receive call comes with a message context, so the messages can be separated. I can try to make this clearer, maybe by adding an example like yours here to the draft....
Change:
(AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME, Section 2.2), as shown in the figure below. <del> Issuers provide a Private and Public Key, denoted "skI" and "pkI" respectively, used to produce tokens as input to the protocol.  See issuer-configuration for how this key-pair is generated. </del> <ins> This section describes a variant of this issuance protocol for producing privately verifiable tokens using the protocol in OPRF.  In particular, this variant of the issuance protocol uses the OPRF(P-384, SHA-384) ciphersuite. In this variant, Issuers provide a Private and Public Key, denoted "skI" and "pkI" respectively, used to produce tokens as input to the protocol.  See issuer-configuration for how this key-pair is generated. </ins> Clients provide the following as input to the issuance protocol:

Discussion:
This link is broken in a few ways. Note that the links has an trailing period in it, which is only part of the problem there; there is no Section 5.1.2 or Section "5.1.2.". Also, the function is called "BlindSign" in that version of the draft.
In the issuance protocol draft, there are a few places where it is assumed that a value will be a certain length, but no effort has been made to explicitly set a length. In : Is the 0x0002 two octets? Sure, you might readily assume that, but nothing says that explicitly. The same assumption appears in Sections 5.1 and 5.5.
Change:
5.2. The Media Distributor has the part of the key for the outer (hop-by- <del> hop), but it does not have the part of the key for the (end-to-end) cryptographic algorithm.  The cryptographic algorithm and key used to decrypt a packet and any encrypted RTP header extensions would be the same as those used in the endpoint's outer algorithm and key. </del> <ins> hop) cryptographic algorithm, but it does not have the part of the key for the (end-to-end) cryptographic algorithm.  The cryptographic algorithm and key used to decrypt a packet and any encrypted RTP header extensions would be the same as those used in the endpoint's outer algorithm and key. </ins> In order to modify a packet, the Media Distributor decrypts the <del> packet, modifies the packet, updates the OHB with any modifications not already present in the OHB, and re-encrypts the packet using the cryptographic using the outer (hop-by-hop) key. </del> <ins> received packet, modifies the packet, updates the OHB with any modifications not already present in the OHB, and re-encrypts the packet using the the outer (hop-by-hop) cryptographic key before transmitting. </ins> 5.3.

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
these labels provides key separation between QUIC and TLS; see key- diversity. <ins> Both "quic key" and "quic hp" are used to produce keys, so the Length provided to HKDF-Expand-Label along with these labels is determined by the size of keys in the AEAD or header protection algorithm.  The Length provided with "quic iv" is the minimum length of the AEAD nonce, or 8 bytes if that is larger; see AEAD. </ins> The KDF used for initial secrets is always the HKDF-Expand-Label function from TLS 1.3; see initial-secrets.

Discussion:
This was a pretty serious omission, even if it was obvious enough that no one ever noticed when implementing it.
NAME said:
The Context thing should be addressed by . The 4 bits should be "Unused" to match the transport spec. I'll fix that.
NAME said:
Oh, so many things to unpack from a short comment... Yes, Context should be explicitly empty. I'll create a PR for this and the other, below. The TLS transcript is integrated into the derivation of the keys that we use, so we don't need to include it again. As an aside, EAP-TLS1.3 use of 0x0D in the exporter is counter to the intended use of the field. They already have all the fixed key separation necessary through the use of the exporter label. The field is intended to capture variable, contextual information such as identities or other things that are not already folded into the handshake. I agree that using a different span of the handshake transcript for key derivation would be massively disruptive, that is why I would oppose doing that. As with Context, so too with Length, though that requires a little more text to address. That's in the PR too. Note: I had to decide between NMAX and NMIN and chose N_MAX. Though the values are the same for all of the AEADs we use, that isn't guaranteed. I'm sure that an AEAD with variable-length nonce could manage, but no sense in being imprecise. I want nothing to do with Derive-Secret. That's too far into TLS internals.
I think that the separation that we have now is good and that we do not need to change the design. Regarding IV length, as stated in the PR review comment, we are using TLS cipher-suites. Therefore I think we should be using what is defined in TLS 1.3 (i.e. ) rather than specifying a different rule.
Change:
RFC8701 "encrypted_client_hello" extension in the first ClientHello as follows: <del> Set the "config_id" field to a random eight byte string. </del> <ins> Set the "config_id" field to a random byte. </ins> Set the "cipher_suite" field to a supported HpkeSymmetricCipherSuite.  The selection SHOULD vary to exercise

Discussion:
accidentally targeted an older branch that was since merged into master. This just takes the same change and redirects it to the main branch.
Change:
"AggregateContinueReq.task_id"'s parameters except its own, the leader sends a POST request to "[aggregator]/aggregate" with AggregateContinueReq as the payload and the media type set to <del> "message/ppm-aggregate-continue-req".  In addition, this request MUST </del> <ins> "message/dap-aggregate-continue-req".  In addition, this request MUST </ins> be authenticated as described in https-sender-auth. 4.3.2.2.

Discussion:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.
Change:
A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519) <del> A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability </del> <ins> A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities such as Claims collection and Evidence signing </ins> An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence

Discussion:
Suggested new text for Endorsements definition to make it slightly more broad, but constrained to the operations of an Attesting Environment (which is a subset of an Attester that also might contain Target Environments and other environments) which is focus for why a Verifier cares to get Endorsements.
This now aligns excellently with the overall terminology. Unfortunately, this now uses a term that is well-defined in section 4.2., but not included in the "upfront" terminology section. This is fine text! But it might now impliy the addition of Attesting Environment into this section.
Change:
ODCIL: The length of the original destination connection ID from the triggering Initial packet.  This is in cleartext to be readable for <del> the server, but authenticated later in the token. </del> <ins> the server, but authenticated later in the token.  The Retry Service SHOULD reject any token in which the value is less than 8. </ins> RSCIL: The retry source connection ID length.

Discussion:
and
Thanks Christian, Your comments ended up as an editorial rewrite of the section, with port verification added.
The diagrams indicate they are in the range 0..160. This is incorrect.
SS Tokens can have this, because they could be NEW_TOKEN tokens. But the shared state format is limited to 64.
Fixed by
A few more issues with Retry tokens: For Retry, we're supposed to check the client port. Because this isn't true for NEW_TOKEN, we probably can't put it in the shared-state pseudoheader. Relatedly, we currently just say that the shared-state Retry Service has to be behind any NAT. This isn't enough. For non-shared-state, we're probably fine. For a Retry, the NAT will keep the 4-tuple binding so that on either side there is something to validate. For shared-state: if the service is in front of the NAT, the server can't validate the address. if the service is behind the NAT, it'll "work" but to add any value at all there really has to be a port in there somewhere. We can probably assume that the alternate path that creates the need for shared state won't cause a service-generated token to suddenly appear on the unprotected path.
Fixed by
We should tighten up the rules for Resumption Token processing by the Retry Service. When active, it should reject the packet, but it should send Retry. I believe we can distinguish resumption from Retry because the CID length fields are zero; as any Retry token must have a ODCIDL of at least 8, this would appear to be robust. On a related note, the requirement on servers to encode a way to distinguish the two token types is silly, because of this propery.
Fixed by
Currently the Initial Packet number MAY be encoded in the Retry Token. We must either: Include language that a server MUST NOT reject a token because this information is not present; OR Just make it part of the format. (IMO this would be bad, because then the Retry service would have to decrypt the packet number)
Most changes appear editorial, except for the addition of the port number field. If you add that port, you need to also specify how it should be processed!
Change:
A push service MAY expire a subscription set at any time and MUST also expire all push message subscriptions in the set.  If a user agent has an outstanding request to a push subscription set (monitor- <del> set) this can be signaled by returning a 400-series status code, such as 410 (Gone). </del> <ins> set) this can be signaled by returning a 404 (Not Found) status code. </ins> A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI.  This MUST also

Discussion:
As suggested by NAME
Thanks to all for the discussion, I was lazy and missed the MUST 404 on the section above.
The language for subscription and subscription sets is still a bit asymmetical. I'll merge this PR and make the subsequent edits. For example can remove versus MAY expire ...
Change:
streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 <del> -1, so the largest legal value of Quarter Stream ID is 2 </del> <ins> -1, so the largest legal value of Quarter Stream ID is (2 </ins> <del> -1 / 4.  Receipt of a frame that includes a larger value MUST be </del> <ins> -1) / 4.  Receipt of a frame that includes a larger value MUST be </ins> treated as a connection error of type FRAME_ENCODING_ERROR. A variable-length integer indicating the context ID of the

Discussion:
Why would parentheses be required? Exponent has higher precedence than subtraction.
I think this proposal resolves the misinterpretation of 2^62 - (1/4)
Oh my bad, I had misread.
Change:
or the rate at which validation can be requested within a given subtree of the DNS. <del> 10.4. </del> <ins> 10.5. </ins> The controls on issuance enabled by ACME are focused on validating that a certificate applicant controls the identifier he claims.

Discussion:
This reverts commit 5ea8bb3afe51fa14b34593341b895e0262b454ca, reversing changes made to 278c6e8ab49e3013708cbf544c76df868973635f.
Change:
internet service provider (ISP) to attempt to "throttle" these transfers in order to to mitigate the load that these hosts placed on their network.  These efforts were met by increased use of encryption <del> in Bittorrent, similar to an arms race, and set off discussions about "Net Neutrality" and calls for regulatory action. </del> <ins> in Bittorrent, and complaints to regulators calling for regulatory action. The BitTorrent case study is just one example, but the example is included here to make it clear that unpredicted and unpredictable massive traffic spikes may not be the result of natural disasters, but they can still have significant impacts. </ins> Especially as end users increase use of video-based social networking applications, it will be helpful for access network providers to

Discussion:
From NAME Unsure whether the end part of this section is relevant to the document as it is rather anecdotical.
We should explain the impact on the Internet, the IETF, and regulatory agencies from the BitTorrent experience.
Working session discussion: yes this is anecdotal, but is a worthwhile example to keep because it adds a concrete example to the abstract notion of unpredictable traffic and its impacts. We think the right response is to add a paragraph to this anecdote explaining the ultimate impact to the internet that this example of unpredictable traffic had as a conclusion to explain how the experiences from unpredictable traffic can cause large and sudden shifts in network operational practice.
NAME - I agree. I suspect that the number of people who remember the impact of Comcast attending to "manage" BitTorrent on residential networks is declining every year, but it was horrendous at the time. We should make it clear that you don't have to have a hurricane to end up with sudden and massive spikes in network traffic that you never planned for.
I teach this every year to keep the new generation aware of some of the non-sense stuff their elder brothers (or sisters) had to put up with. It was not just Comcast, I can name 5 other names based on my own testing at that time.
I like the last paragraph of the PR ;-) Thanks
LGTM
Change:
members to incorporate a Commit message into the transcript without having to store the whole MLSPlaintextCommitAuthData structure. <del> When a new group is created, the "interim_transcript_hash" field is set to the zero-length octet string. </del> <ins> As shown above, when a new group is created, the "interim_transcript_hash" field is set to the zero-length octet string. </ins> 7.7.

Discussion:
Addresses ambiguity pointed out on the mailing list by NAME
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Change:
Insert Count has already been acknowledged, that MUST be treated as a connection error of type "HTTP_QPACK_DECODER_STREAM_ERROR". <ins> The Header Acknowledgement instruction might increase the Known Received Count, see known-received-count. </ins> 4.4.2. When a stream is reset or reading is abandoned, the decoder emits a

Discussion:
Fixes issue . This PR fixes the race condition and clarifies that both endpoints must keep track of the Known Received Count. Also remove "If a header block was potentially blocking" phrase from Known Received Count section, because it is redundant with the clear instructions on whether to increase the Known Received Count in the next sentence. Also remove "for example because the encoder or the decoder have chosen not to risk blocked streams" and defer to new-table-entries instead, so that all guidance on emitting Insert Count Increment instructions is in one place. Note that the decoder has no way to know if the encoder chose not to risk blocked streams, so I find this phrase confusing to start with.
Assume a decoder receives the following data: A: the first dynamic table insertion, B: the second dynamic table insertion, C: the third dynamic table insertion, X: a header block with required insert count of one. A, B, and C are guaranteed to be received in this order, because they are all on the encoder stream. X arrives on a request stream, so its order relative to the insertions is not guaranteed. Consider the orders A, B, X, C, and A, X, B, C. Suppose the decoder sends a Header Acknowledgement of the header block as soon as it is received (all necessary entries are available by that time). This Header Acknowledgement instruction increases the encoder's Known Received Count by one. Suppose that after receiving C, the decoder decides to send an Insert Count Increment instruction. According to URL, "The value of the Increment is the total number of dynamic table insertions and duplications processed by the decoder since the last time it sent a Header Acknowledgement instruction that increased the Known Received Count (see Section ) or an Insert Count Increment instruction." In the first case, one insertion (C) was processed since the last Header Acknowledgment instruction that increased the Known Received Count was sent. In the second case, two insertions (B and C). I'm ready to address this issue with a PR but waiting for review of issue 2942 which would conflict.
Ah, it needs to explicitly reference the Required Insert Count from the header block that was acked, rather than "since the last time". I think this is editorial, since that's the intent of the text.
I agree that it's editorial.

In I'm already proposing to mandate both the encoder and the decoder to keep track of the Known Received Count. Then Insert Count Increment could simply increase Known Received Count, without any references to previously acked header blocks if any etc.
Fixed by
Change:
level transport.  In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram.  Omitting the length field MUST only be used for the last <del> record in a datagram. </del> <ins> record in a datagram.  Implementations MAY mix records with and without length fields on the same connection. </ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from

Discussion:
Andy Cunningham wrote Text would not hurt in the draft to explain this.
Chairs, please opine on whether this should get confirmed on the list.