jiebi/CodeConvo huggingface dataset:
Change:
be used to link a report back to the Client that generated it. To generate a report, the Client begins by sharding its measurement <del> into input shares as specified by the VDAF.  It then wraps each input share in the following structure: </del> <ins> into input shares and the public share using the VDAF's sharding algorithm (VDAF): [TODO: in VDAF-04, "measurement_to_input_shares" will take a nonce argument, for which we will use the report ID #394] The Client then wraps each input share in the following structure: </ins> Field "extensions" is set to the list of extensions intended to be consumed by the given Aggregator.  (See upload-extensions.)  Field

Discussion:
This PR includes several text cleanups previously folded into : The upload section explicitly describes the call to An obsolete TODO in the aggregation section is removed Text that incorrectly instructed leaders to abort if the helper finishes aggregation is corrected.
Change:
Then, for that member, at least the following values have been consumed and MUST be deleted: <del> the init_secret, update_secret, epoch_secret, application_secret of that epoch, </del> <ins> the "init_secret", "update_secret", "epoch_secret", "application_secret" of that epoch, </ins> all node secrets in the AS Tree on the path from the root to the leaf with index i, the first j secrets in the i-th ratchet and <del> application_[i]_[j]_key and application_[i]_[j]_nonce. </del> <ins> "application_[i]_[j]_key" and "application_[i]_[j]_nonce". </ins> Concretely, suppose we have the following AS Tree and ratchet for participant D:

Discussion:
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as if the client had sent value {sha1,ecdsa}. <del> Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA-1. </del> Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in RFC6066

Discussion:
These two notes are leftover from TLS 1.2 and not needed anymore in TLS 1.3. The first may not even be valid anymore.
Change:
This message is always fatal.  [[TODO: IANA Considerations.]] <del> Sent by clients that receive an extended ServerHello containing an extension that they did not put in the corresponding ClientHello. This alert is always fatal. </del> <ins> Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello message, including any extensions in a ServerHello not first offered in the corresponding ClientHello.  This alert is always fatal. </ins> Sent by servers when unable to obtain a certificate from a URL

Discussion:
Modified extension requirements based on recent list discussion. It's a little verbose with repeated boilerplate, but it's clear no matter which section you read now. I've also moved the relevant requirements up top to a consistent place for each extension's section. The level of strictness here is now: If attempting to negotiate and the mandatory extension isn't available: MUST error If just detecting an invalid combination, but not actively negotiating: MAY error SNI is clearly listed as MUST support, servers MAY require, and SHOULD error if required The "unsupportedextension" alert is reworded more generally and put in as the consequence for violating the pre-existing "MUST NOT" send the client-only extensions from a server requirements. Also added some more, namely the fact that "clientkey_share" is clearly an error to be sent from a server.
NAME & NAME Please take a look when you get a chance. Are we all on the same page with this language? Anything that needs tweaking to focus on the above better? Edited to add: Also, do I need to cut out SNI again, or is this wording ok? It's not requiring it to be sent, just noting it must be supported, which was agreed to on list a while ago, and noting the existing case that servers MAY require it with a way to indicate it using the new error alert.
NAME New commit pushed here with changes for your comments: "invalid" -> "prohibited" Text is now: "Servers MUST NOT negotiate use of cipher suites unless the client supplies a supported . If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert." So, trying to find a viable cipher suite is preferred and the error is only required when there's nothing else to do. Edited to note: The latter doesn't contradict the mandatory error on negotiation without the needed extension, as the server simply has the (unlikely) chance of negotiating something completely different instead. The MAY error is still included later in the changeset, as discussed, so clients are still expected to always do this correctly or risk the server throwing an error.
NAME Ok, repushed with one-word change to clarify to "at least one group for each ephemeral key exchange algorithm". This excludes PSK, but is still fine for (EC)DHE when used with it. Seems like the simplest fix.
Change:
17.1. <del> Packet numbers in long and short packet headers are encoded in 1 to 4 bytes.  The number of bits required to represent the packet number is reduced by including the least significant bits of the packet number. </del> <ins> Packet numbers are integers in the range 0 to 2^62-1 (packet- numbers).  When present in long or short packet headers, they are encoded in 1 to 4 bytes.  The number of bits required to represent the packet number is reduced by including the least significant bits of the packet number. </ins> The encoded packet number is protected as described in Section 5.4 of QUIC-TLS.

