jiebi/CodeConvo huggingface dataset:
Change:
Endpoints SHOULD abandon path validation based on a timer.  When setting this timer, implementations are cautioned that the new path could have a longer round-trip time than the original.  A value of <del> three times the larger of the current Probe Timeout (PTO) or the initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY is RECOMMENDED.  That is: </del> <ins> three times the larger of the current Probe Timeout (PTO) or the PTO for the new path (that is, using kInitialRtt as defined in QUIC- RECOVERY) is RECOMMENDED. </ins> This timeout allows for multiple PTOs to expire prior to failing path validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE

Discussion:
Address validation can use 3*PTO, just taking the maximum of the old and new path PTO. The idea of initial timeout is easily replaced in recovery by instead describing the effect on the PTO. The net effect is the same, except that new paths often have to include the maximum ACK delay, which this doesn't incorporate.
A quick look in the reference did not show what units of time you are using in the protocol - maybe I missed it?
is set to 333ms. Not sure why a max between two values needs to define the unit in the first place though.
is not defined in -transport, and Stewart was (probably) only reviewing the document in isolation.
NAME a max needs to ensure both values use the same units. But provided that they do, I agree.
Maybe it's easier to say that these are all physical quantities, or numbers with units. In the specification, we use seconds, milliseconds, microseconds. That's fine, because we know how to align the units when we make calculations (e.g., max).
PR proposes removing the text in question. Of course, it doesn't matter what time units are in use in this case. I'm fairly confident that where units matter (i.e., we base the value on a constant), the units are explicit. Here, the units are part of the definition of the variables.
As Martin points out, the offending text was removed. Not seeing anything to be done here , so I'm closing the issue.
says "initial timeout (that is, )". But I don't think that we have this initial timeout concept in recovery any more; we . Should this just be now? The result is that the is meaningless as the PTO is when initialized. Or is this the PTO on the pre-existing path?
I think this is the case. Notice "current." Therefore I belive that the formula should be .
Changing 2kInitialRtt to 3kInitialRtt and 6kInitialRtt to 9kInitialRtt seems like the simplest fix since we don't define an initial_PTO variable anywhere in the documents.
I assume that the choice between and is purely editorial. Either works for me.
I prefer with some changes that I've noted on the PR.
I think this is correct. LGTM, but waiting for NAME to take a look.
Change:
corrections.  Network propagation delays are the most likely causes of a mismatch in legitimate values for elapsed time.  Both the NewSessionTicket and ClientHello messages might be retransmitted and <del> therefore delayed, which might be hidden by TCP. A small allowance for errors in clocks and variations in measurements is advisable.  However, any allowance also increases the opportunity for replay.  In this case, it is better to reject early data and fall back to a full 1-RTT handshake than to risk greater exposure to replay attacks.  In common network topologies for browser clients, small allowances on the order of ten seconds are reasonable.  Clock skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric replay window. </del> <ins> therefore delayed, which might be hidden by TCP.  Thus, an an allowance on the order of ten seconds to account for errors in clocks and variations in measurements is advisable.  Outside this range, the server SHOULD reject early data and fall back to a full 1-RTT handshake.  Clock skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric range of permissible mismatch values. </ins> 4.3.

Discussion:
…s , , .
NAME if you want to propose some revised text, I will TAL.
From Nikos's comment:
This is relating to . I will try to resolve both issues.
It is hard to understand the current text of Section 4.2.9.3 (Replay Properties). NAME explained me that a server should check: The server can tell: serverrecvtime == now serversendtime == one parameter in the ticket clientsendtime - clientrecvtime == ticketage == obfuscatedticketage + ticketage_add If this understanding is correct, I would suggest to add more explanation to the section.
Yes, that's correct. PRs welcome
I made a tweak to avoid referring to the "base value", in , though more changes may still be helpful.
Change:
of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to <del> Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  Both Alice and Bob are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </del> <ins> Bob's endpoint.  The messages from the Javascript application in Alice's browser to the Javascript in Bob's browser, abbreviated as AliceJS and BobJS respectively, are assumed to flow over some signaling protocol via a web server.  The Javascript on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  The user agents (JSEP implementations) in Alice and Bob's browsers, abbreviated as AliceUA and BobUA respectively, are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </ins> The SDP for |offer-A1| looks like:

Discussion:
I think I got all the things Justin mentioned.
Will take a final look once Eric's comments are resolved.
Made a slight change to one sentence to mention user agents. PTAL.
For the examples, please expand the acronyms "JS" and "UA".
I think we're going to want to do it once.
I think I want to define some of theses instead of replace all of them because we can't stay in the column limit if they are expanded.
Change:
For X25519 and X448, see RFC7748. <del> 7.3.3. </del> <ins> 7.5. </ins> RFC5705 defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF).  This document replaces the PRF with

