jiebi/CodeConvo huggingface dataset:
Change:
The token protection uses an 128 bit representation of the source IP address from the triggering Initial packet.  The client IP address is <del> 16 octets.  If an IPv4 address, the last 12 octets are zeroes.  If there is a Network Address Translator (NAT) in the server </del> <ins> 16 octets.  If an IPv4 address, the last 12 octets are zeroes. If there is a Network Address Translator (NAT) in the server </ins> infrastructure that changes the client IP, the Retry Service MUST either be positioned behind the NAT, or the NAT must have the token <del> key to rewrite the Retry token accordingly. </del> <ins> key to rewrite the Retry token accordingly.  Note also that a host that obtains a token through a NAT and then attempts to connect over a path that does not have an identically configured NAT will fail address validation. </ins> The 96 bit unique token number is set to a random value using a cryptography- grade random number generator.

Discussion:
and
Thanks Christian, Your comments ended up as an editorial rewrite of the section, with port verification added.
The diagrams indicate they are in the range 0..160. This is incorrect.
SS Tokens can have this, because they could be NEW_TOKEN tokens. But the shared state format is limited to 64.
Fixed by
A few more issues with Retry tokens: For Retry, we're supposed to check the client port. Because this isn't true for NEW_TOKEN, we probably can't put it in the shared-state pseudoheader. Relatedly, we currently just say that the shared-state Retry Service has to be behind any NAT. This isn't enough. For non-shared-state, we're probably fine. For a Retry, the NAT will keep the 4-tuple binding so that on either side there is something to validate. For shared-state: if the service is in front of the NAT, the server can't validate the address. if the service is behind the NAT, it'll "work" but to add any value at all there really has to be a port in there somewhere. We can probably assume that the alternate path that creates the need for shared state won't cause a service-generated token to suddenly appear on the unprotected path.
Fixed by
We should tighten up the rules for Resumption Token processing by the Retry Service. When active, it should reject the packet, but it should send Retry. I believe we can distinguish resumption from Retry because the CID length fields are zero; as any Retry token must have a ODCIDL of at least 8, this would appear to be robust. On a related note, the requirement on servers to encode a way to distinguish the two token types is silly, because of this propery.
Fixed by
Currently the Initial Packet number MAY be encoded in the Retry Token. We must either: Include language that a server MUST NOT reject a token because this information is not present; OR Just make it part of the format. (IMO this would be bad, because then the Retry service would have to decrypt the packet number)
Most changes appear editorial, except for the addition of the port number field. If you add that port, you need to also specify how it should be processed!
Change:
mechanism defined in RFC5077 and replaces it with the mechanism defined in resumption-and-psk. negotiated-groups updates RFC4492 by modifying the protocol attributes used to negotiate Elliptic Curves. <del> Because TLS 1.3 changes the way keys are derived it updates RFC5705 as described in exporters it also changes how OCSP messages are </del> <ins> Because TLS 1.3 changes the way keys are derived, it updates RFC5705 as described in exporters.  It also changes how OCSP messages are </ins> carried and therefore updates RFC6066 and obsoletes RFC6961 as described in section ocsp-and-sct.

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
samples, estimated using a mean variation. The calculation of smoothed_rtt uses path latency after adjusting RTT <del> samples for ACK delays.  For packets sent in the ApplicationData packet number space, a peer limits any delay in sending an acknowledgement for an ack-eliciting packet to no greater than the value it advertised in the max_ack_delay transport parameter. Consequently, when a peer reports an Ack Delay that is greater than its max_ack_delay, the delay is attributed to reasons out of the peer's control, such as scheduler latency at the peer or loss of previous ACK frames.  Any delays beyond the peer's max_ack_delay are therefore considered effectively part of path delay and incorporated into the smoothed_rtt estimate. </del> <ins> samples for acknowledgement delays.  These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of QUIC-TRANSPORT.  For packets sent in the ApplicationData packet number space, a peer limits any delay in sending an acknowledgement for an ack-eliciting packet to no greater than the value it advertised in the max_ack_delay transport parameter.  Consequently, when a peer reports an Ack Delay that is greater than its max_ack_delay, the delay is attributed to reasons out of the peer's control, such as scheduler latency at the peer or loss of previous ACK frames.  Any delays beyond the peer's max_ack_delay are therefore considered effectively part of path delay and incorporated into the smoothed_rtt estimate. </ins> When adjusting an RTT sample using peer-reported acknowledgement delays, an endpoint:

Discussion:
Notes that ack delays are right shifted by ackdelayexponent when transmitted in ACK frames.
The recovery draft currently assumes you've already applied the ack delay exponent. It should spell that out explicitly so readers of the draft don't miss it. Ideally it'd be obvious if you just read transport, but that's a long draft, so there's no harm in stating it again. From an on-list comment by Timo Völker
Lgtm
Change:
cryptographic keys it holds.  An application or user may use one client per device (keeping keys local to each device) or sync keys among a user's devices so that each user appears as a single <ins> client.  In the scenario where multiple devices share the cryptographic material the client is referred to as a "virtual" </ins> client. A collection of clients with shared cryptographic state.

Discussion:
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [4] <del> Editor's note: The link above might or might not be changed during </del> <ins> Editor's note: The URL above might or might not be changed during </ins> IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf- mops-streaming-opcons/issues/114 [5] for updates.

Discussion:
Also add Linda to ACKs and add stream: IETF (this is now an XML2RFCv3 thing)
From NAME
responding to the application-level feedback that indicates a bottleneck link somewhere along the path. We agree that "link" is ambiguous. In this section, we're talking about a bottleneck, so we don't need to to say "link", BUT we will clean up other occurrences of "link" in the document - one is actually a URL. implementing some forms of congestion control that probe for bandwidth. The conclusion says that the QoE is poorer when the two methods don't coordinate. Question 2: Both methods are implemented on the Media server, they should coordinate by nature, aren't they? You might think so, but they don't, for various reasons (transport protocols being implemented by OS vendors, and media servers and players are implemented by completely different people. We say that in 3.2, but we describe media servers as "implementing transport protocols". That should have been "rely on". This might change, with transport protocols being implemented in user space and packaged as libraries that are shipped media servers, but that's the case today.
Change:
Examples and a sample decoding algorithm are shown in sample-varint. <del> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding. </del> <ins> Versions (versions), packet numbers sent in the header (packet- encoding), and the length of connection IDs in long header packets (long-header) are described using integers, but do not use this encoding. </ins> 17.

Discussion:
This should address all of them at once; one per commit for those that I think need action. This is probably OK: This is not expressly forbidden. We do say : Which doesn't really contradict the other. FWIW, I'm not a fan of allowing frames to be copied, implementations really should do that, but it's a consequence of having frame idempotency. This is one I'm not sure about: What is the prevailing advice regarding MTU and tunnels? Clearly when you tunnel you get a smaller MTU, but I haven't seen what happens when IPv6 is tunneled over a network that has a minimum MTU. Most paths don't have that small an MTU, so it might be that things just fail.
I realized that there are some answers here in the description, but probably best to move them to the relevant issues anyways.
NAME said: >
NAME said: with TLS.
NAME said:
NAME said: this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be copied.
My recommendation is to answer the question, but not change anything. See for an answer.
Very well, please close this issue. Sorry for the confusion.
NAME said: RESET_RECVD.
NAME said:
NAME said:
This looks good to me, with NAME 's nit.
Change:
operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely <del> on an external CA for such short-lived credentials.  In contrast to OCSP stapling, in which an operator could choose to talk to the CA frequently to obtain stapled responses, failure to fetch an OCSP stapled response results only in degraded performance, however </del> <ins> on an external CA for such short-lived credentials.  In OCSP stapling, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance.  On the other hand, </ins> failure to fetch a potentially large number of short lived certificates would result in the service not being available which creates greater operational risk.

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes
Change:
13.2.5. <del> An endpoint measures the delays intentionally introduced between when the packet with the largest packet number is received and an acknowledgment is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK frame (see frame-ack).  This allows the </del> <ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the time an acknowledgment is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK frame (see frame-ack).  This allows the </ins> receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed.  A packet might be held in the OS kernel

