jiebi/CodeConvo huggingface dataset:
Change:
12.3. <del> The packet number is an integer in the range 0 to 2^62-1.  Where present, packet numbers are encoded as a variable-length integer (see integer-encoding).  This number is used in determining the cryptographic nonce for packet protection.  Each endpoint maintains a separate packet number for sending and receiving. </del> <ins> The packet number is an integer in the range 0 to 2^62-1.  This number is used in determining the cryptographic nonce for packet protection.  Each endpoint maintains a separate packet number for sending and receiving. Packet numbers are limited to this range because they need to be representable in whole in the Largest Acknowledged field of an ACK frame (frame-ack).  When present in a long or short header however, packet numbers are reduced and encoded in 1 to 4 bytes, see packet- encoding). </ins> Version Negotiation (packet-version) and Retry packet-retry packets do not include a packet number.

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:
11.1.  URIs <del> [1] https://lists.w3.org/Archives/Public/ietf-httpapi-wg/ </del> <ins> [1] https://mailarchive.ietf.org/arch/browse/httpapi/ </ins> [2] https://github.com/ietf-wg-httpapi/ratelimit-headers

Discussion:
Hi The link to the mailing archive (URL) is 404. I assume the correct link is: URL
Hi NAME thanks for the report, should be fixed soon.
Change:
Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent Event occurs is implementation-specific.  The Sent <del> Event contains an implementation-specific reference to the Message to which it applies. </del> <ins> Event contains a reference to the Message to which it applies. </ins> Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the

Discussion:
Tentatively answering my own questions in : Removed the messageContext here because the RendezvousError does not necessarily relate to a specific sent Message. If it does, the "reason" parameter can point to that message and/or a messageContext. The beginning of Section 7 actually already said that this IS the messageContext. I removed the word "implementation-specific" because to me this word made it sound like this reference can't be the messageContext. Split into two sentences and changed the second sentence to active voice. Also, I slightly reworded the beginning of Section 7, which is now a bit clearer in my opinion.
When reading the current API draft, I found three minor issues related to Message Contexts. The RendezvousError (Section 6.3) includes a messageContext (which is even required), but neither the InitiateError nor the ListenError include one. Why? Should this messageContext at least be optional?In Section 7.3, it says "The Sent Event contains an implementation-specific reference to the Message to which it applies." - Is this in addition to the messageContext? If yes, why do we need both?In Section 9, it says "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." - I think this sentence is a bit hard to parse and it wasn't immediately obvious to me what kind of framing meta-data this refers to. Perhaps this refers to Section 10.2, so I think it's worth adding a reference to that section here. Also, I suggest turning this into two sentences, with the sentence on framing meta-data specifying that this is per-Message metadata to be used by the framer.
Thanks a lot for doing this! It clears things up nicely, I think.
Change:
IETF <ins> 6.2. IANA is asked to create and maintain a new registry called "Captive Portal API Keys", which will reserve JSON keys for use in Captive Portal API data structures.  The initial contents of this registry are provided in json-keys. Each entry in the registry contains the following fields: The JSON key being registered, in string format. The type of the JSON value to be stored, as one of the value types defined in RFC8259. A brief description explaining the meaning of the value, how it might be used, and/or how it should be interpreted by clients. New assignments for Captive Portal API Keys Registry will be administered by IANA through Expert Review RFC8126.  The Designated Expert is expected to validate the existence of documentation describing new keys in a permanent publicly available specification. The expert is expected to validate that new keys have a clear meaning and do not create unnecessary confusion or overlap with existing keys.  Keys that are specific to non-generic use cases, particularly ones that are not specified as part of an IETF document, are encouraged to use a domain-specific prefix. </ins> 7. This work in this document was started by Mark Donnelly and Margaret

