jiebi/CodeConvo huggingface dataset:
Change:
The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for <del> the DH group defined by the corresponding entry in the cipher_suites array. </del> <ins> the asymmetric encryption scheme defined in the cipher_suites array and used in the HPKE construction for TreeKEM. </ins> The whole structure is signed using the client's identity key.  A UserInitKey object with an invalid signature field MUST be considered

Discussion:
I'm approving these changes given the current state of the document, but I filed because the KDF stuff is broken. Please make HPKE a normative reference (since it's required to implement). Since it's an Internet-Draft, you don't need to add it to the references section, you can just reference it directly as and the Markdown processor will add the reference. (Change the to for an informative reference.)
Change:
To protect the request, the JWS header MUST contain the following additional parameters. <ins> The type header, value "gnap-binding+jws". </ins> The HTTP Method used to make this request, as an uppercase ASCII string.

Discussion:
Suggested changes for URL
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 5602b657d1be7c2b17685269030092799ccb120f https://deploy-preview-226--gnap-core-protocol-editors-URL
This PR is now pending merge, linking with a new issue for verification (to check the value based on typ).
Key proof sections do not currently detail how to verify each method, including requirements for verifying fields, this needs to be added.
The idea is to minimize ways to reuse JWS objects . These attacks are sometimes referred as Swapping JWTs and Cross-JWT Confusion). See also discussion in URL
Change:
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> RFC3711, as those SRTP features <del> duplicate some of the functions of EKT. </del> <ins> duplicate some of the functions of EKT.  Senders MUST not include MKI when using EKT.  Receivers SHOULD simply ignore any MKI field received if EKT is in use. </ins> 2.1.

Discussion:
Section 2 (para 2) EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's [RFC3711], as those SRTP features duplicate some of the functions of EKT. Same issue has be raised by Spt >>>What happens if an implementation does use SRTP's MKI or with SRTP's ? Is an error thrown?
I do expect they'd check, because they have to know how to parse the packet and where to insert the EKT field. With EKT, the key to use is conveyed via the RTP packet. Only after the EKT field is parsed would it make sense to look to find an MKI value. In any case, if MKI is used it's just redundant. One thing I didn't see in reviewing the current specs is where the EKT field should be inserted. It should be inserted on the inner encryption step of double. The outer encryption is consumed by intermediaries and they don't understand EKT. We probably need to put that back into the framework document. The packet format was removed during one revision.
opened new bug for where EKT goes
Change:
decision.  Note that the format and cryptographic protection of this information may change in future versions or extensions of TLS or QUIC, and therefore this functionality is inherently not version- <del> invariant. </del> <ins> invariant.  See also unroutable for other considerations about this case.  Note that an SNI-aware load balancer, faced with an unknown QUIC version, might misdirect initial packets to the wrong tenant. While inefficient, this preserves the ability for tenants to deploy new versions provided they have an out-of-band means of providing a connection ID for the client to use. </ins> 11.

Discussion:
Upon further consideration, any TP to provide CIDs for future connections should be in a different document.
LBs that are doing SNI routing are a special case. (1) If the Initial CID is routable, they can't just take that as good; they have to assume that it was random and inspect the SNI to make a decision. Section 4.1 doesn't allow this, and it should. (2) that mode doesn't work for unknown QUIC versions, obviously. (3) For QUIC versions the SNI-LB doesn't understand, I think this is the best we can do: a) For QUIC versions it understands, the LB MAY find the SNI. It MAY use the SNI for unroutable CIDs. If a routable CID, it may override the encoded SID if that SID does not correspond to the provided SNI. b) The QUIC-LB config explicitly states that the LB is doing SNI routing and the versions it supports c) The server MAY send a TP that means "next time you connect with me, please use one of the connection IDs I provided in a NEWCONNECTIONID frame." This may also be useful for some persistence use cases. The worst case is an unsupported version with a randomly generated CID. In this case, the LB will spray it and will only get lucky if it happens to get to the right tenant. Sec 11.4 may also need a revision here. Or maybe SNI routing is just incompatible with version-independent QUIC-LB?
The down side of just saying "don't do that' is that then SNI Load balancing can't work with version aliasing, which would be sad because VA helps hide the SNI.
Maybe specify a unique quic transport param is a better choice? For a web service, all requests just have same SNI, help nothing for distinguishing the Initial CID
Further more, there is a draft about encrypted client hello(URL)if it becomes RFC, maybe LB cannot get information about clientHello or there must be some ways to synchronize the server private-key to LB
synchronizing the server private-key is exactly what happens; that is what the "client-facing server" is in that draft.
I'm not sure what you're proposing here.

My hope is not introduce a regression relative to current capabilities, but it sounds like you're talking about an L7 load balancer that's doing deep packet inspection. If so, that's out of scope for this document.
OK, I got it
Change:
4.3. A group has a single linear sequence of epochs.  Groups and epochs <del> are generally independent of one-another.  However, it can sometimes </del> <ins> are generally independent of one another.  However, it can sometimes </ins> be useful to link epochs cryptographically, either within a group or across groups.  MLS derives a resumption pre-shared key (PSK) from each epoch to allow entropy extracted from one epoch to be injected