Discussion:
Fixes issue .
The wording "between when ... and when..." or "between when ... and ..." is odd. There are two instances of this in .
Fixed by .
Not critical, perhaps, but I agree that this is less awkward.
Change:
Secure Automation and Continuous Monitoring (SACM) Terminology <del> draft-ietf-sacm-terminology-07 </del> <ins> draft-ietf-sacm-terminology-latest </ins> Abstract

Discussion:
A couple of bookkeeping changes: Fix a format error in the readme Make the date be the date it was generated rather than a fixed date Change the document title to be more generic as it does not match the published numbered version on the IETF website.
Change:
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services Architecture implementation from TAPS also describes how <del> connections may race across interfaces and address families.  In </del> <ins> connections can race across interfaces and address families.  In </ins> cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement

Discussion:
If they don't enforce a limit, clients can cause them to do a lot of work.
Fixed by .
Approved pending
Change:
16.1.  URIs <del> [1] mailto:TBD@ietf.org </del> <ins> [1] mailto:mls-reg-review@ietf.org </ins> [2] mailto:iesg@ietf.org

Discussion:
This started off just fixing , then grew a bit. Defines an IANA registry for ExtensionType values Defines an IANA registry for CredentialType values Updates the Ciphersuites registry to share formatting with the other two, and to be more explicit about its ties to HPKE algorithms Removes the unnecessary field from ... and as a result removes the definition of (which is used nowhere else)
Now that we have a more robust extension mechanism, we need to have an IANA registry to manage extensions, including: Registry structure Registry policy and (probably) designated experts Reserved vendor space
Change:
[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 9.7.7. </del> <ins> 9.7.8. </ins> This registry lists identifiers for the ways that CAs can validate control of identifiers.  Each method's entry must specify whether it

Discussion:
Also, add some more "replace RFC XXXX with this document" notes, for clarity. Thanks to NAME for noticing that this was missing.
Merging based on r+ from NAME
The new registry looks good :+1: - no changes to request there. The existing directory registry () should probably have a "meta" entry:
Change:
A stateless reset token is used in verifying a stateless reset, see stateless-reset.  This parameter is a sequence of 16 bytes. <del> This transport parameter is only sent by a server. </del> <ins> This transport parameter MUST NOT be sent by a client, but MAY be sent by a server.  A server that does not send this transport parameter cannot use stateless reset (stateless-reset) for the connection ID negotiated during the handshake. </ins> The maximum packet size parameter is an integer value that limits the size of packets that the endpoint is willing to receive.  This

Discussion:
I know that we made this a design issue, and these do change 2119 language, but those normative requirements were implied anyway. That is, the text used cannot vs. MUST NOT.
I was also wondering about the rate limit in SR - I too thought it was there. But now, after thinking a bit, the rate limit was probably removed because it is a DoS vector. It can force state to maintained where it is not wanted.
This is a weird statement to make. It is absolutely the place of the spec to do that! If what you mean is that this is entirely optional, then I'm happy to make it a MAY. My concern is not so much what level of force the spec uses, just that the level of force is clear.
Before I merge this, NAME NAME might want to check that I'm not making technical changes. (There is new 2119 language, but my view is that this is converting from implied to express, but I want to give a chance to run a consensus call if you think that's appropriate.)
Those sorts of conversions have surprised people before, and is design anyway, so let's do run that consensus call. If it's ready to go, add and we'll run it up the virtual flagpole.
NAME take a look at what I just proposed.
While there are some prohibitions, and an explicit MAY for responding to Long Headers, there is no normative statement for the usual use case for Stateless Reset. I believe it's a SHOULD, but maybe someone thinks it's a MUST. Relatedly, in 10.4.1, MUST we attempt to detect Stateless Reset, or MAY endpoints just drop after decrypt failure? At the end of 10.4.2, MUST we not reuse connection IDs if there's a static key? (I think the answer is yes)
Thanks, NAME this LGTM.Thank you, this addresses the original issue. One nit below.
Change:
In pseudocode, this procedure is as follows: <del> Servers MUST verify that the request padding consists of all zeroes before processing the corresponding Message. </del> 5.2. Given an HPKE context "context", a request message "request", and a

