jiebi/CodeConvo huggingface dataset:
Change:
ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello <del> is large enough to meet the requirements for QUIC packets.  QUIC PADDING frames are added to increase the size of the packet as necessary; see Section 14.1 of QUIC-TRANSPORT. </del> <ins> is large enough to meet QUIC's requirements for datagrams that carry Initial packets; see Section 14.1 of QUIC-TRANSPORT.  QUIC implementations use PADDING frames or packet coalescing to ensure that datagrams are large enough. </ins> 4.4.

Discussion:
Cleanup the language here a little.
This text could be better: Maybe instead:
Does anyone want to prepare a PR? Otherwise, this will get dropped I guess.
I didn't want to clutter our list of stuff with post-IESG PRs. I'll copy the above text once HTTP is done (real soon now). We're going to have to be careful that these little tweaks don't pile up.
I think this should be good to go now?
Change:
[sender]_application_traffic_secret for message protection, Implementations MAY include the length field at their discretion. <ins> The entire header value shown above is used as it appears on the wire as the additional data value for the AEAD function. </ins> 4.1. Implementations can distinguish the two header formats by examining

Discussion:
As I understand, the intent with the record header in AD business was so that DTLS 1.3 would inherit putting the entire header into the AD. However, TLS 1.3 defines the AD as: and DTLS 1.3 defines encryptedrecord as: If one takes the first half of the clause, it works out, but "record header" isn't defined formally. If one takes the second half, it suggests that is not in the AD and it's not clear how 's AD is defined at all. Probably worth clarifying this.
Change:
BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented. <del> 2.3. </del> <ins> 3.3. </ins> For the format defined here, suffix tags are always

Discussion:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.
Change:
The application expects to send/receive data at a constant rate after connection establishment.  Delay and delay variation should be optimized at the expense of bandwidth efficiency. <ins> This implies that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate adaptive congestion controller. </ins> The application is not interactive.  It expects to send/receive a large amount of data, without any urgency.  This can be used

