jiebi/CodeConvo huggingface dataset:
Change:
expected values, or to apply complex analysis of other information contained in the Attestation Result. <del> Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. </del> <ins> Thus, Attestation Results can contain detailed information about an Attester, which can include privacy sensitive information as discussed in section privacy-considerations.  Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. </ins> Finally, whereas Evidence is signed by the device (or indirectly by a manufacturer, if Endorsements are used), Attestation Results are

Discussion:
maybe unclear if this was what was intended
massaged the change a bit to retain the previous statement better
` I'm not convinced this analogy is helpful. Yes, it conveys the need for detailed information but it also immediately suggests Attestation Results might include PII or privacy sensitive identifiers.
I agree that the analogy to physical passports is misleading. The paragraph tries to justify AR as being detailed and privacy sensitive then in the next paragraph tries to describe them as not needing to be too specific; "Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence." It is sufficient to say that both Evidence and Attestation Results can contain privacy sensitive content. The Attester may rely on the Verifier to obfuscate privacy sensitive Claims that were shared as part of Evidence.
It should be clear that appraising Evidence involves various procedures that are part of the appraisal and that these can be quite resource intensive (like creating a passport), in contrast to Attestation Results that are intended to be easily digestible and universal understood (like using a passport)!
add, "URL contain privacy sensitive information as discussed in section {Privacy}"
Change:
Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the <del> connection ID is zero length, all packets of the 5-tuple belong to the same QUIC connection. </del> <ins> connection ID is zero-length, all packets of the 5-tuple likely belong to the same QUIC connection. </ins> 2.4.

Discussion:
Probably, but not certain Especially if you got it wrong regarding the connection ID.
If there is no connection is how would an endpoint identify connection on the same 5-tuple then (for QUICv1)?
It is possible to run multiple connections on the same tuple with trial decryption.
Change:
The design in this document takes a different approach: it assumes that private origins will co-locate with or hide behind a provider <del> (CDN, app server, etc.) which is able to activate encrypted SNI (ESNI) for all of the domains it hosts.  Thus, the use of encrypted SNI does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the IP address. </del> <ins> (CDN, app server, etc.) which is able to activate encrypted SNI, by encrypting the entire ClientHello (ECHO), for all of the domains it hosts.  As a result, the use of ECHO to protect the SNI does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the IP address. </ins> 2.

Discussion:
This change implements the ESNI -> ECHO design discussed in Singapore. There a couple pending TODOs, particularly around cross-CH HRR binding, but the meat is what's currently being analyzed. cc NAME NAME NAME NAME
This still seems a bit rough, but I think better in the spec than out.
Change:
Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. <del> Add designated expert intructions as notes in the TLS </del> <ins> Add designated expert instructions as notes in the TLS </ins> ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert.

Discussion:
Added the guidelines from RFC 5705
Need to add designated expert instructions for exporters like we did for ExtensionType, Cipher Suite, and ClientCertificateType Identifiers registries.
Also addressed by .
Change:
Alternatively, the AS could require N of M possible RO's to approve a given request in order.  The AS could also determine that the end user is not the appropriate RO for a given request and reach out to <del> the appropriate RO asynchronously.  The details of determining which RO's are required for a given request are out of scope for this specification. </del> <ins> the appropriate RO asynchronously. The RO is also allowed to define a policy at the AS to determine which kind of end user can get access to the resource, and under which condition.  For instance, such a condition might require the end user login and the acceptance of the RO's legal provisions. Alternatively, client software could be acting without an end user, and the RO's policy allows issuance of access tokens to instances of that client software without human interaction. The details of determining which RO's or related policies are required for a given request are out of scope for this specification. </ins> The client instance can also indicate that it is capable of facilitating interaction with the end user, another party, or another

Discussion:
to update section 4 to provide an additional use case (RO's policy). I don't think we need to update the definitions or URL
To edit notification comments on pull requests, go to your .
NAME please run on this PR to clean up the line end spaces, otherwise looks good to me. Thanks!
will do ! (btw, I added that to the wiki)
Following the discussion on the mailing list, will plan a rewording to clarify URL Thanks for the feedback. There was a rewrite of section 4 (gathering consent and authorization) that sought to update this, so if that’s still not entirely clear that definitely needs another pass. — Justin >
Change:
parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> If the ICE ufrag or password changed from the previous remote description, then an ICE restart is needed, as described in Section 9.1.1.1 of RFC5245.  If the description is of type "offer", mark that an ICE restart is needed.  If the description is of type "answer" and the current local description is also an ICE restart, then signal the ICE agent to begin checks as described in Section 9.3.1.1 of RFC5245.  An answer MUST change the ufrag and password in an answer if and only if ICE is restarting, as described in Section 9.2.1.1 of RFC5245. </del> <ins> If the PeerConnection state is "have-local-offer", and the ICE ufrag or password changed from the previous remote description, then an ICE restart is needed, as described in Section 9.1.1.1 of RFC5245.  If the description is of type "offer", note that an ICE restart is needed.  If the description is of type "answer" or "pranswer" and the current local description is also an ICE restart, then signal the ICE agent to begin checks as described in Section 9.3.1.1 of RFC5245.  An answerer MUST change the ufrag and password in an answer if and only if ICE is restarting, as described in Section 9.2.1.1 of RFC5245. If the PeerConnection state is "have-remote-pranswer", and the ICE ufrag or password changed from the previous provisional answer, then signal the ICE agent to discard any previous ICE check list state for the m= section and begin checks as if this were the first answer.  However, such an answer MAY only change the ICE ufrag or password if the local offer is starting or restarting ICE for the m= section. </ins> Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their

Discussion:
ICE credentials, DTLS fingerprint and SCTP port are allowed to change, which is necessary to support sequential forking with pranswers.
I still need to read this all carefully but at first glance looks reasonable to me.
LGTM. NAME do you want to take another pass? NAME do you want to take a look?
LGTM
Change:
"Link" header pointing to documentation about the specific rate limit that was hit, using the "help" link relation type. <del> 6.7. </del> <ins> 6.6. </ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges.

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
New entries to this table can be added via "Specification Required" as defined in RFC8126.  The expert SHOULD ensure the specification defines the values for L and T as required in cipher of RFCAAAA. <del> Allocated values MUST be in the range of 1 to 254. </del> <ins> Allocated values MUST be in the range of 0 to 254. </ins> 7.3. IANA is requested to add supported_ekt_ciphers as a new extension name to the "TLS ExtensionType Values" table of the "Transport Layer <del> Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this. </del> <ins> Security (TLS) Extensions" registry: </ins> [[ Note to RFC Editor: TBD will be allocated by IANA. ]]

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
The client initiates a QUIC connection by choosing an initial version and sending a first flight of QUIC packets with a long header to the <del> server INV.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade). </del> <ins> server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade). </ins> Upon receiving this first flight, the server verifies whether it knows how to parse first flights from the original version.  If it

Discussion:
editorial nit: for consitency with RFC 9000, consider changing you reference name from [INV] -> [QUIC-INVARIANTS]
Change:
reused, e.g., to create another Listener. Listening continues until the global context shuts down, or until the <del> Stop action is performed on the Listener object: After calling Stop(), the Listener object can be disposed of. </del> <ins> Stop action is performed on the Listener object. </ins> The ConnectionReceived Event occurs when a Remote Endpoint has established a transport-layer connection to this Listener (for

Discussion:
, . Partially addresses .
sec 7.2 perhaps I'm not thinking of this correctly, but should there be a way to query the peer-offered user timeout?
This looks protocol-specific (it's not a generic transport function). QUIC could let you query it in a protocol-specific property. Proposing moving to the QUIC mapping doc.
I agree with addressing this in the QUIC mapping doc, but for clarification: this is protocol-specific already (it's about a protocol-specific TCP property), and I added a clarification that the API calls reflect the API specified in Section 3 of RFC 5482 (which doesn't include this functionality). => I agree that allowing to query the peer's UTO might be useful, but it's probably not worth adding more text for this, as I also suspect that nobody will implement this for TCP anyway (even the underlying logic from RFC 5482 isn't widely available either AFAIK). If someone does, they are still free to allow querying whatever they like ... but IMO, we shouldn't make this document longer with more protocol-specific elements than we absolutely need to include.
Can we close the Peer user timeout with no-action?
I temporarily gave this a "discuss" label to see if it provokes people to have a 1-minute chat about closing this. This didn't happen, so now I just closed it.
sec 7.1.8 This section is missing a reference to minSendRate and minRecvRate
sec 6.2 "After Stop() is called, the Listener can be disposed of." I don't understand the difference between calling URL() and simply disposing of the object. Does this imply that there is a URL() that allows a configured listener to resume?
We should just not talk about "disposing" here. Just remove the sentence.
Object disposal implies a language with synchronous destruction, something we can't assume. For something garbage collected, you'd need an explicit close method because you don't know when the object will be destroyed.
sec 5.2.9 It would be helpful to say "Applications that neither prohibit nor require congestion should query the result and disable their own congestion control if present in the transport"
Interesting, but we need to be careful in what we say.

It seems safe, but not performant to do CC at multiple layers, and if it's done at a lower layer performance might be improved by not replicating the function at a higher layer...
Link to UDP guidelines document. Just mention that there are performance implications of multiple CC loops; don't just say "disable CC".
Change:
(0x84 for two representations, 0x86 for three, ...) and the sequences of content-format and embedded representations follow. <ins> For instance, the example from encoding would be serialized as: 0x84 (*) 0x182A 0x48 0x0123456789ABCDEF (+) 0x00 0x45 0x3031323334 where (*) marks the start of the information about the first representation (content-format 42, byte string length 8) and, (+), of the second representation (content-format 0, byte string length 5). </ins> 5. 5.1.

Discussion:
Address Benjamin Kaduk's outstanding DISCUSS.
No: with that, the sender sends along all formats and the recipient chooses based on its capabilities or preferences. Appropriate for single-shot mail, not at all appropriate for a request/response situation (at least not for the response part). URL Grüße, Carsten
Ah sorry, hadn't read properly (it's sender, not receiver).
LGTM
Change:
WebRTC's support of secure peer-to-peer connections facilitates deployment of decentralized systems, which can have privacy benefits. <del> As a result, we want to avoid blunt solutions that disable WebRTC or make it significantly harder to use.  This document takes a more nuanced approach, with the following goals: </del> <ins> As a result, blunt solutions that disable WebRTC or make it significantly harder to use are undesirable.  This document takes a more nuanced approach, with the following goals: </ins> Provide a framework for understanding the problem so that controls might be provided to make different tradeoffs regarding

Discussion:
This reverts commit 0dac1b124828835c5785c4ae703c26ad3d19f65f.
Change:
design decisions that could impact the operation of QUIC-LB. The maximum Connection ID length could be below the minimum necessary <del> for one or more encoding algorithms. </del> <ins> to use all or part of this specification.  The minimum Connection ID length could exceed the limits in this specification. </ins> unroutable provides guidance about how load balancers should handle unroutable DCIDs.  This guidance, and the implementation of an

Discussion:
in accordance with the 2nd crypto review
In the second crypto review () there was a note that plaintexts of different lengths might end up with similar results, if the extra bits were zeros. The suggestion to fix this was to update the path index to also include the length.
Looks good, except for the missing parenthesis.
Change:
TLSInnerPlaintext.content. The padding sent is automatically verified by the record protection <del> mechanism: Upon successful decryption of a TLSCiphertext.fragment, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet.  This non-zero octet is the content type of the message.  This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which allows for quick detection of padding errors. </del> <ins> mechanism: upon successful decryption of a TLSCiphertext.encrypted_record, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet.  This non-zero octet is the content type of the message.  This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which allows for quick detection of padding errors. </ins> Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption.  If a receiving implementation does not

Discussion:
I forsee some merge conflicts in the future, as there's already and I have plans to rototill this section a bit more than you do here.
This won't conflict with . Git is good at detecting identical changes.
Change:
any more messages on this connection.  Any data received after a closure MUST be ignored. <del> This alert is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be sent at all) and that the following records are protected under handshake traffic keys.  This alert MUST be at the warning level. Servers MUST NOT send this alert and clients receiving it MUST terminate the connection with an "unexpected_message" alert. </del> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just

Discussion:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.
Change:
Where Hash is the authenticator hash defined in section 4.1.  If the authenticator request is not present, it is omitted from this <del> construction, i.e., it is zero length. </del> <ins> construction, i.e., it is zero-length. </ins> If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the

Discussion:
got merged while I was reviewing it, so here's my feedback as a follow-up PR. I initially though line 244 needed a comma, but usage through the rest of the document suggests that supporting certificates are a property of one type of identity instead of something that could come along with a generic identity, so I dropped that one.
Thanks, Mike.
Change:
4.1.2. <ins> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints.  It is an abstraction that represents the communication.  The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  For example, an active Connection can represent a connection-oriented protocol such as TCP, or can represent a fully-specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the endpoints.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </ins> Preconnection: A Preconnection object is a representation of a Connection that has not yet been established.  It has state that describes parameters of the Connection: the Local Endpoint from

Discussion:
Review comment: Section 4.1.2 : I would describe the object first and then the transport properties. In the current arrangement when properties are described it mentions Connection which is described just later. Also transport properties here are kind of repetition of what we have in Section 3.1. reordered descriptions, which also to me at least, seems to make the text on properties better relate to the action
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM
Change:
As a result, client implementations are encouraged to avoid using source ports associated with protocols known to be vulnerable to <del> reflection attacks.  Note that the list above is not exhaustive; other source ports might be considered reflection vectors as well. </del> <ins> reflection attacks.  Note that following the general guidance for client implementations given in RFC6335, to use ephemeral ports in the range 49152-65535, has the effect of avoiding these ports.  Note that other source ports might be reflection vectors as well. </ins> 9.

Discussion:
Section 8.1 talks about "Services might block source ports" and then lists a bunch. But contacting a service should really happen from an ephemeral source port, which would be as per suggestion the range 49152–65535. None of the examples in this section come from these ports, so it feels like if one picks proper ephemeral ports, there is no relevant blocking issue at all that this section talks about. Perhaps that is the advise this section should give?
Change:
option-code: The Captive-Portal DHCPv6Option (103) (two octets) <del> option-len: The length, in octets of the URI. </del> <ins> option-len: The unsigned 16-bit length, in octets, of the URI. </ins> URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). See RFC7227, Section 5.7 for more examples of DHCP Options with URIs. <ins> See RFC8415, Section 21.1 for more on the format of IPv6 DHCP options. </ins> Note that the URI parameter is not null terminated.

Discussion:
Additionally: Update DHCPv6 reference from RFC 3315 to RFC 8415. Include reference to DHCPv6 option format text. Include reference to DHCPv4 option format text in RFC 2132. The DHCPv4 and v6 diagrams are not harmonized in this change. Each option format has sever documents using the style currently depicted. Issue:
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.