jiebi/CodeConvo huggingface dataset:
Change:
consistently identified in the registry, IANA is to rename entry 35 to "session_ticket (renamed from "SessionTicket TLS")". <del> 10. </del> <ins> 11. </ins> IANA is to add the following note to the TLS Exporter Label Registry:

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
these events need to be?  Just support QUIC-style recovery from the spec or broader? <del> Triggers: TODO </del> <ins> TODO: read up on the loss detection logic in draft-27+ and see if this suffices </ins> 5.4.5. <del> Importance: Extra This event is emitted when the single recovery loss timer fires. Data: 5.4.6. </del> Importance: Core This event is emitted when a packet is deemed lost by loss detection.

Discussion:
Not 100% sure this is enough for all the latest draft-27(+) changes though, added a TODO in the draft for that purpose. Also added a packetnumberspace field to metrics_updated to be flexible for implementations that don't want to implement all types of events. It's not a great fit at that location, but it seemed the most synergistic without having a completely new event type. PTAL NAME
Currently, we log in . However, we can have multiple PTO's running across multiple PN spaces and there is no proper way to correlate them with a PN space in metricsupdated. This also impacts the event types. Possible resolutions: Add pnspace attribute to Split PTO count into a separate event (potentially merge with loss_timer?) TODO: reason more about how these metrics are tied to PN spaces in general (are there others than PTO that are duplicated) cc NAME
Most other metrics in the event are independent of the PN space, so that would be weird. I'd prefer to do that. Not sure if it makes sense to merge is with the loss timer events, since we also need to be able to log a reset of the PTO count to 0 (which doesn't require setting of a timer).
Change:
an asynchronous operation, in which each call to Receive enqueues a request to receive new data from the connection.  Once data has been received, or an error is encountered, an event will be delivered to <del> complete the Receive request (see receive-events). As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's Transport Properties. </del> <ins> complete any pending Receive requests (see receive-events).  If Messages arrive at the transport system before Receive requests are issued, ensuing Receive requests will first operate on these Messages before awaiting any further Messages. </ins> 8.1.

Discussion:
: added a statement about data arriving before Receive is issued; : removed the confusing sentence; : carried out replacements suggested by NAME
This issue comes from other discussion at the interim of what it means to map to DSCP classes, and proposes to fix two topics. Replace reference OLD: DSCP Less than Best Effort [LE-PHB] PHB NEW: DSCP Less than Best Effort [RFC8622] PHB — Low Latency/Interactive: The current advice is wrong. An endpoint never should be assigning EF without understanding the implication of CAC and policing. OLD: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; NEW: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) [RFC2597] PHB. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding [RFC3246] or [RFC5865] PHBs. —
The new text resolve this issue.
I'm not sure I understand this sentence (in sec 8. - Receiving Data): "As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's transport parameters." Especially, what's meant by "type of Message"?
Change:
Template: <del> Key: The value to be used as a field name in the directory object </del> <ins> Field name: The value to be used as a field name in the directory object </ins> <del> Resource type: The type of resource labeled by the key </del> <ins> Resource type: The type of resource labeled by the field </ins> Reference: Where the resource type is defined

