jiebi/CodeConvo huggingface dataset:
Change:
4.6.2. When the client has sent the "post_handshake_auth" extension (see <del> post_handshake_auth), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message.  The client MUST respond with the appropriate Authentication messages (see authentication-messages). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished.  If it declines, it MUST send a Certificate message containing no certificates followed by Finished. All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types. </del> <ins> post_handshake_auth), a server MAY request certificate-based client authentication at any time after the handshake has completed by sending a CertificateRequest message.  The client MUST respond with the appropriate Authentication messages (see authentication- messages).  If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished.  If it declines, it MUST send a Certificate message containing no certificates followed by Finished.  All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types. </ins> A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert. <del> Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response.  In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses). </del> <ins> Note: Because certificate-based client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response.  In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses). </ins> 4.6.3.

Discussion:
Based on the PSK authentication was not included in the past. I think specification has some places where "Client Authentication" refer to only certificate-based client authentication and not client authentication is general. Not a big thing, but I think it might confuse some readers, and would be good to clarify.
Change:
A Client Initial packet exposes the version, source and destination connection IDs without encryption.  The payload of the Initial packet <del> is obfuscated using the Initial secret.  The complete TLS Client </del> <ins> is protected using the Initial secret.  The complete TLS Client </ins> Hello, including any TLS Server Name Indication (SNI) present, is sent in one or more CRYPTO frames across one or more QUIC Initial packets. The Server Initial datagram also exposes version number, source and destination connection IDs in the clear; the payload of the Initial <del> packet(s) is obfuscated using the Initial secret. </del> <ins> packet(s) is protected using the Initial secret. </ins> The Client Completion flight does not expose any additional information; however, as the destination connection ID is server-

Discussion:
The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...
Change:
6.6. <del> The ISO 19770-2:2015 SWID specification describes use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations.  This document continues this use for CoSWID.  The following subsections provide registrations for these schemes in to ensure that a permanent registration exists for these schemes that is suitable for use in the SWID and CoSWID specifications. URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at IANA.uri-schemes. 6.6.1. IANA is requested to register the URI scheme "swid".  This registration request complies with RFC7595. 6.6.2. IANA is requested to register the URI scheme "swidpath".  This registration request complies with RFC7595. 6.7. </del> The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence

