jiebi/CodeConvo huggingface dataset:
Code change:
This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier verification of the data on client by means of existing DNS library <del> functions.  However this document describes the data structure in sufficient detail that implementers if they desire can write their own code to do this. </del> <ins> functions. </ins> Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in RFC1035, Section 3.2.1. <ins> The resource records that make up a RRset all have the same owner, type and class, but different RDATA as specified RFC2181, Section 5. </ins> Each RRset in the sequence is followed by its associated RRsig record <del> set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del> <ins> set.  This RRset has the same owner and class as the preceding RRset, but has type RRSIG.  The Type Covered field in the RDATA of the RRsigs identifies the type of the preceding RRset as described in RFC4034, Section 3.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field

Related discussion:
text: Remove statement that the document describes the data structure in sufficient detail for implementers and describe more clearly how individual RRsets and the successive RRSig record set are identified by referencing the relevant sections in RFC's; and remove the in response to Eric Rescorla's DISCUSS point: IMPORTANT: I'm not sure that this is actually sufficient to allow an independent implementation without referring to the other documents. I mean, I think I pretty clearly can't validate this chain from the above. Similarly, although I think this is enough to break apart the RRSETs into RRs, it doesn't tell me how to separate the RRSETs from each other. I think you need to either make this a lot more complete or alternately stop saying it's sufficient.
Code change:
Because the integrity check indirectly depends on a sequence number, if record N is not received, then the integrity check on record N+1 will be based on the wrong sequence number and thus <del> will fail.  DTLS solves this problem by adding explicit sequence numbers. </del> <ins> will fail.  DTLS solves this problem by adding sequence numbers. </ins> The TLS handshake is a lock-step cryptographic handshake. Messages must be transmitted and received in a defined order; any

Related discussion:
text: The draft states in three places that DTLS use explicit sequence numbers, while this was true for DTLS 1.2, the sequence number in the DTLSCipherstructure is a mixture of implicit and explict. Maybe "Partly Explicit"?
Please provide me with a PR to add your name to acknowledgements.
Hi, I don’t know what PR is an abbreviation for but I guess it is not clear from my username who I am. I should probably update it, I did not intend to be anonymous :) John Mattsson, Ericsson, EMAIL
Code change:
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions than used in QUIC, which is 1.3, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the

Related discussion:
text: From PR : I'd also like to see something like : /In this section, we discuss those aspects of the QUIC transport protocol that/This section discusses those aspects of the QUIC transport protocol that/ /Here, we are concerned primarily with the unencrypted part of QUIC's wire image {{WIRE-IMAGE}}, which we define as the information available in the packet/This section is concerned primarily with the unencrypted part of QUIC's wire image {{WIRE-IMAGE}}, defined as the information available in the packet/ and /least four datagrams we'll call "Client Initial",/least four datagrams, labelled "Client Initial",/ and / 0-RTT data may also be seen in the Client Initial datagram, as shown in /When the client uses 0-RTT connection resumption, the Client Initial datagram can also carry 0-RTT data, as shown in/ and /typically around 10 packets/typically to around 10 packets/ and /of a connection after one of one endpoint/of a connection after an endpoint/ I'd prefer more like: /Though the guidance there holds, a particularly unwise behavior admits a handful of UDP packets and then makes a decision as to whether or not to filter later packets in the same connection. QUIC applications are encouraged to fail over to TCP if early packets do/ ... and I'll close PR .
“QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established or because the information is intended to be used by the network.” Could this benefit form a cross-reference to manageability, where this topic is also discussed from a network perspective?
Three places where the text might avoid confusion when read in future years: 1) “Further downgrades to older TLS versions than used in QUIC, which is 1.3, “ … will it always be 1.3, or should this be “in QUIC [REF] is TLS 1.3” 2) “Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window.
Code change:
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions than used in QUIC, which is 1.3, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the

Related discussion:
text: “ I'm not so happy with currently here: Is this the best way to say this, might it be better to say this rather than even hinting that future QUIC might only be reliable: “When a QUIC endpoint provides provides fully reliable stream transmission, prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window. “ 3) I’d prefer to see a ref here, since this something that the WG might later decide to work upon: “Currently QUIC only supports failover cases [Quic-Transport].”
That mega paragraph has a bunch of good concepts, but it's all run together into a single blob, which makes it a bit hard to follow.
Code change:
of the element and to ensure correct serialization for integrity and authenticity checks. <ins> All CBOR maps in the Manifest and manifest envelope MUST be encoded with the canonical CBOR ordering as defined in RFC8949. </ins> 8.2. The Envelope contains each of the other primary constituent parts of

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:
of the element and to ensure correct serialization for integrity and authenticity checks. <ins> All CBOR maps in the Manifest and manifest envelope MUST be encoded with the canonical CBOR ordering as defined in RFC8949. </ins> 8.2. The Envelope contains each of the other primary constituent parts of

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:
in that order.  The load balancer uses the server ID octets for routing. <del> 4.4.3. </del> <ins> 4.3.3. </ins> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its

Related discussion:
text: by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.
Code change:
defining a common terminology as well as how each metric should be computed for consistent reporting. <del> 5.6.2. </del> <ins> CTA-5004: Common Media Client Data (CMCD) </ins> Many assume that the CDNs have a holistic view into the health and performance of the streaming clients.  However, this is not the case.