Discussion:
As discussed in , define an IANA registry for extending JSON keys use for Captive Portal API.
NAME NAME thanks for the comments. Please take another pass!
Should we define an IANA registry for adding new keys?
Yes, yes we should.
and i already commented in the PR, but if possible it would be beneficial to have some distinction between IETF or a relevant organization (like WFA, WBA) requested keys vs from some individual organization
Would we want to suggest having a nested dictionary format for organization-specific extensions? Like "wba" as a key to a dictionary; or a sub-dictionary indicating that there are WISPr-related settings to be aware of?
i think it would be a good idea. We have seen WBA start to take active interest in the documents. Also there's work happening in WFA that could benefit from having an extension point
RFC 6648 might suggest otherwise. If there are things that a group wants to add that are truly unique to that group, this is probably fine.
Yes, I think that more than having per-group keys (with almost certain overlap), I'd imagine that compatibility with certain technologies would be handled via these sub-dictionaries, such as what I mentioned for WISPr. Not sure how critical mentioning this is in the document though.
Can we call this one done?
I'm assuming we will go down the path of defining an IANA registry with access technology specific extension ?
The description in "Captive Portal API Keys Registry" gives some guidance for prefixes, etc. I assume the experts once designated can work with WFA/WBA to define proper entries.
Change:
The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII "1" followed by 3 0s) for this version of bundles.  If the recipient <del> doesn't support the version in this field, it MUST either ignore the bundle or fetch and use the content of the "primary-url" field instead. The "primary-url" field identifies both a fallback when the recipient doesn't understand the bundle and a default resource inside the bundle to use when the recipient doesn't have more specific instructions.  This field MAY be an empty string, although protocols using bundles MAY themselves forbid that empty value. </del> <ins> doesn't support the version in this field, it MUST ignore the bundle. </ins> The "section-lengths" and "sections" arrays contain the actual content of the bundle and are defined in sections.  The "section-

Discussion:
Closes WICG/webpackage. This is transferred from NAME WICG/webpackage.
The WG hummed in favor of this direction at IETF 110: URL
Change:
Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. <del> loss and batch section describes exceptions to this strategy. </del> <ins> reordering, congestion, and batch describe exceptions to this strategy. </ins> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all

Discussion:
merging.
Endpoints expect the connection to encounter reordering might want to indicate that the receiver should not send immediate acks on receiving a reordered packet.
Change:
In the event that a valid proposal is omitted from the next Commit, the sender of the proposal SHOULD retransmit it in the new epoch. <del> [[ OPEN ISSUE: This structure loses the welcome_info_hash, because new participants are no longer expected to have access to the Commit message adding them to the group.  It might be we need to re- introduce this assumption, though it seems like the information confirmed by the welcome_info_hash is confirmed at the next epoch change anyway. ]] </del> <ins> The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of the "updates" or "removes vectors is greater than zero.  The "path"field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path"field MAY be omitted if the Commit covers only Add proposals. In pseudocode, the logic for whether the "path` field is required is as follows: </ins> A member of the group creates a Commit message and the corresponding Welcome message at the same time, by taking the following steps:

Discussion:
When we converted to the Proposal/Commit scheme, one of the consequences was that Adds became O(N) instead of O(1), since they had to Committed and commits encrypt the committer's direct path to the remainder of the tree. This is ~log(N) in the nice case and ~N in the worst case. At the time, we noted that one could special-case Add-only Commits in the future and make the update to the direct path optional in that case. This PR implements that suggestion. The leaf KeyPackage for the Commit is moved into the DirectPath struct, and the whole DirectPath is made optional. The optional value MUST be provided for: A Commit committing an update or remove A "just update my path" Commit covering no proposals
So we do go forward one epoch, but with an all-zero commit secret. Do I understand that correctly?
NAME That's correct. The idea is that you don't need to send the current group any additional entropy, you just need them to hash forward. Note that this could change the FS/PCS guarantees available. But I don't think we ever proposed that Add would cause any FS/PCS changes to the group, so maybe this doesn't matter.
Add should give FS guarantees in so far as that the new member shouldn't be able to decrypt old messages or derive old keys. But I think ratcheting forward should do the trick. We should note, though, that this breaks the (implicit) assumption that a commit always introduces fresh key material to the group. As far as I can see, that's not breaking anything right now, but we should keep it in mind.
Note: The latest commit fixes a gap that was discovered in .
See the flexibility question.
Change:
2.3. <del> When resuming via a PSK with an appropriate ticket (i.e., one with the "early_data_info" extension), clients can also send data on their first flight ("early data").  This data is encrypted solely under keys derived using the first offered PSK as the static secret.  As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </del> <ins> With the Zero-RTT mode clients can send data on their first flight ("early data") whereby the client uses a PSK either obtained out-of- band or as a ticket (i.e., one with the "early_data_info" extension) from an earlier exchange to authenticate to the server. When clients use a PSK obtained out-of-band then the following information MUST be provisioned to both parties: * PSK identity, * ciphersuite for use with this PSK, * key exchange and authentication modes this PSK is allowed to be used with, * the Application-Layer Protocol Negotiation (ALPN) label(s), and * optionally the Server Name Indication (SNI). As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </ins> handshake in the first flight.  The rest of the handshake uses the same messages as with a 1-RTT handshake with PSK resumption.