Discussion:
Exporters and (EC)DHE secrets are not traffic secrets. Group the two (EC)DHE sections under a name which matches what the key schedule section calls it (the "(EC)DHE shared secret") and link to it from the key schedule.
Change:
implementations MUST give precedence to whichever value is positioned first. <del> 2.2. </del> <ins> 3.2. </ins> Actual suffix tag keys are registered by supplying the information specified in this section.  This information is modeled after that

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:
[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 8.6.4. </del> <ins> 8.6.6. </ins> This registry lists the ways that ACME servers can offer to validate control of an identifier.  The "Identifier Type" field in template

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:
the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their <del> semantics in this way is intended to mitigate thee risk of cross </del> <ins> semantics in this way is intended to mitigate the risk of cross </ins> protocol attacks involving delegated credentials. The code changes to create and verify delegated credentials would be

Discussion:
Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me
Change:
RFC4291, whose identity cannot be safely confirmed using TLS certificates under most conditions. <del> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  Opportunistic Privacy similarly applies to DoQ RFC9250.  A client MAY use information from the SVCB record for "resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </del> <ins> An Opportunistic Privacy Profile is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  This Opportunistic Privacy Profile similarly applies to DoQ RFC9250.  For this profile, Section 4.1 of RFC7858 explains that clients might or might not validate the resolver; however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses. A client MAY use information from the SVCB record for "resolver.arpa" with this Opportunistic Privacy Profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </ins> 5.

Discussion:
…tion
Section 4.2, verified, calls out the entire cert check for validation, but section 4.3, opportunistic, only talks about skipping the IP validation. It has gone without saying that these are equivalent because the IP is the only thing about the cert being validated, but for implementors, does this mean they can skip the entire cert validation process (meaning the connection will be used even if other errors occur, such as the cert being expired)? I assume yes (no cert checking of any kind), but we should be specific.
I think it's up to implementations. If I look at the opportunistic profile in RFC 7858, it say: I think we should point to that and explain that it's open to the client to determine how opportunistic it wants to be
LGTM
Change:
Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> The header MAY also include the standard "realm" attribute, if </del> <ins> The header field MAY also include the standard "realm" attribute, if </ins> desired.  Issuance protocols MAY require other attributes. <del> As an example, the WWW-Authenticate header could look like this: </del> <ins> As an example, the WWW-Authenticate header field could look like this: </ins> Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the

Discussion:
This one goes out to all the HTTP pedants out there =)
There's a few cases of rather than , which is puts you on HTTP's naughty list
Change:
2.1.1. <del> Full-featured hosts are either configured manually with a </del> <ins> Full-featured hosts either are configured manually with a </ins> registration domain, or discover the default registration domain as described in RFC6763.  If this process does not produce a default registration zone, the Service Registration protocol is not

Discussion:
I had a brief chat with Qiaoyu and the change here is the result of that discussion, including a minor editorial fix that makes a compound sentence a little more comprehensible (I hope).
Change:
have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. <del> Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF". </del> <ins> The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer. </ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates have yet been

Discussion:
I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm
Change:
If this is an external commit, assign the sender the leftmost blank leaf node in the new ratchet tree.  If there are no blank <del> leaf nodes in the new ratchet tree, add a blank leaf to the right side of the new ratchet tree and assign it to the sender. </del> <ins> leaf nodes in the new ratchet tree, expand the tree to the right as defined in adding-and-removing-leaves and assign the leftmost new blank leaf to the sender. </ins> Update the sender's direct path in the ratchet tree as described in synchronizing-views-of-the-tree.  Define