Discussion:
In Section 12.3, the transport specs says: But in both 17.2 (Long Header) and 17.3 (Short Header), Packet Number field in the packet is noted as the following format: which suggest it isn't variable-length integers. Can we get some clarification regarding this? Thank you!
Section 17.2/17.3 is correct -- PNs are not encoded using the varint form in Sec 16.
Change:
If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this <del> encryption level, saved data can be provided.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> encryption level, saved data can be provided to TLS.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake messages it has received are incomplete or it has no data to send. <ins> The content of CRYPTO frames might either be processed incrementally by TLS or buffered until complete messages or flights are available. TLS is responsible for buffering handshake bytes that have arrived in order.  QUIC is responsible for buffering handshake bytes that arrive out of order or for encryption levels that are not yet ready.  QUIC does not provide any means of flow control for CRYPTO frames; see Section 7.5 of QUIC-TRANSPORT. </ins> Once the TLS handshake is complete, this is indicated to QUIC along with any final handshake bytes that TLS needs to send.  TLS also provides QUIC with the transport parameters that the peer advertised

Discussion:
This also adds a paragraph about buffering of CRYPTO frames that references the buffering text in the transport doc. Closes no issue, but there have been complaints.
Change:
This value contains the length information in the outer-header. <del> Value of the negotiated cid.  This field is empty in case a zero- length cid has been negotiated. </del> <ins> Value of the negotiated CID.  This field is empty in case a zero- length CID has been negotiated. </ins> <del> 1 byte field indicating the length of the negotiated cid.  If a zero-length cid has been negotiated, and therefore no cid appears </del> <ins> 1 byte field indicating the length of the negotiated CID.  If a zero-length CID has been negotiated, and therefore no CID appears </ins> on the wire, a cid_length of zero (0) MUST be added. 5. <del> dtls-example2 shows an example exchange where a connection id is used uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. </del> <ins> dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a zero-length CID we use the term 'connection_id=empty'. </ins> Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.
Change:
frame identifies a server push by Push ID (see frame-push-promise), encoded as a variable-length integer. <del> When a server receives this frame, it aborts sending the response for the identified server push.  If the server has not yet started to send the server push, it can use the receipt of a CANCEL_PUSH frame to avoid opening a push stream.  If the push stream has been opened by the server, the server SHOULD abruptly terminate that stream. A server can send the CANCEL_PUSH frame to indicate that it will not be fulfilling a promise prior to creation of a push stream.  Once the push stream has been created, sending CANCEL_PUSH has no effect on the state of the push stream.  The server SHOULD abruptly terminate the push stream instead. </del> <ins> When a client sends CANCEL_PUSH, it is indicating that it does not wish to receive the promised resource.  The server SHOULD abort sending the resource, but the mechanism to do so depends on the state of the corresponding push stream.  If the server has not yet created a push stream, it does not create one.  If the push stream is open, the server SHOULD abruptly terminate that stream.  If the push stream has already ended, the server MAY still abruptly terminate the stream or MAY take no action. When a server sends CANCEL_PUSH, it is indicating that it will not be fulfilling a promise and has not created a push stream.  The client should not expect the corresponding promise to be fulfilled. Sending CANCEL_PUSH has no direct effect on the state of existing push streams.  A server SHOULD NOT send a CANCEL_PUSH when it has already created a corresponding push stream, and a client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream. </ins> A CANCEL_PUSH frame is sent on the control stream.  Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be

Discussion:
Open to discussion about whether all of these are ID_ERROR or not.
I've tried to improve the readability of this section a bit; I turned Ian's suggested parallel paragraphs around to talk about why client and server would send the frame (and the corresponding responses) instead of talking about behavior on receipt. Please take a fresh look, NAME and NAME
I think there are some edge cases with the CANCELPUSH frame that we don't explain: reception of a CANCELPUSH frame with ID greater than the current push limit reception of CANCEL_PUSH with ID that has already been used
I'd also add a CANCELPUSH from the client for a PUSHID that has not been promised.
CANCEL_PUSH with a reused ID is probably indistinguishable from receiving one for a stream that's already open; you SHOULD reset the stream (which is a no-op if the stream is already full transferred).
Change:
correct when EAP-TLS is used with TLS version 1.3 or higher.  For TLS 1.3 the key schedule is described in Section 7.1 of RFC8446. <del> When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, IV, and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in </del> <ins> When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in </ins> Section 7.5 of RFC8446). Other TLS based EAP methods can use exporters in a similar fashion by