Discussion:
For the Constant Rate capacity profile, should we state that this implies that the connection will fail if there is insufficient capacity? (i.e., you're requesting a circuit breaker rather than congestion control)
may fail instead of will fail, but yeah, this seems sensible.
lgtm
Change:
reserve the content type range 32-63 so that content types in this range are not allocated. <ins> IANA is requested to allocate "the too_many_cids_requested" alert in the "TLS Alerts" registry with value 52. </ins> IANA is requested to allocate two values in the "TLS Handshake Type" registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for

Discussion:
Fix a deadlock identified by NAME This seems like it sets up a deadlock scenario. Consider peers A and B; A sends RequestConnectionId with num_cids=200 and B considers this request excessive, so ACKs it but sends no NewConnectionId in response. A is prohibited from sending another RequestConnection Id to indicate that it really needs new CIDs, since the requested 200 have not arrived yet; thus, B could end up not sending any NewConnectionIds even though A is essentially blocking on getting them. Unless "unfulfilled" is supposed to mean "not ACKed"?
NAME
Done.
Change:
packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in long <del> headers, while it is implicit (depending on Destination Connection </del> <ins> headers, while it is implicit (depending on destination connection </ins> ID length) in short headers.  The length of the packet number is cryptographically obfuscated.

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
7.3.2. <del> This method is indicated by the method value "mtls".  This method defines no additional parameters.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </del> <ins> This method is indicated by the method value "mtls" in string form. The signer presents its TLS client certificate during TLS negotiation with the verifier. </ins> In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to

Discussion:
This reformats the object-type key proofs to be defined in terms of types, in parallel with interaction start methods. Now instead of default field values, you can have either an object with parameters or a string with strictly specified behavior. This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with.
To edit notification comments on pull requests, go to your .
Makes sense, it's aligned with the behaviour of the rest of the doc
Change:
the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2) <del> a URI for the Captive Portal Server. </del> <ins> a URI for the User Portal. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.

Discussion:
To replace "web-portal" and "Captive Portal Server" Address issue
Note: this actually fixed
Sorry, don't know where I got 45 from
Some reviewers have found "Captive Portal Server" to be confusing when read alongside "Captive Portal API Server". Let's change it to something a bit more distinct. Tommy Pauly has suggested "user portal", which seems reasonable. While we're in there, make sure we're consistent with this use. It was also pointed out that we used "web portal" in quite a few places (e.g. sec 2.6, section 4).
A reasonable URL
Change:
If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the Transport Properties actually work over the available paths, then the <del> transport system should report an InitiateError to the application. An InitiateError event should also be generated in case the transport system finds no usable candidates to race. </del> <ins> transport system should report an EstablishmentError to the application.  An EstablishmentError event should also be generated in case the transport system finds no usable candidates to race. </ins> 4.5.

Discussion:
This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!
Change:
The selected ALPN RFC7443 value, if any. <del> The server_name RFC6066 value provided by the client, if any. </del> Future extensions MUST define their interaction with 0-RTT. If any of these checks fail, the server MUST NOT respond with the

Discussion:
This seems to have just been a mistake? Unlike ALPN, servername isn't a value that is selected by the server, so there's no need to match it against a value stored in the session. There is the issue of whether sessions are resumable across names or other application-level contexts (for instance, whether we send client certificates, different cipher profiles, etc.), but that is a more complex issue than simply matching on servername on the server side. Moreover, any rules there would want to apply to resumption as a whole. It seems there's no reason to have 0-RTT-specific rules over resumption ones here.
Change:
a client might offer shares for several elliptic curves or multiple integer DH groups.  The key_exchange values for each KeyShareEntry MUST by generated independently.  Clients MUST NOT offer multiple <del> KeyShareEntry values for the same parameters.  Clients and servers MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supported_groups" extension.  Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its corresponding KeyShare.  Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal "illegal_parameter" alert. </del> <ins> KeyShareEntry values for the same group and servers recieving multiple KeyShareEntry values for the same group MUST abort the connection with a fatal "illegal_parameter" alert.  Clients and servers MUST NOT offer or accept any KeyShareEntry values for groups not listed in the client's "supported_groups" extension.  Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its corresponding KeyShare. </ins> If the server selects an (EC)DHE cipher suite and no mutually supported group is available between the two endpoints' KeyShare

Discussion:
For issue . This relaxes the requirement to check for and error on lack of inclusion in both extensions and focuses the explicit error requirement on the case of multiple keys for the same group.
Clients MUST NOT offer multiple KeyShareEntry values for the same parameters. Clients and servers MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supportedgroups" extension. Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its corresponding KeyShare. Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal "illegalparameter" alert. It's a pain in the ass to check for KeyShareEntry values that are not in the NamedGroups and NSS doesn't presently do it. I think the requirement should be relaxed to just be that you don't select one of them.
NAME I think you wrote this text. Objections?
Relaxing this a bit should be fine. Letting redundant keys slide sounds a bit risky for interop, though. PR with new text submitted.
The "MUST" for what error to throw could be reduced to a "SHOULD", if you'd like to make this even less strict. Not likely to come up that often, though, and I don't see it being more than an interop & waste issue (at least at the moment).
I think that MUST NOT send and MAY generate a fatal error is the right balance here. As an implementation, it's annoying to do this sort of validation because you have to cross validate two extensions, and most of the code for extensions is in the extension handler. Note that even the check for duplicate groups is not something that NSS does. (Did you want to close this now?)
Change:
interface itself; they are equivalent to Actions on a per-application global context. <ins> Events are sent to the application or application-supplied code (e.g. framers, see framing) for processing; the details of event processing are platform- and implementation-specific. </ins> We also make use of the following basic types: Boolean: Instances take the value "true" or "false".

Discussion:
Interface, section 4.1.2: Why the limitation to aliases? Specifying a protocol might limit the utility of connection racing, so should perhaps be discouraged, but does it break anything to specify a protocol for a non-alias Endpoint?
Interim: suggest to remove the second sentence.
They are currently just called "Table"
In the interface draft, Section 1.1: Where is the event sent? Perhaps ?
Interim: add "to the application" (but double check, related to framers)
Could alternatively say the same another way around: "Applications can use these events..." (i.e. avoid saying only applications do this).
Section 6 in impl-draft has the parts where the framer objects receive events. There is no terminology section in implementation, so not sure if the terminology section in API should cover it as well.
We already say this in the intro text to this section, but I can tweak the structure and add some additional text to make this more clear.
The appendix text about convenience functions talks about "implementations should" provide various things. This reads strangely to me. I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things.
How about: " implementations can provide special actions for adding each preference level i.e, TransportProperties.Set(someproperty, avoid) would be equivalent to TransportProperties.Avoid(someproperty):..."
EstablishmentError. Fixed in an upcoming PR.
Change:
This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of <del> the Capacity Profile protocol and path selection property (see prop- cap-profile). The following values are valid for Transmission Profile: No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when sending this message. Response time (latency) should be optimized at the expense of efficiently using the available capacity when sending this message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm); to prefer immediate acknowledgment from the peer endpoint when supported by the underlying transport; to signal a preference for lower-latency, higher-loss treatment; and so on. [TODO: This is inconsistent with {prop-cap-profile}} - needs to be fixed] </del> <ins> the Capacity Profile connection property (see prop-cap-profile). </ins> 7.4.9.

