jiebi/CodeConvo huggingface dataset:
Change:
The Initiator needs to have a list of cipher suites it supports in order of preference.  The Responder needs to have a list of cipher <del> suites it supports.  SUITES_I is a CBOR array containing cipher suites that the Initiator supports.  SUITES_I is formatted and processed as detailed in asym-msg1-form to secure the cipher suite negotiation.  Examples of cipher suite negotiation are given in ex- neg. </del> <ins> suites it supports.  SUITES_I contains cipher suites supported by the Initiator, formatted and processed as detailed in asym-msg1-form to secure the cipher suite negotiation.  Examples of cipher suite negotiation are given in ex-neg. </ins> 3.7.

Discussion:
Addressing
NAME Please check if your comments are addressed.
Yes, especially in [1]. Thanks! [1] URL
-08 contained a definition of CREDx including an example when kid is used. -09 removed that example and replaces it with a RPK by value example. Now it seems like the most important use case is not well specified. This is the use case that leads to message2 being 45 bytes.
In addition the TOFU use case should likely also have a kid. Otherwise the UCCS has to be sent by value every time.
This is solved by just adding a 'kid' in the COSE_Key map
The document should say someting more about COSEKey. If IDCREDx = { 4 : keyidx } identifies a raw COSEKey, is that an error or is CREDx then the COSEKey wrapped in a UCCS without any parameters like sub?
SUITES_R is a name. The type needs to be defined and the table changed. This can be done in PR
The current definition of SUITESI is that the Initiator can chose any truncation of the list of supported cipher suites as long as the selected cipher suite is included. This works and allows the Initiator to give the Responder information about the full list. This is however a bit complex and has led to misunderstandings of the test vectors where several people thought the test vectors were wrong. i.e. the following are all valid I think we should simplify SUITESI by mandating that the last suite in the list is the selected. This makes SUITESI much easier to understand and lowers message size when an array is used. Giving the Responder info is not so important. CDDL
Maybe a recommendation that SUITES_R SHOULD contain all cipher suites that R supports.
Currently SUITESR : [ supported : 2 suite ] / suite We may keep that, or remove "supported" SUITESR : [ 2 suite ] / suite Alternatively, we may define SUITES_I : [ supported : 2* suite ] / suite Any preference?
They should be the same: or And then
This needs to be defined as a CDDL type. suites = [ 2* suite ] / suite See
Change:
A sender that paces packets (see pacing) might delay sending packets and not fully utilize the congestion window due to this delay.  A <del> sender should not consider itself application limited if it would </del> <ins> sender SHOULD NOT consider itself application limited if it would </ins> have fully utilized the congestion window without pacing delay. A sender MAY implement alternative mechanisms to update its

Discussion:
This my need a design issue because I suggest to use two SHOULDs instead of should. However, I would first like to get some feedback if people agree.
I think this is editorial, because it fixes an error. I always intended these to be normative SHOULD/SHOULD NOT
I'm going with editorial also.
Yup, this is editorial.
Thanks, this is certainly what I meant when I wrote this text.
Change:
times in a short period.  Servers are encouraged to allow tokens to be used only once, if possible. <del> 8.1.3. </del> <ins> 8.1.4. </ins> An address validation token MUST be difficult to guess.  Including a large enough random value in the token would be sufficient, but this

Discussion:
Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities? That's almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
One suggestion to change a normative to a MUST, on existing text.Some small suggestions, but LG
Change:
3. This document defines the "connect-udp" HTTP Upgrade Token. "connect- <del> udp" uses the Capsule Protocol as defined in HTTP-DGRAM. </del> <ins> udp" uses the Capsule Protocol as defined in HTTP-DGRAM.  The format of HTTP Datagrams is defined in format. </ins> Clients issue requests containing a "connect-udp" upgrade token to initiate a UDP tunnel associated with a single HTTP stream.  Tunnels