Discussion:
Removed IANA registrations for swid and swidpath and updated text to note these are not technically URIs but just expressions using URI syntax.
Change:
authenticating to, and interacting with the captive portal is out of scope of this document. <ins> RFC7710 used DHCP code point 160.  Due to a conflict, this document specifies TBD. </ins> [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of the document, open issues, etc should all be available here.  The

Discussion:
Forgot to make PR. This is the "good" one, should be abandoned...
Nope -- I think it is still TBD - we've asked / strongly suggested 114 in the IANA section, but I think it would feel presumptive to state that it is... W
I believe this should be changed to 114, or IANA-TBD.
Yikes, good catch. I changed it to TBD, and also added a sentence to the Abstract noting that it has changed from 160 to TBD (it seemed important enough). Thank you! W
NAME have changed or will change? I can't see this in the current version(s) of the draft here.
I swear I'd done this, and event sent a PR, but I cannot find it.... so, just made a new one...
I had created the branch, and made the edits, but apparently forgot to make the PR.... and then, because I couldn't find it, I made a new branch, change and PR (), and then realized the original was better, so I removed PR and created ... Oy vey, W
Done, had forgotten to close...
Should the TBDs be 114? Either that, or the list of changes should be TBD as well?
Change:
2.6. <del> First time request (idempotency key or fingerprint has not been </del> <ins> First time request (idempotency key and fingerprint has not been </ins> seen) The resource server SHOULD process the request normally and respond with an appropriate response and status code. <del> Duplicate request (idempotency key or fingerprint has been seen) </del> <ins> Duplicate request (idempotency key and fingerprint has been seen) </ins> Retry The request was retried after the original request completed.  The <del> resource server MUST respond with the result of the previously completed operation, success or an error. </del> <ins> resource server SHOULD respond with the result of the previously completed operation, success or an error.  See Error Scenarios for details on errors. </ins> Concurrent Request

Discussion:
1- Addressed comments wrt 5XX codes being retriable 2- Elaborated the security section to describe security issues relating to the idempotency key
Change:
A receipt subscribe resource is used by an application server to create a receipt subscription (see receipt_subscription).  A link <del> relation of type "urn:ietf:params:push:receipt" is used to identity a receipt subscribe resource. </del> <ins> relation of type "urn:ietf:params:push:receipts" identifies a receipt subscribe resource. </ins> An application server request_receipt for push messages using a <del> receipt subscription. </del> <ins> receipt subscription.  A link relation of type "urn:ietf:params:push:receipt" is identifies a receipt subscription. </ins> 3.

Discussion:
Is there any value in using a link relation type for the receipt subscription rather than a new header field? We already have to define the link relation type, so maybe it can save on a bit of protocol machinery.
While considering this, I noticed an editorial error in Section 10.2 where the link relation is referenced as urn:ietf:push:receipts instead of urn:ietf:push:receipt which is used throughout the rest of the draft. Using a link relation might be more consistent - not sure that it saves on protocol machinery? Are you proposing to replace the Push-Receipt header with a new link relation - potentially there would be: push:receipts - to create new receipt subscriptions push:receipt - a specific receipt subscription
Yes, there are the same number of moving parts. My mistake. Just remembered the actual reason for opening the issue. The HTTP working group often state that header fields need to have wide applicability for them to be defined, otherwise the data they carry is best carried in payload bodies. The same restriction does not apply to link relations.
Change:
to invalid records by terminating the connection. The security and privacy properties of the CID for DTLS 1.3 builds on <del> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </del> <ins> top of what is described for DTLS 1.2 in I-D.ietf-tls-dtls- connection-id.  There are, however, several differences: In both versions of DTLS extension negotiation is used to agree on the use of the CID feature and the CID values.  In both versions the CID is carried in the DTLS record header (if negotiated). However, the way the CID is included in the record header differs between the two versions. </ins> The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with

Discussion:
In both versions of DTLS we have to do the extension negotiation because you have to agree on the CID values. In both versions we have to carry the CID in the record layer (if the CID is used). The way we incorporated the CID into the headers is different between the different versions. In DTLS 1.3 we have this variable length header and in DTLS 1.2 we don't. There are also privacy differences.
I'm inclined not to add anything here. If you feel strongly maybe you could provide a PR?
I think the privacy differences (and ability to change values over the lifetime of an association, e.g., when roaming) are probably worth mentioning. NAME do you plan to write some text? If not I can try to squeeze it in.
PR is available at
Fixed in . Closing.
LGTM
Change:
In constrained environments it cannot be assumed that the client <del> and RS are part of a common key infrastructure.  Therefore the AS provisions credentials or associated information to allow mutual authentication between client and RS.  The resulting security association between client and RS may then also be used to bind these credentials to the access tokens the client uses. </del> <ins> and the RS are part of a common key infrastructure.  Therefore, the AS provisions credentials and associated information to allow mutual authentication between the client and the RS.  The resulting security association between the client and the RS may then also be used to bind these credentials to the access tokens the client uses. </ins>

Discussion:
This terminology decision was made in early days of OAuth = long time ago. Done. Done. Changed. I added a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol. Text added. >-- Section 5 -- Text changed. >-- Section 5.1.1 -- >Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust. Text changed to "unsecured channel" >-- Section 5.1.2 -- I assume you mean "Section 5.3". Text added. >-- Section 5.5 -- >In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ? I cannot find this text in the document. >-- Section 5.6 -- OK OK. >-- Section 5.6.4.1 -- >In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749. Done. >-- Section 5.7.2 -- >It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ? I cannot find this text. >-- Section 5.8.1 -- >Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'" Changed. >-- Section 10.2 -- >Is RFC 7049 really an informative reference as CBOR appears as the default encoding ? Changed to a normative reference and updated reference. All nits below have been addressed.
Comments addressed in this PR: URL
Merged
Change:
3. <del> Names are formed using Port-Prefix Naming (SVCB Section 2.3), with a scheme of "dns".  For example, SVCB records for a DNS service identified as "dns1.example.com" would be located at "_dns.dns1.example.com". </del> <ins> Names are formed using Port-Prefix Naming (Section 2.3 of SVCB), with a scheme of "dns".  For example, SVCB records for a DNS service identified as ""dns1.example.com"" would be located at ""_dns.dns1.example.com"". </ins> 3.1.

Discussion:
The lack of quoting in some of the examples might make it harder to see what constitutes example and what is punctuation. Highlighting and fonts in the HTML rendering are subtle and not present in text renderings (any more). I've also changed some section references. I'm happy to split that off into a different change or use the form if you prefer that.
Change:
satisy the requested Stream Send or Stream Receive Bitrate, based on the observed maximum throughput; <del> Capacity-Seeking: Prefer adpating to paths to determine the </del> <ins> Capacity-Seeking: Prefer adapting to paths to determine the </ins> highest available capacity, based on the observed maximum throughput.

Discussion:
This is a first cut, I'll update next.
The Capacity Profile in the API draft (now) lists these possible choices: Default, Scavenger, Low Latency/Interactive, Low Latency/Non-Interactive, Constant-Rate Streaming and Capacity-Seeking. The text in section 4.1.3 only discusses Scavenger, Low Latency/Interactive, and Constant-Rate Streaming.
Aha - I could offer to align the Capacity Profile classes?
See a PR to align Capacity profile with API
Resolved
LGTM, thanks!
Change:
version such that commonly deployed versions are compatible with it. For example, a successor to QUIC version 1 may wish to design its transport parameters in a way that does not preclude compatibility. <del> Additionally, frames in QUIC version 1 do not use a self-describing encoding, so unrecognized frame types cannot be parsed or ignored (see the Extension Frames section of QUIC); this means that new versions that wish to be very similar to QUIC version 1 and compatible with it should avoid introducing new frames in initial packets. </del> 11.

Discussion:
In : This is not an issue. If v2 defines a new frame type that can appear in Initial-equivalent packets, then to be compatible with v1 (in both directions) that frame type could simply be optional in v2. The lack of a self-describing encoding is not an issue as the parsing of the v2 packet is done with knowledge of all the core frame types in v2. Sure, you can't introduce an extension frame here, but that's true of v1 on its own. The only way in which a version might become incompatible is if it includes new information that can't be inferred from the other version or doesn't have a valid default. I think that the intent of this was to say that if there is any need for the Initial flight to carry new information that is only consumed by a compatible version, then there is no way for QUIC version 1 to carry that new information by using new frames. Instead, it has to use a field in v1 that would be ignored by a v1 endpoint. As v1 defines no real extension points of this sort, the options in this case are limited. I think that this text can be removed. Maybe you could talk about the problem of carrying version-specific information in other versions.
This makes sense. This text was somewhat vestigial from earlier designs of this mechanism.
Change:
Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) <del> or Relying Party (for Attestation Result) is willing to accept. Freshness is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </del> <ins> or Relying Party (for Attestation Result) is willing to accept.  Some flexibility on the freshness requirement, however, is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </ins> There are two common approaches for determining the epoch of an Evidence or Attestation Result.

Discussion:
Signed-off-by: Dave Thaler
` I think what you mean is that “some flexibility on the requirement for freshness is a key component…”, i.e., it’s the willingness to accept a result that’s been around for a while enables caching.
agree.
Change:
Response: <ins> Since the field values are not necessarily correlated with the response status code, a subsequent request is not required to fail. The example below shows that the server decided to serve the request even if "RateLimit-Remaining" is 0.  Another server, or the same server under other load conditions, could have decided to throttle the request instead. Request: Response: </ins> 8.1.2. The server uses two custom fields, namely "acme-RateLimit-DayLimit"

Discussion:
clarifies that status code is independent from the values of RL fields the example reflects the above statement.
Would there be scope to define standards for the 429 response or would that be more relevant to RFC6585. Should RFC6585 be extended to mention this RFC ?
This I-D is independent from the status code of the response, so I'd say there are no normative relations between this doc and RFC6585. This is by design: we just want to standardize response fields without explicitly define a "ratelimit protocol". Instead, we want implementers to be free to implement their throttling strategies.
See. URL
I noticed in the example in You return a 200 response with RateLimit-Remaining: 0 . It is not completely clear in the document that a remaining value of 0 should be returned to the caller as a success when the quota has been used exactly. In you present a case where the cost of a more expensive call deducts two from the remaining pool and results in a 429. I am conflicted as to whether it should be a server decision whether the call is respected or whether the spec should strictly define this behaviour. I lean toward the former but some feel guidance is needed.
we should clarify that this is a server choice. The spec does not mandate any correlation between the RL values and the returned status code . The server can always decide to serve requests even when quota is over. We need to clarify this both in the text and in the example.
That is something that was not clear to me when reading the spec. The assumption being that when is exhausted, a user will be rate limited and an error response (429) will be issued. It would seem as per and that there is no specific intention to require a server implementation to deny further responses, but rather in some cases the expectation would be for the client to gracefully comply and back off. My feeling is though that this use case would be the exception rather than the rule, with most implementations opting to deny further requests. Should we not at least provide guidance that a 429 response should be issued in this scenario ?
Change:
defined in long-header.  A Version Negotiation packet is identifiable as such by the Version field, which is set to 0x00000000. <del> The Version Negotiation packet contains a list of Supported Version fields, each identifying a version that the endpoint sending the packet supports.  The Supported Version fields follow the Version field.  A Version Negotiation packet contains no other fields.  An endpoint MUST ignore a packet that contains no Supported Version fields, or a truncated Supported Version. </del> <ins> Only the most significant bit of the first byte of a Version Negotiation packet has any defined value.  The remaining 7 bits, labeled Unused, can be set to any value when sending and MUST be ignored on receipt. After the Source Connection ID field, the Version Negotiation packet contains a list of Supported Version fields, each identifying a version that the endpoint sending the packet supports.  A Version Negotiation packet contains no other fields.  An endpoint MUST ignore a packet that contains no Supported Version fields, or a truncated Supported Version. </ins> Version Negotiation packets do not use integrity or confidentiality protection.  Specific QUIC versions define mechanisms to authenticate

Discussion:
As Magnus noted, the description of the first byte is missing, and I also noticed that the Supported Version field was described as following Version, which is wrong.
For -09 in WG LC. Section 6 has a packet header structure with the field: Unused (7) All the other fields are either fixed value or kind of defined earlier. In fact I would argue they represent concepts that are defined in -transport. Thus a second part of this is if -transport needs to be normative reference for the concepts used in this document. But back to Unused: I think this field can take any value on transmission, and should be ignored on reception. Maybe this needs to be noted explicitly in Section 6.
It's very deliberate that Invariants does not normatively depend on Transport. Invariants needs to stand alone, as a description of what versionless QUIC means. Arguably, Transport could normatively depend on Invariants, but it chooses instead to restate the things it depends on and make the reference informative.
Change:
[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 8.6.3. </del> <ins> 8.6.5. </ins> This registry lists the types of identifiers that ACME clients may request authorization to issue in certificates.

Discussion:
As discussed at IETF 97, this PR creates specification-required registries of fields in ACME objects, so that they can be extended in an orderly fashion. Currently only applies to account and order objects, not authorizations. Not for any ideological reason -- I would be happy to add that for symmetry if people think there might be a need..
Change:
Application Data may appear only in the Early Data and Application Data levels.  Handshake and Alert messages may appear in any level. <del> The 0-RTT handshake is only possible if the client and server have </del> <ins> The 0-RTT handshake can be used if the client and server have </ins> previously communicated.  In the 1-RTT handshake, the client is unable to send protected Application Data until it has received all of the Handshake messages sent by the server.

Discussion:
Though I guess provisioning of a PSK depends on prior communication of a sort, there is no need to be so absolute here.
NAME said:
I will suggest that we strike the "only" here.