Discussion:
I am proposing that a client can also use the Zero-RTT with PSK-based authentication without having to rely on a previously obtained ticket.
Surely there would need to be additional security considerations for this behavior?!
This seems reasonable and was my intent, at least. Can you fix the build problem.
Could you please add linebreaks to wrap to about 80 character or so lines? Our line length is often rather inconsistent, but we do generally try to keep lines shorter than in the current changeset.
This LGTM. I'll let it sit for a little but in case anyone wants to weigh in (NAME NAME NAME
That's the sort of additional considerations that I was expecting to see, yes. I think that you got the list basically right, though there are a few things here that could be clearer.
Change:
2.3. Applications that have a mapping for TCP as well as QUIC are expected <del> to use the same port number for both services.  However, as with TCP- based services, especially when application layer information is encrypted, there is no guarantee that a specific application will use the registered port, or the used port is carrying traffic belonging to the respective registered service.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </del> <ins> to use the same port number for both services.  However, as for all other IETF transports RFC7605, there is no guarantee that a specific application will use a given registered port, or that a given port carries traffic belonging to the respective registered service, especially when application layer information is encrypted.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </ins> Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the

Discussion:
It seems to me that QUIC is no different to other transports in respect of being able to utilise other port numbers, and it would be worth noting that this is normal. The present text might perhaps suggest this is specific to QUIC. Should the text reference RFC 7605 or something else just to explain ports don't imply specific application behaviour, but could infer this?.
The title of the pull request was cause for a momentary flutter - in that I don't see the port as carrying anything other than a reference to a convention - but the text is very good.
Change:
extension.  Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range. Implementations of TLS 1.3 which choose to support prior versions of <del> TLS SHOULD support TLS 1.2.  Servers should be prepared to receive </del> <ins> TLS SHOULD support TLS 1.2.  Servers MUST be prepared to receive </ins> ClientHellos that include this extension but do not include 0x0304 in the list of versions.

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement.  Values of 2^24 or greater are invalid, and receipt of these values MUST be treated as a connection error of type TRANSPORT_PARAMETER_ERROR. </del> <ins> acknowledgement. </ins> An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat

Discussion:
Does it make sense to specify any maximum values for any of the ACK frequency frame fields, such as for Packet Tolerance? Does a value of 4 billion make sense? Can I use a in my implementation to store this locally? Is there any expectation around the sizes of these fields? If there is no explicit max, what if I implicitly apply one? I'm working on implementing this and I'm trying to figure out how small (byte size) I can make the variables I use to store the values on the connection.
Update Max Ack Delay will be limited by the Max Ack Delay limit once lands. That leaves Packet Tolerance, which I agree is reasonable to limit to a value smaller than 2^62-1 locally. We could add a comment like "Implementations that have a lower limit than 2^62-1 on the Packet Tolerance MUST set treat it as though the maximum supported Packet Tolerance value has been received."
Slight tweak: "If an endpoint receives a Packet Tolerance value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable maximum value instead."
If I understand correctly, the maximum value of the transport parameter is supposed to ensure that the value is smaller or equal than the transport parameter. According to the maximum value of is . However, the maximum value of is .
We're going to remove the 2^24 - 1 limit and just rely on the MUST that minackdelay can't be greater than maxackdelay, which implies the 2^14-1 limit.
QUIC Transport specifies a maximum value of 2^14 ms (roughly 16s) for the transport parameter. Does this limit apply to values sent in the field of the ACK_FREQUENCY frame, or is any value up to 2^62 microseconds allowed here? Either way, the draft might benefit from clarifying the rules here.
The editors do not have a strong opinion, and we currently say nothing about the limit being changed by this extension, so we're inclined to keep the limit as is and add some text clarifying that the extension doesn't change the limit. We're open to arguments otherwise if people have them.
Change:
because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer. <ins> Note that because invalid records are rejected at a layer lower than the handshake state machine, they do not affect pending retransmission timers. </ins> 4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that