Related discussion:
text: LGTM
From NAME The very first sentence is mostly unparseable due to its length (7 lines). Please consider splitting it.
I added this, from NAME review: This section and the next one should be a list with 2 bullets rather than 2 sections to make the text more readable.
Code change:
encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash algorithm and salt size.  The salt size MUST match the output size of <del> the hash function associated with the public key and token type. </del> <ins> the hash function associated with the public key and token type.  The parameters field for the digest used in the mask generation function and the digest being signed MUST be omitted. An example sequence of the SPKI object (in ASN.1 format) for a 2048-bit key is below: "$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER 0:d=0 hl=4 l= 338 cons: SEQUENCE 4:d=1 hl=2 l= 61 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss 17:d=2 hl=2 l= 48 cons: SEQUENCE 19:d=3 hl=2 l= 13 cons: cont [ 0 ] 21:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 34:d=3 hl=2 l= 26 cons: cont [ 1 ] 36:d=4 hl=2 l= 24 cons: SEQUENCE 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 49:d=5 hl=2 l= 11 cons: SEQUENCE 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 62:d=3 hl=2 l= 3 cons: cont [ 2 ] 64:d=4 hl=2 l= 1 prim: INTEGER :30 67:d=1 hl=4 l= 271 prim: BIT STRING " </ins> Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide

Related discussion:
text: cc NAME NAME for an extra set of eyes to check me here -- ASN.1 is not my forte. I went based on the implementation , which I think matches what Frank did , but I would definitely appreciate confirmation!
Friendly bump NAME and NAME =)
Do you have a test vector / example to make sure it matches what I believe?
NAME yeah, each includes the encoded public key ().
Example, taken from the current test vector:
Looks good to me. But yeah, ASN.1 is not the most concise nor readable format.
ASN1 matches my expectations as well.
... we should make it clear, and provide test vectors to make sure it matches. The test vector could include public keys in PEM format and then print out the expected key ID.
Code change:
structure, which specify the protocol used to verify and aggregate the clients' measurements: <ins> "nonce": A unique sequence of bytes used to ensure that two otherwise identical "PDAParam" instances will have distinct "PDATaskID"s.  It is RECOMMENDED that this be set to a random 16-byte string derived from a cryptographically secure pseurandom number generator. </ins> "leader_url": The leader's endpoint URL. "helper_url": The helper's endpoint URL.

Related discussion:
text: I added a clarification that the nonce is random. IMO the question of who randomly generates the nonce goes with the question of how participants agree upon PDAParams, which is to say it's outside the protocol.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
Approved, with the following suggestion: Let's leave a [TODO: ...] comment under the definition of for clarifying how it should be chosen.
Code change:
given that establishing a new connection using 0-RTT support is cheap and fast. <del> QoS mechanisms in the network MAY also use the connection ID for </del> <ins> QoS mechanisms in the network could also use the connection ID for </ins> service differentiation, as a change of connection ID is bound to a change of address which anyway is likely to lead to a re-route on a different path with different network characteristics.

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:
Abstract <del> This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. </del> <ins> This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. </ins> 1. <del> TLS 1.3 RFC8446 supports pre-shared key (PSK) authentication, wherein </del> <ins> TLS 1.3 RFC8446 supports Pre-Shared Key (PSK) authentication, wherein </ins> PSKs can be established via session tickets from prior connections or externally via some out-of-band mechanism.  The protocol mandates that each PSK only be used with a single hash function.  This was

Related discussion:
text: This is mainly editorial, so there should be nothing surprising here. Please let me if that's not the case! It also includes clarifying text per NAME recommendation raised during WGLC. cc NAME NAME
From Rob Sayre: We should note the latter is a requirement from Section 4.2.11 of RFC8446. Let's also fix the typo "import external keys for TLS..."
Code change:
routing bytes.  The Server ID is unique to each server, and the routing bytes are global. <del> For Obfuscated CID Routing, this consists of the Routing Bits, Divisor, and Modulus.  The Modulus is unique to each server, but the others MUST be global. </del> For Stream Cipher CID Routing, this consists of the Server ID, Server ID Length, Key, and Nonce Length.  The Server ID is unique to each server, but the others MUST be global.  The authentication token MUST

Related discussion:
text: by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.
Code change:
possibility of cross-protocol attacks, but more analysis is still needed here. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> This document registers a new value in the "QUIC Transport Parameters" registry maintained at

Related discussion:
text: Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM
Code change:
6.1. <ins> Within sec-trans, the term "Media Transport Protocol" is used to describe to describe the protocol of interest.  This is easier to understand if the reader assumes a protocol stack that looks something like this: where "Media Format" would be something like an RTP payload format RFC2736 or ISOBMFF ISOBMFF, "Media Transport Protocol" would be something like RTP or HTTP, and "Transport Protocol" would be something like TCP or UDP. Not all possible streaming media applications follow this model, but for the ones that do, it seems useful to have names for the protocol layers between Media Format and Transport Layer It is worth noting explicitly that the Media Transport Protocol and Transport Protocol layers might each include more than one protocol. For example, a Media Transport Protocol might run over HTTP, or over WebTransport, which in turn runs over HTTP. It is worth noting explicitly that more complex network protocol stacks are certainly possible - for instance, packets with this protocol stack may be carried in a tunnel, or in a VPN.  If these environments are present, streaming media operators may need to analyze their effects on applications as well. 6.2. </ins> For most of the history of the Internet, we have trusted UDP-based applications to limit their impact on other users.  One of the strategies used was to use UDP for simple query-response application

Related discussion:
text: really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section