Discussion:
One question we might want to ask (even though I think we have the right answer already) is: should be included in AAD? I also removed the padding text, since we moved that to the bhttp spec.
It's a reasonable question, but I think we can safely assume that a single key can't be used with multiple KEMs.
In principle it might be possible, but I think we should prohibit it.
Change:
The initial contents of this registry are shown in iana-tp-table. <ins> Additionally, each value of the format "31 * N + 27" for integer values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by IANA. </ins> 22.2. IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a

Discussion:
NAME I added IANA considerations, analogous to those in the HTTP doc for the stream type.
We have space for private transport parameters and a process for assigning new standard transport parameters. However, since we do not apply GREASE to transport parameters, we leave ourselves open to that flexibility ossifying. I'm happy to produce a PR to address this in the spec.
During interop in London we found an implementation that failed the handshake upon seeing an unknown transport parameter. I think applying GREASE to transport parameters is a great idea.
Discussed in London, NAME to prepare a PR
NAME any progress here?
I have prepared something. I can open a pr
NAME sorry I totally dropped the ball here! I had text ages ago and was circling back today finally. Thanks NAME for seeing to it.
Thanks Marten!Thanks for writing this up!Need to fix the examples, but otherwise looks good.
Change:
"Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <https://www.iana.org/assignments/http-fields/>. <ins> *Note:* This registry will not exist until SEMANTICS is approved. *RFC Editor*, please remove this note prior to publication. </ins> As in previous versions of HTTP, field names are strings containing a subset of ASCII characters that are compared in a case-insensitive fashion.  Properties of HTTP field names and values are discussed in

Discussion:
These are some minor editorial things that should be considered to be addressed: Section 4.1: "A server MAY send one or more PUSHPROMISE frames (Section 7.2.5) before, after, or interleaved with the frames of a response message. These PUSHPROMISE frames are not part of the response; see Section 4.4 for more details. These frames are not permitted in pushed responses; a pushed response that includes PUSHPROMISE frames MUST be treated as a connection error of type H3FRAMEUNEXPECTED." Especially the third sentence was hard to parse. Took me a while to realize that it tries to express that PUSHPROMISE frames are not allowed in pushed responses. I think it is primarily a language thing. However, isn't this dependent on stream type. So PUSHPROMISE are allowed on the client-initiated bi-directional stream but not on the server-initiated unidirectional stream. Section 4.1.1: "For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at URL" To avoid more confusion like the one I had in IETF last call. Can you add an Editors note (to be removed before RFC publication) that this registry does not yet exist, and is dependent on approval of [SEMANTICS]? Section 7.2.4.1: "SETTINGSMAXFIELDSECTION_SIZE (0x6): The default value is unlimited. See Section 4.1.1 for usage." As the actual discussion of usage of this setting is in Section 4.1.1.3 wouldn't that be better to reference?
I'll take a look at cleaning it up, but I'm hesitant to simply say "can't be used on unidirectional streams" because an extension might create a unidirectional stream that does allow PUSH_PROMISE frames for whatever reason. Maybe specifically stating that they can't be sent on Push Streams would work? Good suggestion. Good suggestion; probably we moved this text to subsections after the reference was written.
My personal view has been that PUSHPROMISE is part of a request message. And so it has to abide by the rules there. Any attempt to change that requires a semantic extension to H3. Which is what URL precisely does in order to allow PUSHPROMISE on a new stream type.
Change:
The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <ins> 10.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.

Discussion:
This would have been easier had I not forgotten how to do this.
Does this ref need to be normative?
oh, it seems this relates to a the registration of buried down in Section 10.2. Is this still valid?
Yes it is, though I realize that we also buried the IANA considerations a little too deep.
Currently, these normative references are to old document versions. We should link to RFC 9113 and 9114, and probably use the Use [HTTP/2] and [HTTP/3] labels for consistency with the HTTP style guide.