Discussion:
In the JSON , could be called a "field name" or a "key." We use both in this document, but we should consolidate one one. I think "field name" is better (and NAME agrees). In part this avoids any ambiguity with cryptographic keys.
Change:
the date format defined in For pending orders, the authorizations that the client needs to <del> complete before the requested certificate can be granted (see </del> <ins> complete before the requested certificate can be issued (see </ins> identifier-authorization).  For final orders, the authorizations <del> that were completed.  Each entry is a dictionary with parameters describing the authorization: </del> <ins> that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </ins> The status of the authorization.  This field MUST have the same value as it does in the underlying authorization object.

Discussion:
As discussed at IETF 97, this PR removes the "requirements" abstraction, and changes the "requirements" field in an application/order object to be an "authorizations" field. This is a replacement for .
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98
Change:
8. <del> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. </del> <ins> QUIC connections are closed either by expiration of an idle timeout, as determined by transport parameters, or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. </ins> An immidate close will emit an CONNECTION_CLOSE frame.  This frames has two sets of types: one for QUIC internal problems that might lead

Discussion:
"Idle period", "network idle timeout", and "idle timeout" are distinct; addresses a comment in .
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by
Change:
This specification defines the following ciphersuites for use with MLS 1.0. <del> The KEM/DEM constructions used for HPKE are defined by HPKE.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </del> <ins> The KEM/DEM constructions used for HPKE are defined by I-D.irtf-cfrg- hpke.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment,

Discussion:
Since draft-08, we have neglected to update the changelog, despite a bunch of significant changes. Also, because our CI is busted, some build failures crept in.
Change:
This version of QUIC defines a single packet type that uses the short packet header. <del> The short header can be used after the version and 1-RTT keys are negotiated.  Packets that use the short header contain the following fields: </del> <ins> 17.3.1. A 1-RTT packet uses a short packet header.  It is used after the version and 1-RTT keys are negotiated. 1-RTT packets contain the following fields: </ins> The most significant bit (0x80) of byte 0 is set to 0 for the short header.

Discussion:
This PR restructures 17.3 to be aligned with 17.2. Note that while the diff seems to show whole paragraphs changed in the section, all I've done is replaced with . Note that I've not replaced all uses of . I've retained it where it is used alongside , for symmetry. This still touches more text than I had hoped, but it makes the structure of Section 17 clearer.
NAME Thanks for the note. I've updated the tls doc, but I've left most uses of as they are. I've retained them for symmetry, since in all the ones I've retained, it appears alongside .
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
Update: I think we might want to make corresponding changes to the TLS draft. Re TLS draft, I think we can replace all the occurrences of "short header packet(s)", "packet(s) with (a) short header" in the TLS draft with "1-RTT packet(s)", as well making necessary changes to table 1.This looks good. The actual changes are much smaller than the diff appears, and I think the symmetry with 17.2 helps readability despite the extra layer.
Change:
6.5. <ins> CoAP over reliable transports maintains the property from Section 5.10.1 of RFC7252: The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Unless otherwise noted, the default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message.  The default value of the Uri-Port Option is the destination TCP port. For CoAP over TLS, these default values are the same unless Server Name Indication (SNI) RFC6066 is negotiated.  In this case, the default value of the Uri-Host Option in requests from the TLS client to the TLS server is the SNI host. For CoAP over WebSockets, the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server is indicated by the Host header field from the WebSocket handshake. 6.6. </ins> The steps are the same as specified in Section 6.4 of RFC7252 with the following changes:

Discussion:
RFC 7252 section 5.10.1 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. Do we expect this default value to be applicable (and/or useful) for all the cases we are looking at? Maybe keeping Default-Uri-Host is not such a bad idea after all, or maybe we should clarify that this means for, say, a WebSocket server.
We should simply document appropriate defaults for TLS and WebSockets. There is already text for WS:
Regarding this scenario in RFC7252: Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. This is no longer relevant in CoAP over reliable transports. As Klaus noted in the earlier TRAC issue: In CoAP over WebSockets, the virtual server is specified during the WebSocket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server. (Please correct me if I'm wrong.) In CoAP over TLS we have the SNI extension, so I would expect that CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each virtual server. For the TLS+SNI case, the default value of the URI-Host is the underlying destination address that's shared across the virtual servers. Further note that the Hostname passed in the TLS SNI extension is not an "IP literal": URL - Literal IPv4 and IPv6 addresses are not permitted in "HostName". would still require our draft to support the URI-Host Option for this case: At the moment, this issue does not appear actionable.
Change:
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that incoming data is being discarded on receipt at application request. <del> This signals a peer to abruptly terminate transmission on a stream. Receipt of a STOP_SENDING frame is invalid for a locally-initiated stream that has not yet been created or is in the "Ready" state (see stream-send-states).  Receiving a STOP_SENDING frame for a locally- initiated stream that is "Ready" or not yet created MUST be treated as a connection error of type STREAM_STATE_ERROR.  An endpoint that receives a STOP_SENDING frame for a receive-only stream MUST terminate the connection with error STREAM_STATE_ERROR. </del> <ins> STOP_SENDING requests that a peer cease transmission on a stream. A STOP_SENDING frame can be sent for streams in the Recv or Size Known states (see stream-send-states).  Receiving a STOP_SENDING frame for a locally-initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR.  An endpoint that receives a STOP_SENDING frame for a receive-only stream MUST terminate the connection with error STREAM_STATE_ERROR. </ins> The STOP_SENDING frame is as follows:

Discussion:
URL the case where those streams are implicitly created. There's probably another state here if we were being entirely honest with ourselves to distinguish between a stream that has been created and one that has had frames sent for it, but this is already more complex than it needs to be.
NAME does this sound normal to you?
To clarify, I +1'd your suggestion. More clearly: "Looks good, but I would like you to accept Dimitri's suggestion before submitting this PR."
Ah, alright. I thought it was the other way around.
This LGTM. I was just about to file a similar issue when I saw this.
MAXSTREAMDATA should not be able to be transmitted on uni-directional until frames have been received on the same or a higher numbered stream of same type. Or until the stream is created for bidi streams. If this is not the case, a peer can force the initiator to track unbounded state and frames or risk frames being received when an endpoint is not ready to handle them. See discussion here URL
As I said in that discussion, I don't think there's an unresolved issue here. :
Sorry if that is the case. My impression was that you used it as an example to where we did not have such protection, and didn't care. I'll leave it open for now since the term "has not opened" is also a bit vague. Exactly what state must the sender be in for this to count? And what must the peer observe to conclude this?
This is a non-issue, with the clarifications in the PRs incoming. That is, you can only receive MAXSTREAMDATA for a stream that you have decided to open. At that point you have decided to track considerably more state than a flow control limit. We can leave this until or similar lands.
Thanks
LG minus Dimitri's suggestion
Change:
public key: where "pk" is the HPKE public key encoded by the collector's HPKE key <del> configuration and "output_share" is its serialized output share. This encryption prevents the leader from learning the actual result, as it only has its own share and not the helper's share, which is encrypted for the collector. </del> <ins> configuration, "server_role" is the role of the server ("0x01" for the leader and "0x00" for the helper) and "output_share" is the serialized "OutputShare".  "task_id", "batch_start" and "batch_end" are obtained from the "OutputShareReq".  This encryption prevents the leader from learning the actual result, as it only has its own share and not the helper's share, which is encrypted for the collector. The helper response to the collector with HTTP status 200 OK and a body consisting of the following structure: </ins> <del> It responds with the following message: </del> <ins> "collector_hpke_config_id" is "collector_config.id" from the "Param" corresponding to "CollectReq.task_id". "enc" is the encapsulated HPKE context, used by the collector to decrypt the output share. "encrypted_output_share" is an encrypted "OutputShare", whose structure is given below. </ins> The leader uses the helper's output share response to respond to the collector's collect request (see pa-collect).

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:
receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. <del> 5.2.3.4. If the "IceRestart" option is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).  Similarly, if the ICE configuration has changed, this option has no effect, since new ufrag and pwd attributes will be generated automatically.  This option is primarily useful for reestablishing connectivity in cases where failures are detected by the application. </del> 5.3. When createAnswer is called, a new SDP description must be created

Discussion:
ORTA/ORTV can now be set to a number smaller than the number of MSTs, leading to a=sendonly settings. Also allowed VAD to work in CreateAnswer. ()
LGTM
NAME do you have any remaining concerns?
lgtm
LGTM
Per e-mail, I feel like the text around how to not change extant m= sections is confusing. Ignoring recycling, if we have N mediastreams of which O are old and are sendrecv and someone asks for offerToReceive=M, then we end up with: if O >= M: O sendrecv m= lines N - O sendonly m= lines if O < M: M sendrecv m= lines N - M sendonly m= lines I am fine with that, but I feel like the text may not make it entirely clear.