Discussion:
Some of these editorial comments I find less clear than the original. The code changes and varint are fine. Could you please split this into two more atomic PRs so we can discuss separately?
Feel free to leave comments on the editorial portion of this PR to keep things moving
Change:
This JWT is included in an Authorization header field, using an auth- scheme of "vapid".  A push service MAY reject a request with a 403 (Forbidden) status code RFC7235 if the JWT signature or its claims <del> are invalid. </del> <ins> are invalid.  A push service MUST NOT use information from an invalid token. </ins> The JWT MUST use a JSON Web Signature (JWS) RFC7515.  The signature MUST use ECDSA on the NIST P-256 curve FIPS186 which is identified as

Discussion:
This looks a lot worse than it really is. Reflowing text causes massive diffs, which github somehow manages to make look like entirely new text.
Change:
The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of RFC5280.  This SHOULD use the <del> default system or application trust anchors. </del> <ins> default system or application trust anchors, unless otherwise configured. </ins> The client MUST verify that the certificate contains the IP address of the designating Unencrypted DNS Resolver in an

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
4.1. <del> Long headers take the form described in fig-long.  Bits that have version-specific semantics are marked with an X. </del> <ins> Long headers take the form described in fig-long. </ins> A QUIC packet with a long header has the high bit of the first byte set to 1.  All other bits in that byte are version specific.

Discussion:
Happened to notice that the updated figure (didn't check the old one) was inconsistent with the text about the allowed length of the CID fields. Should be editorial, since the text wins any conflicts.
Bah, yes, 255 bytes = 2,040 bits.
:D That's exactly the process that my mind followed.
Both section 4.2 and 4.3 say Unfortunately, the doesn't have Xs. I'm not sure how to reword this to support both formats.
how about :)
I think this was fixed by URL, I dont know if that was just a coincidence or it was untagged
That was intentional. I just neglected to tag this.
Change:
Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that <del> there is no deduplication of the nodelist. [dedup] </del> <ins> there is no deduplication of the nodelist. </ins> 2.6.5.

Discussion:
Delete the editor's note as »Note that there is no deduplication of the nodelist.« is now the agreed behavior.
As currently specified, there is no deduplication of nodes input to the count() function extension. But the spec contains a placeholder suggesting discussion of deduplication. This issue is for that discussion. This issue is related to URL because if function extensions do not have access to node location, then it would not be possible to deduplicate on node identity, only potentially on value.
2023-01-10 Interim: Remove the editor's note now.
Change:
Upon determining the true SNI, the client-facing server then either serves the connection directly (if in Shared Mode), in which case it executes the steps in the following section, or forwards the TLS <del> connection to the hidden server (if in Split Mode).  In the latter </del> <ins> connection to the backend server (if in Split Mode).  In the latter </ins> case, it does not make any changes to the TLS messages, but just blindly forwards them.

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.
Change:
"helper_url": The helper's endpoint URL. "collector_config": The HPKE configuration of the collector <del> (described in key-config).  [OPEN ISSUE: Maybe the collector's HPKE config should be carried by the collect request?] </del> <ins> (described in key-config).  Putting the collector's HPKE configuration directly in "struct PPMParam" absolves collectors of the burden of operating an HTTP server.  See #102 [1] for discussion. </ins> "batch_size": The batch size, i.e., the minimum number of reports that are aggregated into an output.

Discussion:
Removes some TODOs, clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl, and amends collect protocol so that leader output shares are encrypted to collector's HPKE config. Several response structures no longer have or fields if the appropriate task (and hence and hence ) can be inferred from the request.
I want to address in this PR as well, so downgrading to draft for now.
NAME NAME This is ready; please review at your convenience.
Thank you for the review, NAME This picked up some merge conflicts so I will wait for all of NAME changes to land and then rebase.
You should be able to rebase now. I am mostly done.
Rebased, reordered, ready for re-review
This seems to be a dupe fo -- can we close?
Per discussion in the call today, I think this issue is about updating the various PDU definitions to allow for multiple helpers. For instance, currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle >1 helper, which probably involves more rounds of communication. I'm going to grab this issue because I ran into which I think is related, so I'll fix both.
Right now only the helper's output share for a batch of reports is encrypted to the collector. We previously agreed that all input shares should be encrypted to the corresponding aggregator (URL). It makes sense to encrypt the leader's output share for the same reasons we discussed there. Along the way, the message format should be made to accommodate multiple helpers, as we did for the input shares.
Fixed in . Making "the message format [...] accommodate multiple helpers" is specifically tracked in and resolved by .
Change:
has not yet caught up. The RECOMMENDED time threshold (kTimeThreshold), expressed as a <del> round-trip time multiplier, is 9/8. </del> <ins> round-trip time multiplier, is 9/8.  The RECOMMENDED value of the timer granularity (kGranularity) is 1ms. </ins> Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT

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:
has not yet caught up. The RECOMMENDED time threshold (kTimeThreshold), expressed as a <del> round-trip time multiplier, is 9/8. </del> <ins> round-trip time multiplier, is 9/8.  The RECOMMENDED value of the timer granularity (kGranularity) is 1ms. </ins> Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT

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:
Each protocol has a notion of Connectedness.  Possible values for Connectedness are: <del> Unconnected.  Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. </del> <ins> Connectionless.  Connectionless protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. </ins> Connected.  Connected protocols establish state between endpoints, and perform a handshake during Connection establishment.  The