Discussion:
This also addresses two inline [EDITOR's NOTE] items. One was about the per-message override capacity profile being inconsistent with the other one; this was solved by removing details, such that the other one defines the possible choices. Another was about selection vs. connection properties, with broken text. There was no need to add the references as the editor's note says, I thought.
this LGTM, thanks!
Change:
solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. <del> 3.3. </del> <ins> 3.4. </ins> The following rules extend the ABNF syntax defined in RFC3339 in <del> order to allow the inclusion of an optional suffix. </del> <ins> order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule "date-time-ext". </ins> <del> 3.4. </del> <ins> 3.5. </ins> Here are some examples of Internet extended date/time format. <del> This represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note that this is equivalent to 1996-12-20T00:39:57Z in UTC. </del> <ins> rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note that this is the same instant in time as "1996-12-20T00:39:57Z", expressed in UTC. datetime-tzname represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account. date-time-hebrew represents the exact same instant but it informs calendar-aware implementations that they should project it to the Hebrew calendar. date-time-private, based on rfc3339-datetime, utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise. 4. </ins> <del> This represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account. </del> <ins> Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by RFC8126; the IETF review process needs to be based on the requirements laid out in multi-char. </ins> <del> This represents the exact same instant but it informs calendar-aware implementations that they should project it to the Hebrew calendar. </del> <ins> 5. </ins> <del> This timestamp utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise. </del> <ins> TBD </ins>

Discussion:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.
Change:
[1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ietf-wg-httpapi/ratelimit-headers <ins> [3] https://www.iana.org/assignments/http-ratelimit-parameters </ins>

Discussion:
Merge three "add to table" into one request to "add these to the table" Create a new registry for quota fields.
looks good!
NAME NAME I made some edits: ad an addressable subsection for iana-ratelimit-parameters add , to iana table reference specification sections in IANA registries removed normative parts from IANA mention IANA table in {{quota-policy}} Could you please PTAL?
ooops I missed your comment :) Ok, let's merge.
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
architecture to protect against replay attacks. To assess the security provided by a particular Appraisal Policy, it <del> is important to understand the strength of the Root of Trust, e.g., </del> <ins> is important to understand the strength of the root of trust, e.g., </ins> whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM.

Discussion:
Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?
Change:
system and Protocol Stack to handle, some failure of the underlying Protocol Stack, or a set of Message Properties not consistent with the Connection's transport properties.  The SendError contains a <del> reference to the Message to which it applies. </del> <ins> reference to the Message Context of the Message to which it applies. </ins> 7.2.3.

Discussion:
Also spotted some further small nits while reviewing the document, will create a pull request for those.