Discussion:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:
Change:
header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <del> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </del> <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,

Discussion:
Also, fixes problem where my previous change to explain the directional attribute for answers was accidentally applied to the offer section.
Not clear whether this should be an example, i.e., in the Examples section, or perhaps just an aside in the setDirection section.
Change:
multiple machines. A method that does not result in any state change on the origin <del> server when applied to a resource.  For example, the GET method only returns a representation of the resource state but does not change the resource.  Thus, it is always safe for a client to retrieve a representation without affecting server-side state. </del> <ins> server when applied to a resource. </ins> A node that listens for requests, performs the requested operation and sends responses back to the clients.

Discussion:
Note about client role and reference to architecture section for details.
+1 (if the newline in the definitions () still does render correctly...
How do you like your newlines cooked?
The definitions seem to render correctly. I'll merge this.
Change:
greater than its own Insert Count, the stream cannot be processed immediately, and is considered "blocked" (see {blocked-decoding}). <del> The SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration) specifies an upper bound on the number of streams which can be blocked.  An encoder MUST limit the number of streams which could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times.  Note that the decoder might not become blocked on every stream which risks becoming blocked. </del> <ins> The decoder specifies an upper bound on the number of streams which can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration).  An encoder MUST limit the number of streams which could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times.  If an decoder encounters more blocked streams than it promised to support, it MUST treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED. Note that the decoder might not become blocked on every stream which risks becoming blocked. </ins> An encoder can decide whether to risk having a stream become blocked. If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,

Discussion:
Emphasize that SETTINGSQPACKBLOCKED_STREAMS is set by the decoder. Move normative sentence on decoder encountering excessive number of blocked streams to this paragraph. Split note to separate paragraph.
:+1: This reads much better to me.
Change:
2. <del> Application servers SHOULD generate and maintain a signing key pair usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes a continuous identity for the application server. </del> <ins> Application servers that wish to self-identity generate and maintain a signing key pair.  This key pair MUST be usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes an identity for the application server that is consistent across multiple messages. </ins> When requesting delivery of a push message, the application includes a JSON Web Token (JWT) RFC7519, signed using its signing key.  The

Discussion:
1 Application Server Self-Identification Application servers SHOULD generate and maintain a signing key pair usable with elliptic curve digital signature (ECDSA) over the P-256 curve [FIPS186]. What is the rationale for SHOULD rather than MUST?
Change:
"issuer_name" is a string containing the name of the issuer.  This is a hostname that is used to identify the issuer that is allowed <del> to issue tokens that can be redeemed by this origin. </del> <ins> to issue tokens that can be redeemed by this origin.  The string is prefixed with a 2-octet integer indicating the length, in network byte order. </ins> "redemption_context" is an optional field.  If present, it allows the origin to require that clients fetch tokens bound to a

Discussion:
For anyone unfamiliar with TLS struct notation, spell out the length fields in the text.
Change:
today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs. <del> However, whenever a non-standard port is used which does not enable easy mapping to a registered service name, this can lead to blocking by network elements such as firewalls that rely on the port number as a first order of filtering. </del> <ins> As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC in general.  For applications with a fallback to TCP which do not already have an alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. Applications SHOULD define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (QUIC-HTTP sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and announce a different port number.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. Note that given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name may lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </ins> 7.

Discussion:
Both documents provide limited guidance on use of ports, however, there was an open question if the applicability statement should maybe say more and e.g. also talk about ALPN.
pending consensus on use of ALPN in -transport
We already have consensus to require ALPN. Unless you meant to refer to URL In that case, yes, you might want to explain how this works for HTTP/3 specifically. That is, the HTTP/3 ALPN refers to QUICv1. For now. We have apparently reserved the right to revise that when we define QUICv2. If you start to explain the controversial aspects of this (does ALPN refer to the layer or the stack as a whole) then you will soon find that you don't have any concrete answers.
Yep, I meant quicwg/base-drafts. This document should provide some advice to application mappings other than HTTP on how/whether to use ALPN, but that advice really will depend on the larger discussion of what ALPN means (is is app-only, a stack designator, or something in between). Having that discussion in this draft is probably not the right thing to do, so holding this issue open until it converges in TLS/HTTP/QUIC.
Probably it would be good to have a more general section on service discovery and point to the HTTP/3 doc as one example.
Create a new section in applicability, and reference the -http draft section 3.1 as an example.