jiebi/CodeConvo huggingface dataset:
Change:
4.1.5. exchange-summary summarizes the exchange between QUIC and TLS for <del> both client and server.  Each arrow is tagged with the encryption level used for that transmission. </del> <ins> both client and server.  Solid arrows indicate packets that carry handshake data; dashed arrows show where application data can be sent.  Each arrow is tagged with the encryption level used for that transmission. </ins> exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what incoming messages trigger different actions.  New handshake messages <del> are requested after all incoming packets have been processed.  This process might vary depending on how QUIC implementations and the packets they receive are structured. </del> <ins> are requested after incoming packets have been processed.  This process varies based on the structure of endpoint implementations and the order in which packets arrive; this is intended to illustrate the steps involved in a single handshake exchange. </ins> 4.2.

Discussion:
I came back to this today and found that the ordering was inconsistent and not sufficiently clear. Changing this so that all the actions for a single endpoint were grouped seemed to be the best arrangement. All events and actions are as close as possible in the ordering to the preceding event that caused or enabled it. The application data packets are displayed with a different marking, which helps distinguish those that carry CRYPTO frames. The final implied exchange for Get Handshake was removed. This was, I think, intended to imply something about session tickets. Without explanation, it is confusing. This doesn't show HANDSHAKE_DONE, nor do I think that it should, because that is something that the transport does once it gets the Handshake Complete signal.
LGTM, one suggestion
Change:
Calling Clone on a Connection yields a group of Connections: the parent Connection on which Clone was called, and a resulting cloned <del> Connection.  The connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties except "Connection Priority" (see conn-priority) .  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. </del> <ins> Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  The Connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties except "Connection Priority" (see conn-priority) .  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. </ins> The stack of Message Framers associated with a Connection are also copied to the cloned Connection when calling Clone.  In other words,

