jiebi/CodeConvo huggingface dataset:
Change:
(RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can <del> have different TTLs.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </del> <ins> have different TTLs, though it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </ins> A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

Discussion:
…
during the singapore meeting tale noted that the http caching model, where 1 lifetime is assigned to the rrset is not necessarily the way a dns cache would handle things.. each rr can have its own ttl (though one dns implementation does it this way). perhaps worth some explanatory text when talking about rrset granularity and http caches.
Change:
Server with other details of the push subscription. When sending a message, an Application Server generates an ECDH key <del> pair and a random salt.  The ECDH public key is encoded into the "dh" parameter of the Crypto-Key header field; the salt is encoded into message payload.  The ECDH key pair can be discarded after encrypting the message. </del> <ins> pair and a random salt.  The ECDH public key is encoded into the "keyid" parameter of the encrypted content coding header, the salt in the "salt" parameter of that same header (see Section 2.1 of I- D.ietf-httpbis-encryption-encoding).  The ECDH key pair can be discarded after encrypting the message. </ins> The content of the push message is encrypted or decrypted using a content encryption key and nonce that is derived using all of these

Discussion:
/cc NAME Not sure about "parameter of that same header" phrasing. Not a fan of duplicating the text about the content coding header either. Suggestions?
Yep, these are both correct. Thanks.
Change:
discovery solutions designed around this threat model may have limited value. <del> 7. </del> <ins> 5. </ins> This section lists requirements that flow from the above sections. <del> 8. </del> <ins> 6. </ins> See priv-sec. <del> 9. </del> <ins> 7. </ins> This document has no IANA actions.

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
1. Privacy Pass tokens are unlinkable authenticators that can be used to <del> anonymously authorize a client (see I-D.ietf-privacypass- architecture).  A client possessing such a token is able to prove that it was able to get a token issued by a token issuer - based on some check from a token issuer, such as authentication or solving a CAPTCHA - without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow. </del> <ins> anonymously authorize a client (see ARCHITECTURE).  A client possessing such a token is able to prove that it was able to get a token issued by a token issuer - based on some check from a token issuer, such as authentication or solving a CAPTCHA - without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow. </ins> Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens.

Discussion:
We could omit the authenticator value and just focus on how Token is constructed based on TokenChallenge, but it seems reasonable to include the authenticator so folks can also test that they're computing the token key ID correctly. Generated from .
Change:
(if supported) to send back a message body that is too large to fit into a single IP packet RFC7959. <del> If Q-Block1 Option is present in a request or Q-Block2 Option in a response (i.e., in that message to the payload of which it pertains), it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed. </del> Implementation of the Q-Block1 and Q-Block2 Options is intended to be optional.  However, when it is present in a CoAP message, it MUST be processed (or the message rejected).  Therefore, Q-Block1 and Q-Block2 Options are identified as Critical options. <ins> With CoAP over UDP, the way a request message is rejected for Critical options depends on the message type.  A Confirmable message with a unknown Critical option is rejected with a 4.02 (Bad Option) response (Section 5.4.1 of RFC7252).  A Non-confirmable message with a unknown Critical option is either rejected with a Reset message or just silently ignored (Section 5.4.1 and 4.3 of RFC7252).  To reliably get a rejection message, it is therefore REQUIRED that clients use a Confirmable message for determining support for Q-Block1 and Q-Block2 options. </ins> The Q-Block1 and Q-Block2 Options are unsafe to forward.  That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option MUST reject the request or response that uses either option.

Discussion:
find another name than Quick-Block
A poll is ongoing. Updated to Q-Block in -02, but open to change if we get more inputs
Change:
connection basis, through a stochastic process or based on client address. <ins> A configuration agent MUST distribute a list of QUIC versions the Retry Service supports.  It MAY also distribute either an "Allow- List" or a "Deny-List" of other QUIC versions.  It MUST NOT distribute both an Allow-List and a Deny-List. The Allow-List or Deny-List MUST NOT include any versions included for Retry Service Support. The Configuration Agent MUST provide a means for the entity that controls the Retry Service to report its supported version(s) to the configuration Agent.  If the entity has not reported this information, it MUST NOT activate the Retry Service and the configuration agent MUST NOT distribute configuration that activates it. The configuration agent MAY delete versions from the final supported version list if policy does not require the Retry Service to operate on those versions. The configuration Agent MUST provide a means for the entities that control servers behind the Retry Service to report either an Allow- List or a Deny-List. If all entities supply Allow-Lists, the consolidated list MUST be the union of these sets.  If all entities supply Deny-Lists, the consolidated list MUST be the intersection of these sets. If entities provide a mixture of Allow-Lists and Deny-Lists, the consolidated list MUST be a Deny-List that is the intersection of all provided Deny-Lists and the inverses of all Allow-Lists. If no entities that control servers have reported Allow-Lists or Deny-Lists, the default is a Deny-List with the null set (i.e., all unsupported versions will be admitted).  This preserves the future extensibilty of QUIC. </ins> A retry service MUST forward all packets for a QUIC version it does <del> not understand.  Note that if servers support versions the retry service does not, this may increase load on the servers.  However, dropping these packets would introduce chokepoints to block deployment of new QUIC versions.  Note that future versions of QUIC might not have Retry packets, require different information in Retry, or use different packet type indicators. </del> <ins> not support that are not on a Deny-List or absent from an Allow-List. Note that if servers support versions the retry service does not, this may increase load on the servers. Note that future versions of QUIC might not have Retry packets, require different information in Retry, or use different packet type indicators. </ins> 6.2.

Discussion:
Hopefully this will close the gap between what we want Retry Services to do and reality.
It would help the anti-DDoS properties if the Retry Service could receive explicit instructions about which QUIC versions the server might support. This provides a way to deploy new versions without having to upgrade the retry service software or hardware.
Change:
The following table indicates the purpose values for each type of key: <del> 7.2.1. </del> <ins> 7.3.1. </ins> The handshake hash is defined as the hash of all handshake messages sent or received, starting at ClientHello up to the present time,

Discussion:
Is good.
The counter has a size of (2^64-1).The records are max (2^14 + 2048). So, my bold calculation would come to (2^64-1) / (2^14 + 2048) / 2^40 = 910.22 TiB of data. In Big Data, video streaming and other mass data cases 910TB data can be a limitation. I would like to propose the counter to go to 2^128-1, which would result in a connection that can reach (2^128-1) / (2^14 + 2048) / 2^80 = 1.52 * 10^10 YiB. If byte preservation is an issue, I'm willing to accept 2^96-1 as the counter max, resulting in (2^96-1) / (2^14 + 2048) / 2^80 = 3.55 YiB as maximum connection.
On a 40Gibit line this will take less time than one might expect: URL (let's say 2.5-3 days with overhead).
Why do you divide by (2^14 + 2048)? Shouldn't it be a multiplication with the minimum record size?
I don't see much support for this. Please take it to the list if you want to pursue it.
Consensus at interim: No protocol action needed. Add calculations to security considerations.
Also, consensus is that the math above is wrong.
NAME would you be willing to contribute a PR with a paragraph or two of guidance on the limits for AES-GCM and ChaCha20
Yes. What happened to the Key Update message? I can't find it in the text, and that would be a logical place to mention the limitations as well as in the security considerations section.
URL If you want to just send a PR against that branch that would be fine. Or really, whatever form you want and I can manually merge.
If we ditch renegotiation (), then we will need a way to rekey sessions to extend their lifetime. Nico suggests that sending ChangeCipherSpec and then using an increasing counter to extract new keys (i.e., add a counter to the key expansion PRF input), which would seem to be sufficient.

We have asked David McGrew about the theoretical limits on AES-GCM, we can find the same info for ChaCha+Poly1305. When we have that info, we will make an assessment as to how urgent this is. That will determine how soon we define this mechanism. NAME noted that you don't even have to negotiate to enable rekeying: if you send the rekey message and rekey, your connection will either be rekeyed, or killed by the peer.
Change:
2. <ins> RFC3339 states that an offset given as "Z" or "+00:00" implies that "UTC is the preferred reference point for the specified time".  The offset "-00:00" is provided as a way to express that "the time in UTC is known, but the offset to local time is unknown". This convention mirrors a similar convention for date/time information in email headers, described in RFC5322 and introduced earlier in RFC2822.  The latter convention is in actual use, while the former always was handicapped by the fact that ISO8601 does not actually allow "-00:00". Implementations that needed to express the semantics of "-00:00" therefore tended to use "Z" as a "neutral" offset instead. This specification updates RFC3339, aligning it with the actual practice of interpreting the local offset "Z": this is no longer understood to "imply that UTC is the preferred reference point for the specified time". Note that the semantics of the local offset "+00:00" is not updated; this retains the implication that UTC is the preferred reference point for the specified time. Note also that the fact that ISO8601 does not allow "-00:00" as a local offset reduces the level of interoperability that can be achieved in using this feature; the present specification however does not formally deprecate this syntax.  For the intents and purposes of the present specification, the local offset "Z" can be used in its place. 3. </ins> This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends RFC3339 for use in Internet protocols. <del> 2.1. </del> <ins> 3.1. </ins> The format is intended to allow implementations to specify additional important information in addition to the bare timestamp.

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:
The next four bytes include a 32-bit Version field (see version). <del> The next byte contains the length in bytes of the two Connection IDs (see connection-id) that follow.  Each length is encoded as a 4-bit unsigned integer.  The length of the Destination Connection ID (DCIL) occupies the high bits of the byte and the length of the Source Connection ID (SCIL) occupies the 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; the final value is therefore either 0 or between 4 and 18 bytes in length (inclusive).  For example, a byte with the value 0xe0 describes a 17 byte Destination Connection ID and a zero byte Source Connection ID. The connection ID lengths are followed by two connection IDs.  The connection ID associated with the recipient of the packet (the Destination Connection ID) is followed by the connection ID associated with the sender of the packet (the Source Connection ID). </del> <ins> The next byte contains the length in bytes of the Destination Connection ID (see connection-id) field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Destination Connection ID field follows the DCID Len field and is between 0 and 255 bytes in length. The next byte contains the length in bytes of the Source Connection ID field that follows it.  This length is encoded as a 8-bit unsigned integer.  The Source Connection ID field follows the SCID Len field and is between 0 and 255 bytes in length. </ins> The remainder of the packet contains version-specific content.

Discussion:
I noticed this earlier today when trying to resolve conflicts relating to the connection ID change.
Suggestions accepted.
A couple of changes
Change:
MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired <del> WebTransport server.  An "Origin" header { {!RFC6454}} MUST be provided within the request. </del> <ins> WebTransport server.  In a Web context, the request MUST include an "Origin" header field ORIGIN that includes the origin of the site that requested the creation of the session. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server can check if it has a

Discussion:
Two things: Say what the header contains Limit it to the Web And fix the xref formatting.
Change:
Commit to the null optional.  Define "commit_secret" as the all- zero vector of the same length as a "path_secret" value would be. <del> Generate a new KeyPackage for the Committer's own leaf, with a "parent_hash" extension.  Store it in the ratchet tree and assign it to the "key_package" field in the Commit object. </del> If one or more PreSharedKey proposals are part of the commit, derive the "psk_secret" as specified in pre-shared-keys, where the order of PSKs in the derivation corresponds to the order of

Discussion:
It looks like in Commit was moved to in UpdatePath, but some docs didn't get updated.
Change:
versions of the protocol, or even be negotiated during the handshake via the use of transport parameters. <ins> Even though transport parameters transmitted in the client initial are obserable by the network, they cannot be modified by the network without risking connection failure.  Further, the negotiated reply from the server cannot be observed, so observers on the network cannot know which parameters are actually in use. </ins> 3.1.1. An in-network observer assuming that a set of packets belongs to a

Discussion:
which is about "Network-visible information about QUIC flows". They are mentioned once, based on a recent edit, but the text before that does not introduce them or explain what they are. Maybe we can add a few more sentences also making sure that even though they could be observed in the client initial, they cannot be changed nor observed form the server (to understand final negotiation/support).
Change:
These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low- <del> trust zones such as CDNs or remote data centers.  This allows server 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 on an external CA for such short-lived credentials.  In OCSP stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), 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, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </del> <ins> trust zones such as Content Delivery Network (CDNs) or remote data centers.  This allows server 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 on an external CA for such short- lived credentials.  In Online Certiicate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), 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, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </ins> To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own