Discussion:
Section 3 "connect-udp" uses the Capsule Protocol as defined in [HTTP-DGRAM]. What does "uses" here mean? As there are situations where the Capsule Protocol and the Datagram Capsule defined in HTTP-DGRAM is not required to be used, it is not clear if it MUST be implemented and MAY be used?
It would be better to link specifically to URL associated request's data stream uses the Capsule Protocol. If they do so, that means that the contents of the associated request's data stream uses the following format ...
and possibly forward ref to https://ietf-wg-URL
And that might be clearer, assuming that the implementation requirement is clear in those section of the HTTP datagram spec.
Change:
After completing the handshake, endpoints have agreed to enable multipath feature and can start using multiple paths.  This document <del> does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </del> <ins> does not specify how an endpoint that is reachable via several addresses announces these addresses to the other endpoint.  In particular, if the server uses the preferred_address transport parameter, clients SHOULD NOT assume that the initial server address and the addresses contained in this parameter can be simultaneously used for multipath.  Furthermore, this document does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </ins> This proposal adds one multipath control frame for path management:

Discussion:
Attempt at moving Further, it is out of scope for this document if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter. However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. In the beginning of section where I think it would be more appropriate.
Looks good, except for the typo.
Change:
at the secondary RS.  This internal secondary token is issued in the context of the incoming access token. <del> While it is possible to use a [token format]{#structure} that allows for the RS to generate its own secondary token, the AS can allow the RS to request this secondary access token using the same process used by the original client instance to request the primary access token. Since the RS is acting as its own client instance from the perspective of GNAP, this process uses the same grant endpoint, request structure, and response structure as a client instance's request. </del> <ins> While it is possible to use a structure that allows for the RS to generate its own secondary token, the AS can allow the RS to request this secondary access token using the same process used by the original client instance to request the primary access token.  Since the RS is acting as its own client instance from the perspective of GNAP, this process uses the same grant endpoint, request structure, and response structure as a client instance's request. </ins> The client instance calls RS1 with an access token.

Discussion:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 122ea374f78cfa417b0d1d80101e64990c448665 https://deploy-preview-11--gnap-resource-servers-editors-URL
Change:
output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. <del> The identity of 'ipskx' as sent on the wire is ImportedIdentity. </del> <ins> The identity of 'ipskx' as sent on the wire is ImportedIdentity, i.e., the serialized content of ImportedIdentity is used as the content of PskIdentity.identity in the PSK extension. </ins> The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
Abstract <del> This document specifies the behavior of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud </del> <ins> Bootstrapping Remote Secure Key Infrastructures defines how to onboard a device securely into an operator maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and to help the device.  This document extends the new device behaviour so that if no local infrastructure is available, such as in a home or remote office, that the device can use a well defined "call-home" mechanism to find the operator maintained infrastructure. To this, this document defines how to contact a well-known cloud registrar, and two ways in which the new device may be redirected towards the operator maintained infrastructure. </ins> 1.

Discussion:
I find this section too telegraphic. Needs a bit more grammar...
Maybe we just delete this section completely NAME ?
I think we should eliminate the heading, but expand the content to better match the diagram.
I'm not convinced. In the rest of the doc, we never mention OEM or Network integrator. And Network operator is only mentioned again in secetion "Issues with Security of HTTP Redirect" I lean to delete completely, unless you have some explicit ideas and concepts you need to get across. FIne if you do - maybe include that in your abstract rewrite PR?
This is a bit short. I think it should provide a little context for a casual reader (what is BRSKI, what is a pledge, what is a registrar).
No, this is a runon sentence. It is worth. Let me work on something for Friday.
Change:
endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: <del> When an implementation views this aggregate set of connection attempts as a single connection establishment, it only will use one of the leaf nodes to transfer data.  Thus, when a single leaf node becomes ready to use, then the entire connection attempt is ready to use by the application.  Another way to represent this is that every leaf node updates the state of its parent node when it becomes ready, until the trunk node of the tree is ready, which then notifies the application that the connection as a whole is ready to use. </del> <ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer data.  Thus, once a single leaf node becomes ready to use, then the connection establishment tree is considered ready.  One way to implement this is by having every leaf node update the state of its parent node when it becomes ready, until the trunk node of the tree is ready, which then notifies the application that the connection as a whole is ready to use. </ins> A connection establishment tree may be degenerate, and only have a single leaf node, such as a connection attempt to an IP address over

Discussion:
Raising this issue as part of my review of the the Implementation Draft. Quoting from Section 4.1 "Structuring Candidates as a Tree" ~ Feedback: While it is understood that "connection attempt" is here used to refer to a given node in the tree, rather than the actual (stateful) process of attempting to connect to the given endpoint (using the given parameters), it does not make for easy reading. Similarly, it is possible to grasp how an "aggregate set" can be "viewed" as "a single connection establishment", but the language could be clearer here as well. Couldn't an "attempt" that has succeeded and is "ready to use" be referred to differently? Couldn't "candidate" or "option" be substituted for "attempt" to improve readability? Proposal:
Seems quite close to me
Yes, I like this proposed text.
Change:
This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the <del> congestion controller.  For example, a pacer might distribute the congestion window over the smoothed RTT when used with a window-based controller, or a pacer might use the rate estimate of a rate-based controller. </del> <ins> congestion controller.  Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or another method to limit such bursts to the initial congestion window; see initial-cwnd. </ins> An implementation should take care to architect its congestion controller to work well with a pacer.  For instance, a pacer might

Discussion:
I prefer to have MUSTs towards the top of sections when possible so they're not missed. This is a follow-on from
I'm not a fan of this change -- I think there's value in having that text below where we talk about how bursts can occur. That said, I don't feel strongly about it, so I'm not going to fight for it.
Change:
Template: <del> Field name: The string to be used as a key in the JSON dictionary </del> <ins> Field name: The string to be used as a key in the JSON object </ins> Field type: The type of value to be provided, e.g., string, boolean, array of string

Discussion:
Follow-up to , catches a few more references I initially missed.
I think 'field name' makes more sense... but I'm not really wed to either.
Change:
A PRIORITY frame that references a non-existent Push ID, a Placeholder ID greater than the server's limit, or a Stream ID the client is not yet permitted to open MUST be treated as a connection <del> error of type HTTP_LIMIT_EXCEEDED. </del> <ins> error of type HTTP_ID_ERROR. </ins> A PRIORITY frame received on any stream other than the control stream MUST be treated as a connection error of type HTTP_WRONG_STREAM.

Discussion:
Implements suggestions from
Updated to replace HTTPLIMITEXCEEDED and HTTPPUSHIDERROR with the single error HTTPID_ERROR.
There are presently a few cases where the Push ID can be used incorrectly. The table shows current error codes, proposes replacing the HTTPDUPLICATEPUSH with an HTTPPUSHIDERROR code, and replaces use of HTTPMALFORMED frame. Note, on I suggested a slightly different solution to replace HTTPMALFORMED FRAME, but I think this is a better path.
To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things like "IDERROR, STREAMIDERROR. Also, using PUSHIDERROR in some cases while using MALFORMEDFRAME in others seems confusing. I think we might want to consider doing either of the two: Use PUSHIDERROR (or a generic error code for push) for all the push-related errors. This makes sense if we consider push as an optional feature of HTTP/3 Introduce IDERROR that captures all the limit and ID errors.
Thanks NAME The proposal is a bit of a compromise, so I agree with some of the points that you make. I like your idea of replacing HTTPLIMITEXCEEDED with HTTPIDERROR. I think it solves the issue in the most general way and doesn't change the protocol mechanics. What follows is the response I made first, before coming to that agreement :) Right. The difference here is that H3 frames only reference the stream and placeholder ID spaces, they don't control them. So, if the peer references an ID that doesn't exist then respond with HTTPLIMITEXCEEDED. Multiple references to the same ID is a little different, its ok to reuse placeholder ID (as long as the above condition holds, and you create a semantically valid PRIORITY frame). The transport spec discusses reuse of stream IDs at that layer; in H3 we only use stream ID for PRIORITY and GOAWAY - this has similar restrictions. However, server push is a little different because it's ID space is managed by the MAXPUSHID frame. The three errors that use HTTPPUSHIDERROR are unique to push.

However, if we modified HTTPLIMITEXCEEDED to cover exceeding limits and incorrect ID usage (call it HTTPID_ERROR) I think that would work.
I updated the PR with the above, so that we can see what it looks like.
I'm not totally sold on this, but I'm having trouble articulating what it is that doesn't flow for me. I suspect that means I don't actually disagree, I just need some time to wrap my head around it.
We merged so I'm closing this as completed.
Change:
decline ESNI-established sessions if it did not accept ESNI. The client MUST verify that the certificate is valid for <del> ESNIConfig.public_name.  If invalid, it MUST abort the connection with the appropriate alert. </del> <ins> ESNIConfigContents.public_name.  If invalid, it MUST abort the connection with the appropriate alert. </ins> If the server requests a client certificate, the client MUST respond with an empty Certificate message, denoting no client

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.
Change:
server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on. <del> A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  An endpoint MAY send multiple GOAWAY frames indicating different identifiers, but the identifier in each frame MUST NOT be greater than the identifier in any previous frame, since clients might already have retried unprocessed requests on another connection.  Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </del> <ins> An endpoint MAY send multiple GOAWAY frames indicating different identifiers, but the identifier in each frame MUST NOT be greater than the identifier in any previous frame, since clients might already have retried unprocessed requests on another connection. Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </ins> An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible

Discussion:
Move "A client that is unable to retry requests [...]" sentence from the beginning of an entirely unrelated paragraph to somewhere more appropriate. Change Push ID requirement on subsequent GOAWAY frames. This was presumably an oversight, because "An endpoint MAY send multiple GOAWAY frames indicating different identifiers [...]" paragraph above is pretty clear and covers both directions already.
Change:
A different Captive Portal API URI could be returned in the following cases: <del> Whenever a new Captive Portal API URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to the API. </del> <ins> When the Network Provisioning Service updates the Captive Portal API URI, the User Equipment can retrieve updated state from the URI immediately, or it can wait as it normally would until the expiry conditions it retrieved from the old URI are about to expire. </ins> 5.

Discussion:
There was some concern that section 4 could be seen as normative. To make matters worse, there was some normative text in there. Rework things a bit to address that. Explicitly call out that section 4 is not normative to avoid confusion Move normative text out of 4.3 into 2.1 Add some more description to 4.3 Describe trust for new URIs
Roman writes, It's meant to be informative. Move it Section 2.1 (User Equipment)
We did this in
Benjamin writes, This should be the same as the initial one we received when first accessing the network(e.g. via DHCP, RAs, etc). Perhaps we don't properly indicate elsewhere that this should be supported. I thought we did, but I can't find it... I think we should add a point to Section 2.1 that the UE SHOULD support updates to the captive portal URI from the network provisioning service, and then mention here that that service is what did it. The same trust as mentioned in section 7.1 still applies.
Benjamin writes, Do it.
Change:
candidates for that stream and MAY include a totally new set of candidates. <ins> As described in sec-role, ICE agents MUST NOT re-determine the roles as part as an ICE restart, unless certain criteria that require the roles to be re-determined is fulfilled. </ins> 9. This section defines a new ICE option, 'ice2'.  The ICE option

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
If the application requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data <del> should be send out immediately.  Alternatively, if the application </del> <ins> should be sent out immediately.  Alternatively, if the application </ins> expects to use a specific sending pattern, it can also provide a suggested delay to QUIC for how long to wait before bundle frames into a packet.

Discussion:
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 URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.