Discussion:
Clarify that the Connection returned by Clone will send a Ready Event or an InitiateError Event.
Clone() is analogous to Initiate(), so why doesn't it return ready events like initiate()?
This should be OK because Initiate doesn't generate the Ready event, etc, but the Connection does. Both Initiate and Clone return a Connection. We can try to clarify this.
Change:
fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward Erasure Correction (FEC) channels.  The Congestion Control channel <del> carries source packets (from a server to a client) and potential </del> <ins> carries source packets (from a sender to a receiver) and potential </ins> information signaling the packets that have been received (from the <del> client to the server).  The Forward Erasure Correction channel carries repair packets (from the server to the client) and a </del> <ins> receiver to the sender).  The Forward Erasure Correction channel carries repair packets (from the sender to the receiver) and a </ins> potential information signaling the packets that have been repaired <del> (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. </del> <ins> (from the receiver to the sender).  It is worth pointing out that there are cases where these channels are not separated. </ins> Inside a host, the CC and FEC entities can be regarded as conceptually separate: fig:sep-entities provides more details than fig:sep-channel by <del> focusing on the server side.  Some elements are introduced: </del> <ins> focusing on the sender-side.  Some elements are introduced: </ins> 'network measurements' (input control plane for the transport including CC): refers to the information a ongestion control can

Discussion:
I propose some rewording and talk about sender and receiver instead of server and client. The sender is not always the server and it could be confusing to assume the sender as being a server (e.g. in ssh it is the inverse). Let me know if you disagree on this.
Au contraire, I disliked the client-server thing from the beginning and thought we should move it to sender-receiver some day! So thanks a LOT for doing this!
LGTM, thanks for this!
Change:
can be established by consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting packet is sent, an explicit duration must be used to account for those cases where PTOs do not occur or <del> are substantially delayed.  This duration is computed as follows: </del> <ins> are substantially delayed.  The rationale for this threshold is to enable a sender to use initial PTOs for aggressive probing, as TCP does with Tail Loss Probe (TLP) RACK, before establishing persistent congestion, as TCP does with a Retransmission Timeout (RTO) RFC5681. The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is approximately equivalent to two TLPs before an RTO in TCP. This duration is computed as follows: </ins> For example, assume:

Discussion:
As pointed out in , I think that we should assume same amount of RTT variance when there is no RTT sample and when there is one sample, because variance is unknown in both cases. This PR makes that change while keeping the initial PTO being the same (i.e. 1 second), and slightly simplifies the timeout logic.
NAME Thank you for the review. Would you ming checking if the updated text has what you have suggested?
NAME NAME Thank you for the suggestions. I've applied them.
For each connection, the loss detection timeout is defined as 2 InitialRTT. I wonder if this should be 3 InitialRTT instead, because, once you have one RTT sample, PTO is calculated as 3 * InitialRTT. I do not think we have a reason to believe that the variance of RTT (which applies as a multiplier here) increases when we obtain the first sample? PS. The other benefit of making these two consistent is that we can get rid of in SetLossDetectionTimer. It would be possible to always rely on PTO calculation.
I wasn't sure if this would be design or not, but now that the PR is complete, I believe it's editorial, as NAME PR changes the pseudocode, but proscribes exactly the same behavior as the existing text.
To be precise, there is one thing that does change, and that is the initial timeout when a connection is resumed on the same path. At the moment, the only variable we recommend to remember is SRTT, and when resuming a connection on the same path, use 2 SRTT as the initial timeout. The proposed change increases that to 3 SRTT. I think this is better than status-quo, assuming that we agree that RTTVAR should be 2 * sample when there is only one known sample.
Thanks for pointing that out, I noticed that the first time around and then forgot. I'll let NAME make the call about whether he thinks this is design then.
LGTM - thanks, NAME Can you resolve the merge conflict?
Change:
can be established by consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting packet is sent, an explicit duration must be used to account for those cases where PTOs do not occur or <del> are substantially delayed.  This duration is computed as follows: </del> <ins> are substantially delayed.  The rationale for this threshold is to enable a sender to use initial PTOs for aggressive probing, as TCP does with Tail Loss Probe (TLP) RACK, before establishing persistent congestion, as TCP does with a Retransmission Timeout (RTO) RFC5681. The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is approximately equivalent to two TLPs before an RTO in TCP. This duration is computed as follows: </ins> For example, assume:

Discussion:
Moves some RECOMMENDEDs up and removes others which are already elsewhere in the draft and reference those sections. This was intended to address , which I can still do in this PR if NAME would like, but I still think of Min CWND and Initial CWND as constants per-connection, even if they're not truly constants.
Change:
7.6. To request that a certificate be revoked, the client sends a POST <del> request to the ACME server's revoke-cert URL.  The body of the POST is a JWS object whose JSON payload contains the certificate to be </del> <ins> request to the ACME server's revokeCert URL.  The body of the POST is a JWS object whose JSON payload contains the certificate to be </ins> revoked: The certificate to be revoked, in the base64url-encoded version of

Discussion:
The example was misleading in case a certificate is revoked by signing the revocation request with the certificate's private key. I assume "jwk" should be the public key from the certificate in this case and not the account key; see URL
Merging because it looks like the issue raised by NAME has been addressed.
Change:
request with their own keys, thereby negating the benefits of using key-bound access tokens. <del> The RS also needs to ensure that a sufficient portions of the message </del> <ins> The RS also needs to ensure that sufficient portions of the message </ins> are covered by the signature.  Any items outside the signature could still affect the API's processing decisions, but these items would not be strongly bound to the token presentation.  As such, an

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
The main participants in the protocol are as follows: The basic unit of DAP is the "task" which represents a single <del> measurement (though potentially taken over multiple time windows). The definition of a task includes the following parameters: </del> <ins> measurement process (though potentially taken over multiple time windows).  The definition of a task includes the following parameters: </ins> The type of each measurement. The aggregation function to compute (e.g., sum, mean, etc.). <del> The set of aggregators and necessary cryptographic keying material </del> <ins> The set of Aggregators and necessary cryptographic keying material </ins> to use. The VDAF to execute, which to some extent is dictated by the

Discussion:
Based on .
NAME can you please rebase? Some of the changes we improved on in now appear here.
Rebased.
Change:
While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily <del> expose stream identifiers to the application (see e.g.  QUIC-HTTP section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </del> <ins> expose stream identifiers to the application (see, for example, QUIC- HTTP, Section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </ins> 4.1.

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:
Unconditional input secrecy.  The issuance protocol MUST NOT reveal anything about the Client's private input, including the <del> challenge and nonce, to the Attester or Issuer.  The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </del> <ins> challenge and nonce, to the Attester or Issuer, regardless of the hardness assumptions of the underlying cryptographic protocol(s). The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </ins> One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens

Discussion:
cc NAME
LGTM!
Is unconditional input secrecy meant to mean similar to unconditionally hiding? If so, this probably deserves more explanation and justification in the architecture document as a requirement; otherwise, a different term should probably be used.
To my knowledge unconditional input secrecy is the standard term here. What do you think should be added to resolve this issue?
I guess my main question is why is unconditional secrecy a requirement here?
Because we don't want the server to learn anything about the client's private input regardless of its computational power. Take blind RSA as an example, which has this property. While a PQ adversary could break RSA, it could not learn the client's private input from a protocol trace.
I think this should be spelled out explicitly; i.e., say explicitly that the client's private input should remain private even if some of the cryptographic hardness assumptions underlying the protocol become falsified. I wonder if this would be a good place to use a SHOULD vs a MUST. I can see how unconditional secrecy is a desirable property, but, e.g., TLS doesn't have it for obvious reasons.
I sent a PR for (1). I don't think we should relax (2). Future versions of the architecture can update this requirement to relax as desired.
Change:
4. The SAP network model builds on the network data model defined in the <del> 'ietf-network' module RFC8345, augmenting the nodes with service attachment points, which anchor the links and are contained in nodes. </del> <ins> 'ietf-network' module RFC8345, augmenting the nodes with Service Attachment Points, which anchor the links and are contained in nodes. </ins> The 'service-attachment-point' attribute defined in the SAP network model is not a tunnel termination point (TTP) nor a link, but an abstraction of the termination point defined in RFC8345.

Discussion:
Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:
Change:
A response MAY consist of multiple messages when and only when one or more interim responses (1xx; see Section 15.2 of SEMANTICS) precede a final response to the same request.  Interim responses do not contain <del> payload data or trailers. </del> <ins> content or trailers. </ins> An HTTP request/response exchange fully consumes a client-initiated bidirectional QUIC stream.  After sending a request, a client MUST

Discussion:
… avoiding confusion with individual frame payloads (editorial). This is related to the Semantics issue URL
NAME has created URL on http-core Semantics draft, which describes how the term "payload" is overloaded when considered with the H2 and H3 docs. Roy's has a proposal to change that term in Semantics, which impacts the HTTP/3 draft. But he was kind enought to submit PR URL, which demonstrates the impact of that change. This issue is mainly for visibility and tracking purposes.
With or without NAME suggestion. I need to do the same for h2, so it is good to see URL suggestion
Change:
and users of known security concerns specific to the idempotency keys. <del> For idempotent request handling, the resources MAY make use of the value in the idempotency key to look up a cache or a persistent store for duplicate requests matching the key.  If the resource does not validate the value of the idempotency key prior to performing such a lookup, it MAY lead to various forms of security attacks and compromise.  To avoid such situations, the resource SHOULD publish the expected format of the idempotency key, algorithm used to generate it and always validate the key value as per the published specification before processing any request. </del> <ins> Resource servers that do not implement strong idempotency keys, such as UUIDs, or have appropriate controls to validate the idempotency keys, could be victim to various forms of security attacks from malicious clients: Injection attacks-When the resource server does not validate the idempotency key in the client request and performs a idempotent cache lookup, there can be security attacks (primarily in the form of injection), compromising the server. Data leaks-When an idempotency implementation allows low entropy keys, attackers MAY determine other keys and use them to fetch existing idempotent cache entries, belonging to other clients. To prevent such situations, the specification recommends the following best practices for idempotency key implementation in the resource server. Establish a fixed format for the idempotency key and publish the key's specification. Always validate the key as per its published specification before processing any request. On the resource server, implement a unique composite key as the idempotent cache lookup key.  For example, a composite key MAY be implemented by combining the idempotency key sent by the client with other client specific attributes known only to the resource server. </ins> 6.

Discussion:
1- Addressed comments wrt 5XX codes being retriable 2- Elaborated the security section to describe security issues relating to the idempotency key
Change:
The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future <del> client requests.  The server should generate the value provided in </del> <ins> client requests.  The server MUST generate the value provided in </ins> Replay-Nonce in such a way that they are unique to each message, with <del> high probability. </del> <ins> high probability.  For instance, it is acceptable to generate Replay- Nonces randomly. </ins> The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of

Discussion:
And clarify "high probability."
While we're clarifying, I might add an encrypted counter another option that is guaranteed unique.
I don't think we need to get into that level of prescribing implementation detail; once you mention it at all it immediately sounds half-specified. As a reader, I would want to know "what algorithm? shared across how many frontends? how does key management and rotation work?" Better to just say it should be unique (with high probability) and leave it to the implementer.
Change:
This is an example response for a query for the IN A records for "www.example.com" with recursion turned on.  The response bears one <del> record with an address of 93.184.216.34 and a TTL of 128 seconds. </del> <ins> record with an address of 192.0.2.1 and a TTL of 128 seconds. </ins> 7.

Discussion:
Unfortunately, we shouldn't use the existing real-world URL address and should be using example ip space instead.
unfortunately you included the PR changes in this PR too.. let's see if the merge process can sort that out :)
ok! thanks.
Change:
Group ID, epoch, tree, confirmed transcript hash, and interim transcript hash from the new state <del> The confirmation from the MLSPlaintext object </del> <ins> The confirmation_tag from the MLSPlaintext object </ins> Sign the GroupInfo using the member's private signing key

Discussion:
This PR gets rid of the explicit HMAC reference and uses KDF.Extract instead (which internally uses HMAC). Also is renamed to .
I don't love the extra , but I can live with it.
Change:
"true" or "false". "OptionalValue" is an abstraction of a primitive value that may <del> also be absent. "Absent" is an abstraction of an empty nodelist. </del> <ins> alternatively be absent ("Nothing"). </ins> "OptionalNodes" is an abstraction of a "filter-path" (which appears in an existence test or as a function argument).

Discussion:
Remove single-valued type "Absent". This is not useful as a function signature type (parameter or result).
I'm looking at 2.6.1 and wondering if it would be meaningful for a function to have a result type of . How could such a function be used in a filter? If it is the case that this doesn't make sense, that should probably be noted in the text.
By "absent" do you mean "no return value," like a function in C? If so, what would be the point? The usefulness of functions is that they perform calculations on inputs and provide a result.
Indeed, the clarification should be that not all types that make up the type hierarchy are useful as return types. (Which does not mean they need to be outlawed -- they are just not useful.)
No. is a type with one instance ().
I can just about conceive of a logging function that doesn't need to return a value returning type . It could be used in a filter expression like this . I'm not suggesting that's a good idea, but it could be done.
That has no impact on the output of the query, though. Why would one include such a thing? Logging is an implementation/application concern. What? I'm asking about the meaning of . How is it used? What's it's purpose? It doesn't appear in the spec anywhere, so why even ask the question?
2023-01-10 Interim: Remove Absent type.
Change:
6. <del> TODO - review and trim as needed. </del> There are a number of security considerations that need to be taken into account by implementers of this specification.  While some considerations have been highlighted here, additional considerations

Discussion:
Remove the sections from the Examples Applenix that were blank, clean up the Security Considerations, and narrow the table in the IANA considerations.
Looks good to me! Thanks! Let us know if you want us to merge it or you plan to do that yourself.