Discussion:
Updating x690 version to match TLS1.2 (2015) Expanding acronyms (avoid genart) removed "!" from some refs (unneded) r/LURK/KEYLESS (completes derference from earlier PR).
Change:
Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD. <del> These limits were originally calculated using assumptions about the limits on TLS record size.  The maximum size of a TLS record is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is expected that QUIC packets will generally be smaller than TLS records.  Where packets might be larger than 2^14 bytes in length, smaller limits might be needed. </del> Any TLS cipher suite that is specified for use with QUIC MUST define limits on the use of the associated AEAD function that preserves margins for confidentiality and integrity.  That is, limits MUST be

Discussion:
We changed the limits listed here to be based on the maximum packet size, so the note a few paragraphs up citing the appendix is all we need here.
NAME said:
A few things here... The text in DTLS is a copy of this text, so similarities are no accident. However, the text has diverged, so drawing an analogy doesn't seem necessary (and I don't want a downref, even if it were informational). The numbers we are using from TLS is the target advantage probability. QUIC has a larger limit on packet size than TLS has on record size. Larger sizes affects the limits, which is what you see there. The note you quote is old and it should have been removed when we changed the numbers. As noted the analysis for DTLS would be helpful, but not definitive. As you say, the number of blocks in a packet can have an effect (though not for ChaCha20Poly1305 apparently). So l've a PR for the note, but I don't see any other action here.
I have an action item (to pester the DTLS 1.3 authors to reduce the divergence), but I agree there's no other action for this document.
Change:
have a string key that maps to any value.  Used to indicate a generic JSON object. <ins> All timestamps and time-related values (e.g., offsets) in qlog are logged as "float64" in the millisecond resolution. Other qlog documents can define their own CDDL-compatible (struct) types (e.g., separately for each Packet type that a protocol supports). </ins> 1.1.2. <del> While the qlog schemas are format-agnostic, and can be serialized in many ways (e.g., JSON, CBOR, protobuf, ...), this document only describes how to employ JSON, its subset I-JSON, and its streamable derivative JSON-Text-Sequences as textual serialization options.  As such, examples are provided in JSON.  Other documents may describe how to utilize other concrete serialization options, though tips and requirements for these are also listed in this document (concrete- formats). </del> <ins> Serialization examples in this document use JSON (JSON) unless otherwise indicated. </ins> 2.

Discussion:
There's too much text here that doesn't aid the reader. Delete it to be clear that we're using JSON as the notational convention for examples. If this text was valuable, it should be somewhere else.
I still feel we should have a "forward reference" here, indicating that we also discuss I-JSON and Streaming JSON considerations in this document, rather than making it seem we only do "pure JSON" due to the examples. Put differently, something like this should still be mentioned in this location imo:
But the fact it can be serialized to I-JSON has nothing to do with notational conventions used in this document, because we don't use any I-JSON.
NAME I just pushed a commit with a proposal to split up the original text to keep only a minimal amount in "Notational Conventions" but keep the core message alive in the introduction (which seemed the most logical location for now). I added the "unless otherwise indicated", as there are some examples of JSON-SEQ near the end of the document that obviously don't use RFC8259 notation directly. Please review and if approved, merge :)