Discussion:
Zaheduzzaman Sarker wrote -> need to add text
I don't actually understand the ask here. Why would it matter?
I believe he wants us to note that when an invalid record is received and silently discarded then it does not impact timers in any way. It would be surprising if it did but do we want to add a sentence about that?
Since we have a dedicated section for "handling invalid records" that does allow for things other than silent discard, it makes sense to mention the lack of effect on timers. "[...] however, an error MAY be logged for diagnostic purposes. In no case does an invalid record affect pending retransmission timers."?
I'm not sure I agree, but I added something.
Change:
secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import. <del> 6.2. </del> <ins> 6.3. </ins> PSK provisioning systems are often constrained in application- specific ways.  For example, although one goal of provisioning is to

Discussion:
While trying to find a home for this text, I did some other unrelated cleanup. I couldn't find a spot better than the security considerations. cc NAME
Slightly different placement than I suggested, but it works too.
From NAME This is a great point. We can add some language which describes considerations for external PSK reuse with early data.
Martin: I think we should add: When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that makes the keying material for the early data associated with one session different from the keying material for the early data associated win another session. As a result, when the external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. However, this does not address the last point. Early data always has replay concerns. This was discussed at length during the development of RFC 8446. This is the reason that RFC 8446 says that clients "MUST only send early data which they deem safe to be replayed." With that warning in RFC 8446, what more needs to be said here?
Not sure what you mean regarding the last point, but this is a good contribution. How about (copy editing only):
That reads pretty well to me. Thanks, NAME
MT's text also looks good to me. I'm not sure I understand the (as-yet-unaddressed) point about anti-replay performance, though. I mean, I can parse it -- it's a claim that (some? all?) anti-replay implementations will incur more runtime cost than in scenarios where the PSK is reused and the random data is "not good enough". But how would that come to happen? Are we imagining an implementation that uses a hash table and inputs the client random as the hash input, and "not good enough" randomness would cause unbalanced hashing? Or is the nature of the concern on a totally different axis?
Yeah, I think that we can let that point lie. The NSS anti-replay implementation is somewhat vulnerable to hash stacking, but the effect is that early data is accepted less often, it's not that server CPU cycles are wasted.
Change:
connection ID values in transport parameters and verifying them ensures that that an attacker cannot influence the choice of connection ID for a successful connection by injecting packets <del> carrying attacker-chosen connection IDs during the handshake.  An endpoint MUST treat any of the following as a connection error of type PROTOCOL_VIOLATION: </del> <ins> carrying attacker-chosen connection IDs during the handshake. </ins> <del> absence of the initial_source_connection_id transport parameter from either endpoint, </del> <ins> An endpoint MUST treat absence of the initial_source_connection_id transport parameter from either endpoint or absence of the original_destination_connection_id transport parameter from the server as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> <del> absence of the original_destination_connection_id transport parameter from the server, </del> <ins> An endpoint MUST treat the following as a connection error of type TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: </ins> absence of the retry_source_connection_id transport parameter from the server after receiving a Retry packet,

Discussion:
As discussed in URL, most of the errors that can occur when authenticating connection IDs should be TRANSPORTPARAMETERERRORs, not PROTOCOL_VIOLATIONs.
This changes the error codes that we require, so it is technically a design change. I think we'll need an issue to track this.
NAME Created .
The guiding principle here (as we apply it for FRAMEENCODINGERRORs) is that if an error is detectable without accessing connection state, we use the more specific error. So for example, since and are required transport parameters, their absence should be responded to with a TRANSPORTPARAMETERERROR. A similar argument applies to the absence of the TP, although I can see how one might use PROTOCOLVIOLATION here (note that this is still valid behavior with this PR, as every more specific error can be replaced with a PROTOCOL_VIOLATION, if an implementation wishes to do so).
Thanks. I think that this is fine. I will make a few editorial comments on the PR, but I think that the application of the agreed principles is correct.
If you take the suggestions here, I will mark this for inclusion in the next consensus call. (Otherwise, we should continue discussion.)