jiebi/CodeConvo huggingface dataset:
Code change:
to implement version negotiation to protect against downgrade attacks. <del> I-D.duke-quic-version-aliasing is a more robust, but much more complicated, proposal to address these ossification problems.  By design, it requires incompatible version negotiation.  QUICv2 enables exercise of compatible version negotiation mechanism. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: , , , , , .
Just a style thing (and something we should try an capture in a QUIC style guide).
There a bit of inconsistency through the document. Personally I prefer the QUIC version N style.
is there a missing word here?
Nope, extra word, thanks
I find this awkward to read in isolation, it requires converting the RFC 9000 types definition format into a different encoding to realize there is a change. A clearer alternative could be "All version 2 Long Packet Types are different: Initial: 0b01 0-RTT: 0b10 Handshake 0b11 Retry: 0b00
Starting with This might be a matter of style but to me the term "changes" imply that you're modifying the original, not creating something new. How about we term these as differences instead? The the opening paragraph of Section 3 could be something like "QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in ], ], and ]. However, the following differences apply in version 2."
This might have been important earlier in the document lifetime but it seems to stick out now.
This could be misread to imply the salt is universally known and universally applicable, which I don't think is your intention. In fact, I find the construction of this entire paragraph a bit awkward. Can we rephrase this for better clarity? Something like "In QUIC version 1, Initial packets are encrypted with the version-specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Clent Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the 1 key derivation and packet formats."
Couple of nits but otherwise LGTM
Code change:
Initialize VDAF preparation and initial outputs as described in input-share-prep. <del> [[OPEN ISSUE: consider moving the helper nonce check into #early- </del> <ins> [[OPEN ISSUE: consider moving the helper nonce check into early- </ins> input-share-validation]] Once the helper has processed each valid report share in

Related discussion:
text: Justify text after bullets consistenly Make sure all lines break at 80 characters
LGTM, modulo conflicts. It'd be nice if we had a linter that blocked PRs until their formatting was right, since changes like this taint git history.
Code change:
MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. <ins> The algorithms used in SUIT_Authentication are defined by the profiles declared in I-D.moran-suit-mti. </ins> 8.4. The manifest contains:

Related discussion:
text: adds a missing digest parameter corrects CDDL for suit-text removes dangling
I have discovered this because the EAT build process pulls the SUIT CDDL in for validation using the cddl tool.
NAME posted to the list the following: I think I found a little typo in the draft-ietf-suit-manifest-14 ... At the "Appendix A. A. Full CDDL" of the "SUITSeverableMembersChoice", the last two members are pointing to "SUITCommand_Sequence" are probably typos as following,
In draft-ietf-suit-manifest-04 In the example manifest image-digest parameter is set for component 0 in common sequence. The load sequence sets component-index to 1 and after directive-copy it specifies image-match condition. However, the image-digest parameter has not been set for component-index 1 causing the condition to fail as . Is it expected that parameters are implicitly copied from source component when copy-directive is executed? Should the image-digest be also specified for component-index 1 or perhaps for all components? Another observation in the example is that vendor-id and class-id parameters and corrsponding condition checks are specified for component 0, which seems to be the "external storage". Wouldn't it be better to specify the VID and CID globally for the entire device or for the component 1, which seems to be the one running the image? / common / 3:h'a2024782814100814101045856880c0014a40150fa6b4a5 3d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45038202582 000112233445566778899aabbccddeeff0123456789abcdeffedcba98765432100e198 7d001f602f6' / { / components / 2:h'82814100814101' / [ [h'00'] , [h'01'] ] /,
Code change:
MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. <ins> The algorithms used in SUIT_Authentication are defined by the profiles declared in I-D.moran-suit-mti. </ins> 8.4. The manifest contains:

Related discussion:
text: / common-sequence / 4:h'880c0014a40150fa6b4a53d5ad5fdfbe9d e663e4d41ffe02501492af1425695e48bf429b2d51f2ab450382025820001122334455 66778899aabbccddeeff0123456789abcdeffedcba98765432100e1987d001f602f6' / [ / directive-set-component-index / 12,0 , / directive-override-parameters / 20,{ / vendor-id / 1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf- be9d-e663e4d41ffe /, / class-id / 2:h'1492af1425695e48bf429b2d51f2ab45' / 1492af14-2569-5e48-bf42-9b2d51f2ab45 /, / image-digest / 3:[ / algorithm-id / 2 / sha256 /, / digest-bytes / h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210' ], / image-size / 14:34768, } , / condition-vendor-identifier / 1,F6 / nil / , / condition-class-identifier / 2,F6 / nil / ] /, } /, (.) / load / 11:h'880c0113a1160016f603f6' / [ / directive-set-component-index / 12,1 , / directive-set-parameters / 19,{ / source-component / 22:0 / [h'00'] /, } , / directive-copy / 22,F6 / nil / , / condition-image-match / 3,F6 / nil / ] /,
Code change:
Specification Required policy to avoid collisions with HTTP/2 error codes. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.4.

Related discussion:
text: IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >
Code change:
9. Please update the "Media Types" registry at <del> https://www.iana.org/assignments/media-types [1] for the media types </del> <ins> https://iana.org/assignments/media-types [1] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [2] for the types "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). </ins> 9.1. The "application/ohttp-keys" media type identifies a used by

Related discussion:
text: We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!
Code change:
D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </del> <ins> races between two different Protocol Stacks, both need to use the same security protocols and options.  However, a Transport Services system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to

Related discussion:
text: This is intended to provide predictable outcomes to the application using the transport service. I would then suggest to use lower case within other parts of the document - except were pointed to from here, (we could refer to the requirements subsection, if we thought necessary).
for discussion at the interim, but IMO we could start the interim with a PR based on these suggestions and work from there.
I suspect that we need more protocol-specific properties to be able to talk to various kinds of native protocol peers (other than TCP and UDP: these should already work fine with what we have, I believe). A concrete example: we're hiding stream numbers. In NEAT, we needed to make them configurable though, because we wanted a NEAT client to be able to talk to a native SCTP server, where an application may expect certain type of data to arrive via a certain stream number. I suspect that we may need something similar for a QUIC peer. Should we address this? (I'd say yes) How .. is it a protocol-specific (per-Message) property? (I'd say yes... and perhaps a per-Connection property too, with text explaining that the per-Message one automatically becomes the Connection default unless otherwise specified) What other such things are we missing... what other expectations may e.g. a native QUIC or SCTP application have that we just cannot fulfil with our current system?
Code change:
Clients MUST discard Retry packets that contain an Original Destination Connection ID field that does not match the Destination Connection ID from its Initial packet.  This prevents an off-path <del> attacker from injecting a Retry packet. </del> <ins> attacker from injecting a Retry packet.  A client MUST discard a Retry packet with a zero-length Retry Token field. </ins> The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection

Related discussion:
text: The Retry packet can be discarded.
The Retry packet currently allows sending an empty token. The Retry token is defined as an opaque blob where "indicates that x is variable-length", which also includes zero-length values. On the wire, an Initial packet with a zero-length token is identical to an Initial without a token. However, there's a difference on the client side, since a client will perform at most a single Retry.
Tagging this editorial. This was clearly intended to be considered non-zero length.
Code change:
candidates of the Media Server.  The Media Server MAY use ICE lite, while the WHIP client MUST implement full ICE. <del> The WHIP client MAY perform trickle ICE or ICE restarts RFC8863 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </del> <ins> The WHIP client MAY perform trickle ICE or ICE restarts as per RFC8838 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/ trickle-ice-sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </ins> Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If the WHIP resource supports either Trickle ICE or ICE restarts, but

Related discussion:
text: NAME ping?
Section 4.1 “The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request…” Why is there a reference to RFC8863, which specifies ICE PAC, here? In general a reference to ICE PAC is useful, because this draft allows an offer without any candidates. So maybe that reference should go at the end of: “The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY only contain local candidates (or even an empty list of candidates).”
I think it was a typo.
I created a PR to fix the tricke ice reference and add the pac one as suggested.
Code change:
Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys. <del> 13.2.8. </del> <ins> 13.2.7. </ins> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Packets containing only

Related discussion:
text: It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.
Code change:
12.3.23. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> Integer Connection Property - see </ins> 12.3.24. <del> Protocol Property (Generic) / Control Property [TODO: Discuss] Enum Preconnection, Connection This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. </del> <ins> Enum Connection Property - see </ins> 12.3.25. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.26. <del> Protocol Property (Generic) Integer Connection (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender.  This property is read- only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.27. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent. This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.28. <del> Protocol Property (Generic) Integer Connection (read only) This numeric property represents the maximum Message size that can be received.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.29.

Related discussion:
text: This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.
Code change:
applicability, and issues that application developers must consider when using QUIC as a transport for their application. <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 2. QUIC uses UDP as a substrate.  This enables both userspace

Related discussion:
text: note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.
Code change:
performance of the QUIC handshake and use shorter timers for acknowledgement. <del> Packets that contain only ACK frames do not count toward congestion control limits and are not considered in-flight. </del> <ins> Packets containing frames besides ACK or CONNECTION_CLOSE frames count toward congestion control limits and are considered in- flight. </ins> PADDING frames cause packets to contribute toward bytes in flight without directly causing an acknowledgment to be sent.

Related discussion:
text: At the moment, we state that a QUIC packet that contains frames other than ACK and PADDING (), but I wonder if that is true for CONNECTIONCLOSE frame. A CONNECTIONCLOSE frame never elicits an acknowledgment. IIUC, it is not meant to be governed by the congestion controller. Considering the aspects, I think we should add CONNECTION_CLOSE to the list of non-ACK-eliciting frames.
That also ensures the congestion controller never inadvertently blocks sending a CONNECTIONCLOSE, which is consistent with the intent. If we make this change, I believe APPLICATIONCLOSE needs to be on the list as well. Now that we discuss ack-eliciting in transport, I think we'd need to change both transport and recovery and mark this design. So I think this would be a slight improvement, but I an also imagine people claiming that CONNECITON_CLOSE is already special, so there's no need for a change.
APPLICATION_CLOSE is no more. This seems like a fine change.
This seems sensible.
Discussed in Cupertino. Obvious correction.
Seems right to me. Editorial tweaks suggested.