Discussion:
This PR fixes small issues that I noticed while implementing proposal validation and fixing some external join bugs: The pseudocode for determining whether a path is required assumes that all proposals are by-reference. The PR updates the pseudocode to be more general, and also account for proposals by value. There were two references to adding a single leaf to the tree, which are updated to make clear that the tree grows by doubling, not by single leaves. There was no current requirement that an Update proposal have a distinct , so one is added.
Change:
former is used to update the confirmed transcript hash and the latter to update the interim transcript hash. <del> In this notation, "InterimTranscriptHashInput_[epoch]" and "ConfirmedTranscriptHashInput_[epoch+1]" are based on the Commit that initiated the epoch with epoch number "epoch".  (Note that the "epoch" field in this Commit will be set to "epoch - 1", since it is </del> <ins> In this notation, "ConfirmedTranscriptHashInput_[epoch]" and "InterimTranscriptHashInput_[epoch]" are based on the Commit that initiated the epoch with epoch number "epoch.  (Note that the "epoch"field in this Commit will be set to "epoch - 1`, since it is </ins> sent within the previous epoch.) <ins> The transcript hash "ConfirmedTranscriptHashInput_[epoch]" is used as the "confirmed_transcript_hash" input to the "confirmation_tag" field for this Commit.  Each Commit thus confirms the whole transcript of Commits up to that point, except for the latest Commit's confirmation tag. </ins> 8.3. In addition to initializing a new epoch via KDF invocations as

Discussion:
The current text on initializing the transcript hash is ambiguous. In particular, it never tells you how to compute the first . This PR provides clearer initialization instructions, and a figure that summarizes the transcript hash evolution [2]. [1] To be clear, I think the intent is clear and all current implementations are consistent. The text is just bad. [2] The diagram is a little over-the-top elaborate. I would be OK removing it :)
I generally like the diagram, but the intersection between , and is not clear to me. What is going where? Also shouldn't and also get numbers? And what's the different between the and suffix?
OK, I rotated the diagram 90 degrees and rejiggered things to hopefully be clearer. It now should just barely fit in the .TXT format. What do folks think?
Beautiful!
Change:
services at their disposal to establish the necessary values and credentials required for encryption and authentication. <del> The Messaging Service (MS) presents as two abstract services that allow clients to prepare for sending and receiving messages securely: </del> <ins> The Messaging Service (MS) presents two abstract services that allow clients to prepare for sending and receiving messages securely: </ins> An Authentication Service (AS) which is responsible for maintaining user long term identities, issuing credentials which allow them to authenticate each other, and potentially allowing <del> users to discover each others long-term identity keys. </del> <ins> users to discover each other's long-term identity keys. </ins> A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members.  In the case of

Discussion:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thanks NAME !
Change:
along with an "endpoint_id" that, combined with the client's identity, serve to uniquely identify a client in a group. <del> When used as InitKeys, KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See initkey-reuse).  Clients MAY generate and publish multiple InitKeys to support multiple ciphersuites. </del> <ins> KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See keypackage-reuse). Clients MAY generate and publish multiple KeyPackages to support multiple ciphersuites. </ins> The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite, and it MUST be unique

Discussion:
Complete the renaming of InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Change:
This field indicates which version of QUIC is in use and determines how the rest of the protocol fields are interpreted. <del> The byte following the version contains the lengths of the two connection ID fields that follow it.  These lengths are encoded as two 4-bit unsigned integers.  The Destination Connection ID Length (DCIL) field occupies the 4 high bits of the byte and the Source Connection ID Length (SCIL) field occupies the 4 low bits of the byte.  An encoded length of 0 indicates that the connection ID is also 0 bytes in length.  Non-zero encoded lengths are increased by 3 to get the full length of the connection ID, producing a length between 4 and 18 bytes inclusive.  For example, a byte with the value 0x50 describes an 8-byte Destination Connection ID and a zero-length Source Connection ID. </del> <ins> The byte following the version contains the length in bytes of the Destination Connection ID field that follows it.  This length is encoded as an 8-bit unsigned integer.  In QUIC version 1, this value MUST NOT exceed 20.  Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet.  Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. </ins> The Destination Connection ID field follows the DCID Len and is between 0 and 20 bytes in length. negotiating-connection-ids

Discussion:
I noticed this earlier today when trying to resolve conflicts relating to the connection ID change.
Suggestions accepted.
A couple of changes
Change:
domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 SECG-SEC2 or in RFC8032. <del> EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the eddsa_ed448 curve.  Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and eddsa_ed448 MUST NOT be used for ECDSA. </del> <ins> EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature algorithm, and Ed448 keys MUST use the ed448 signature algorithm. This document does not define use of Ed25519ph and Ed448ph keys with TLS.  Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used with ECDSA. </ins> 5.10.

Discussion:
ecdhx25519 and ecdhx448 no longer have an ecdh_ prefix (.Remove some remnants of EdDSA curves as NamedCurves.TLS 1.3 only uses the PureEdDSA algorithms. If we were to use Ed25519ph, we would want separate SignatureAlgorithm values so the receivers can indicate support.
(NAME suggested I file this here.) In TLS 1.3, we dropped the "ecdh" prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or another. I think plain x25519 and x448 is tidier. X25519 already denotes the ECDH function, as opposed to curve25519 which is the curve.
Looks fine to me
Change:
5.3. <del> ABR playback is commonly implemented by streaming clients using HLS RFC8216 or DASH MPEG-DASH to perform a reliable segmented delivery of media over HTTP.  Different implementations use different strategies ABRSurvey, often relying on proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. </del> <ins> Adaptive Segmented Delivery attempts to optimize its own use of the path between a media server and a media client.  ABR playback is commonly implemented by streaming clients using HLS RFC8216 or DASH MPEG-DASH to perform a reliable segmented delivery of media over HTTP.  Different implementations use different strategies ABRSurvey, often relying on proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. </ins> Many systems will do an initial probe or a very simple throughput speed test at the start of video playback.  This is done to get a

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.