Discussion:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.
Change:
the client has the mapping ready, it can push it down to SFrame later. <ins> The KeyId field in the SFrame header is used to find the right key for that user, which is incremented by the sender when they change to a new key. </ins> For frames that are failed to decrypt because there is not key available yet, SFrame will buffer them and retries to decrypt them once a key is received. <del> 3.2.5. </del> <ins> 3.3.4. </ins> Unlike messaging application, in video calls, receiving a duplicate frame doesn't necessary mean the client is under a replay attack, there are other reasons that might cause this, for example the sender might just be sending them in case of packet loss.  SFrame decryptors <del> use the last received frame counter to protect against this.  It </del> <ins> use the highest received frame counter to protect against this.  It </ins> allows only older frame pithing a short interval to support out of order delivery. <del> 3.2.6. </del> <ins> 3.3.5. </ins> Because the E2EE keys could be rotated during the call when people join and leave, these new keys are exchanged using the same E2EE

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See <del> Section 5 of SEMANTICS. </del> <ins> Section 5.4 and Section 5.6 of SEMANTICS. </ins> Data associated with a field name, composed from all field line values with that field name in that section, concatenated together

Discussion:
Section 1.1: HTTP field line: A name-value pair sent as part of an HTTP field section. See Section 5 of [SEMANTICS]. I would guess that this can be refined to point to section 5.4.
Proposed change is "editorial".
Change:
the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see conn-timeout) is used. <ins> 7.2.4. groupConnLimit Numeric (with special value "Unlimited") Unlimited This property controls the number of Connections that may arrive from a peer as new members of the Connection's group.  Similar to SetNewConnectionLimit(), this limits the number of ConnectionReceived Events that will occur, but constrained to the group of the Connection associated with this property.  In case of a multi- streaming transport, this takes the role of a limit on the number of allowed streams. </ins> 7.3. During the lifetime of a connection there are events that can occur

Discussion:
I found the relationship between streams and connections to be extremely murky throughout the draft, and left it not really sure how I would control a streamed transport. Section 6.4 hints suggests that opening additional streams is an alternative implementation of Clone() for transports that can do so. Does this imply that if the peer stream limit does not allow new streams, the transport should open a connection instead? How does SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are there two levels of listener: a stream listener and a connection listener? How would opening "stream listeners" relate to the maximum number of streams the peer could open (i.e. do I have to call listen() 8 times to allow the client to open 8 streams)? Or are there no stream listeners and these "connections" just sort of appear? Skimming the -impl draft, I can see there's some text here but it is not fitting together for me. There are at least three streamed transports and it would be helpful to explain how the API conceptualizes this, perhaps in a new section.
To clarify, Listen() is called once and keeps receiving streams within the NewConnectionLimit. The main thing to clarify is how the NewConnectionLimit applies to streams of a multiplexed transport. We could look at having a limit of connections per endpoint in a group from a listener.
Add a property to section 7.1.
Also make sure to have an early section being very explicit about the overall interaction model.
In section 4.1, we could add an example for explicit group management via clone, etc.
Sigh, I will never self-assign an issue again before its discussion :-) but it's ok... I'll do it
Change:
establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies that support CONNECT-IP SHOULD restrict its use to authenticated <del> users.  The HTTP Authorization header AUTH MAY be used to </del> <ins> users.  The HTTP Authorization header SEMANTICS MAY be used to </ins> authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using CONNECT-IP extensions.

Discussion:
Fixing some ID nits validations errors include update references from drafts to RFCs for SEMANTICS and H3 Websockets draft.
Change:
bandwidth efficiency and delay variation when sending this message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's <del> algorithm), to signal a preference for lower-latency, higher-loss treatment, and so on. </del> <ins> algorithm); to prefer immediate acknowledgment from the peer endpoint when supported by the underlying transport; to signal a preference for lower-latency, higher-loss treatment; and so on. </ins> <del> Delay and delay variation should be optimized at the expense of </del> <ins> Delay and delay variation should be minimized at the expense of </ins> bandwidth efficiency. This Message may be sent at the system's leisure.  This can be

Discussion:
Removes Immediate Acknowledgment and makes it an optional implicit feature of Low Latency profile, renames Instantaneous Capacity Profile to Transmission Profile. Addresses ; we should open a new issue to discuss whether we want to split Capacity Profile back out.
About "Transmission profile", I like it; we had Capacity Profile (not "Instantaneous" though) in NEAT because it contains choices about how an application wants to make use of the available capacity. Because "Transmission profile" loses that hint, it conveys less meaning - but frankly, I still prefer it just for the way it sounds.