jiebi/CodeConvo huggingface dataset:
Change:
shared used to derive the ESNI key. A cryptographic hash of the ESNIKeys structure from which the ESNI <del> key was obtained, i.e., from the first byte of "checksum" to the </del> <ins> key was obtained, i.e., from the first byte of "version" to the </ins> end of the structure.  This hash is computed using the hash function associated with "suite".

Discussion:
The checksum seems to add little value with the retry mechanism and record_digest. I think we should remove it. See for some context.
The I-D says: "recorddigest : A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure. This hash is computed using the hash function associated with suite." From looking at the NSS code it appears that the recorddigest input is actually the entire ESNIKeys (after base64 decode) including the version and checksum. Is that correct? IOW, does the following also produce the right value (for CF and sha256)? `
proposes removing the checksum, which should clear this up.
Closing since landed. NAME please re-open if this is still an issue!
The hash used in the extension should use the same hash inputs as the checksum. The difference here just makes using this harder.
I support the change, if that makes people feel more comfortable about having the checksum field in ESNIKeys.
I'm not opposed, but it doesn't help as much as you might think, because you need to compute the label with the cipher hash and not (necessarily) with SHA-256.
So, if you take my suggestion in (which I know NAME doesn't like, but we simply disagree about that), then you can identify the ESNI using a truncated hash that is calculated using the cipher hash because it only appears in the context of a handshake. But that just suggests that this is either not-helpful because we chose not to do anything in , or it is not necessary because we did. I'm OK closing this on that basis.
Checksum is now gone. Closing this issue. NAME thanks for filing it!
I agree that we can now and should make this simplification. The PR looks good to me.
Change:
However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using <del> the IP address should proactively try to prevent spoofing of the IP </del> <ins> the IP address SHOULD proactively try to prevent spoofing of the IP </ins> address.  Similarly, if the mapping of IP address to User Equipment <del> is changed, the components of the architecture must remove or update </del> <ins> is changed, the components of the architecture MUST remove or update </ins> their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not

Discussion:
Does this also need to update the boilerplate text that defines SHOULD, MUST, etc?
forgot to mention that, but the draft is already updated to use 8174 boilerplate
In the paragraph starting at line 633, we say: In particular, " Consequently, any solution using the IP address should proactively" and "the components of the architecture must remove or update their" I think we should either capitalize these two or rephrase them.
Aside from my one comment, lgtm. I don't think the intention of the issue was to rephrase everything that used lowercase, but to make sure that we capitalized everything we needed to.
changed the 2 to capital case
lgtm, thanks.
A scrub for these to determine which are really requirements is a good idea. Also, update SS1.1 to use RFC 8174 boilerplate.
looks OK to me
Change:
Address case nits <ins> Add text around using an oracle to forge DCs in the future and past </ins> Add text about certificate extension vs EKU draft-08

Discussion:
NAME please go ahead and merge after resolving conflicts!
From Martin: The security considerations don't cover the potential for misissuance creating a credential that is as long-lived as the certificate, but they probably should.
NAME I'm not sure what you mean here. Are you talking about explicitly calling out the possibility that the credential may expire after the certificate and that this should be forbidden?
If you are able to access the signing key of the certificate, or are otherwise able to construct a DC, you can create multiple DCs that cover the time from now until the certificate expires. It's not a big deal, but I thought it might be worth noting.
Gotcha. I'll note this.
Closed in
Change:
the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. <del> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is subsequently used.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. </del> <ins> Unlike the token that is created for a Retry packet, which is used immediately, the token sent in the NEW_TOKEN frame might be used after some period of time has passed.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. </ins> A token issued with NEW_TOKEN MUST NOT include information that would allow values to be linked by an on-path observer to the connection on

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:
justifies the existence of a non-blank leaf in the ratchet tree in step 5. <del> The update secret resulting from this change is the path secret computed for the root node of the ratchet tree in the first step. </del> <ins> The "update_secret" resulting from this change is the "path_secret[i+1]" derived from the "path_secret[i]" associated to the root node. </ins> 10.

Discussion:
"The update secret resulting from this change is the path secret for the root node of the ratchet tree." is suspicious because in the derivation, the index for both the and is the same as the level of the node. It should be the "above the root" and not "for the root" (which is the one used to derive the of the root)...
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:
Abstract In many IoT applications, direct discovery of resources is not <del> practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. </del> <ins> practical due to sleeping nodes, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined. </ins> 1.

Discussion:
We were asked about the term in Erik's comments, and nobody could explain its relevance to the RD; removing it. See-Also: URL
Change:
For any dots (".") outside character classes (first alternative of "charClass" production): replace dot by "[^nr]". <del> Envelope the result in "^" and "$". </del> <ins> Envelope the result in "^(?:" and ")$". The ECMAScript regexp is to be interpreted as a Unicode pattern ("u" flag; see Section 21.2.2 "Pattern Semantics" of ECMA-262). </ins> Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/".

Discussion:
Clarifications in conversion to platform regexps.
Looks plausible but I don't know these regexps well enough to approve.
Change:
Each header block contains a Required Insert Count, the lowest possible value for the Insert Count with which the header block can <del> be decoded.  For a header block with no references to the dynamic table, the Required Insert Count is zero. </del> <ins> be decoded.  For a header block with references to the dynamic table, the Required Insert Count is one larger than the largest Absolute Index of all referenced dynamic table entries.  For a header block with no references to the dynamic table, the Required Insert Count is zero. If the decoder encounters a header block with a Required Insert Count value larger than defined above, it MAY treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED.  If the decoder encounters a header block with a Required Insert Count value smaller than defined above, it MUST treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED as prescribed in invalid-references. </ins> When the Required Insert Count is zero, the frame contains no references to the dynamic table and can always be processed

Discussion:
Currently the draft is inconsistent: if the Required Insert Count value in a header block is smaller than dictated by the referenced dynamic table entries, {{overview-hol-avoidance}} says the decoder MAY treat this as a stream error, while {{invalid-references}} says it MUST. This PR seeks to clarify this.
Change:
3. <del> 3.1. </del> <ins> This section illustrates one less obvious example for using application/multipart-core: combining it with observing a resource RFC7641 to handle pending results. </ins> <del> When a client registers to observe a resource RFC7641 for which no </del> <ins> When a client registers to observe a resource for which no </ins> representation is available yet, the server may send one or more 2.05 (Content) notifications before sending the first actual 2.05 <del> (Content) or 2.03 (Valid) notification.  The possible resulting sequence of notifications is shown in Figure 1. </del> <ins> (Content) or 2.03 (Valid) notification.  A diagram depicting possible resulting sequences of notifications, identified by their respective response code, is shown in fig-sequence. </ins> The specification of the Observe option requires that all notifications carry the same Content-Format.  The application/

Discussion:
Address Benjamin Kaduk's outstanding DISCUSS.
No: with that, the sender sends along all formats and the recipient chooses based on its capabilities or preferences. Appropriate for single-shot mail, not at all appropriate for a request/response situation (at least not for the response part). URL Grüße, Carsten
Ah sorry, hadn't read properly (it's sender, not receiver).
LGTM
Change:
jump over the years due to increased consumption of entertainment as well as conversational video. <del> 2.5. </del> <ins> 2.6. </ins> Although TCP/IP has been used with a number of widely used applications that have symmetric bandwidth requirements (similar

Discussion:
This definitely needs more work!
NAME and NAME - I have three notes in the section I've added. I'll hit this again later in the week, but if you can express opinions about any of them, that would be very helpful.
NAME In the call we discussed this and we feel like we don't need to say anything about this in addition to what we already said in Section titled "Bitrate Detection Challenges". So, maybe we can drop and close this?
I actually like NAME suggestions - let me spend a couple of hours on this, and then you two can either merge it or reject it.
NAME and NAME see what you think. I'm also ok with closing as wontfix, but wanted to give it a try.
NAME and NAME any thoughts on this PR? I tried to reflect Jake's high-level comments, which were even more helpful and actionable than usual ...
This reads much better than the initial version, thanks.
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Mark Nottingham) in response to call for help on capturing the mismatch between supply and demand of bandwidth with regard to video: Dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) "These are big numbers, but the internet has grown over time, and CDN capacities have grown over time. Is it last mile? Probably not--Is it middle mile? Maybe that's more interesting. It it CPU? Is it network cards? Is it the economics of your peering relationships? Unpicking those bits might help a bit. URL
For many, poor Wifi is the culprit. For many others, the ISP aggregation links are the culprit during the prime times (since most such links are oversubscribed/oversold). For some, the CDN issues create problems and for rare cases, the origin drowns and everybody gets upset. For certain environments like student dorms, campus networks, libraries, airport cafes, it is just lack of bandwidth for the power users.
Thanks, this version reads much better to me. I have no objections.
Change:
2.5. <del> The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client selects the version most likely to be supported from the versions that are compatible with the client's most preferred version. Without additional information this could mean selecting the oldest </del> <ins> When the client picks its original version, it will try to avoid incompatible version negotiation to save a round trip.  Therefore, the client SHOULD pick an original version to maximize the combined probability that both: The server knows how to parse first flights from the original version. The original version is compatible with the client's preferred version. Without additional information, this could mean selecting the oldest </ins> version that the client supports. 3.

Discussion:
Section 2.5 says unconditionally that the client chooses the most compatible version. This isn't right, because the most compatible version isn't what it is looking to end up on. What the client should choose is probably the most compatible version of those that are compatible (directionality ?) with its most preferred version.
Rereading this, I think the directionality is correct in the existing text. But perhaps we could figure out better wording.
LGTM with the following edits.
Change:
Likewise, the requirements for parameters on templated links are the same as those for a Link header field. <ins> However, the "anchor" parameter MAY contain a URI Template.  For example: Here, the link to the author for a particular book in a list of books can be found by following the link template. </ins> This specification defines additional semantics for the "var-base" parameter on templated links; see below.

Discussion:
Has there been any consideration of allowing a URI Template for the parameter? A particular use case would be for a collection resource that includes links from each item in the collection. If the media type supports fragments, then the item link could be templatized to point from specific locations in the representation. If we had a collection of books represented as an object with an array, and the instance media type allowed JSON Pointers: As an example of links between the full book resource and another resource, so as not to have to fetch the entire book resource if it is not needed, an author link template could be something like this (ignoring the likelihood of multiple authors): I was looking at this I-D in comparison to the (currently tabled) JSON Hyper-Schema project, and I think that anchor templates are the most notable relevant Hyper-Schema feature that is not present here. I would love to be able to use a revived Hyper-Schema as a bridge between a link-template header field and JSON-compatible data.
Change:
using the same mechanisms. If validation succeed, the client can send non-probing, 1-RTT packets <del> on the new paths.  In contrast with the specification in section 9 of </del> <ins> on the new paths.  In contrast with the specification in Section 9 of </ins> QUIC-TRANSPORT, the server MUST NOT assume that receiving non-probing packets on a new path indicates an attempt to migrate to that path. Instead, servers SHOULD consider new paths over which non-probing

Discussion:
Fix issue
I went ahead and replaced the references to RFC9000 by QUIC-TRANSPORT, and RFC9001 by QUIC-TLS. I have checked that this produced the expected XML V3.
RFC9000 is cited massively in the draft. It would be helpful to indicate to the reader where to look by indicating the section. Some change examples are provided below: and so on.
Side comment -- please see issue about the use of XML2RFC v3 syntax for links. We can do some of that, but not necessarily everywhere. We do expect that readers are familiar with QUIC V1. If we want to say "we are just in line with QUIC V1", then a global reference to RFC 9000 should suffice. If we want to say "please read this text in QUIC V1, we don't want to replicate here", then yes, we should refer to the specific section.
Thanks, Christian. That's the intent.
The draft is using old style references, such as "section 9 of {{RFC9000}}". Version 3 of XML2RFC defines a structure way to do that, such as: , which can be expressed in recent versions of Markdown as . The new style references don't change the text version much, but in the HTML rendering they generate direct references to the target section, which is nice for the readers.
Sorry, that's my fault because of my local build system. Will fix this for the next revision...
With the fixed references, it works now...
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> The following terms are used: </del> This document uses the presentation language of RFC8446 to define messages in the DAP protocol.  Encoding and decoding of these messages as byte strings also follows RFC8446.

Discussion:
Based on . Update the definitions to align better with terminology in the VDAF draft. Also, add "aggregation paramter" and "public share".
Change:
first byte being set; packets with a short header have that bit cleared. <ins> QUIC packets might be integrity protected, including the header. However, QUIC Version Negotiation packets are not integrity protected; see vn. </ins> Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length.

Discussion:
URL's just a Version field. This is a subtle one, but it follows from the work that others have been doing on greasing versions or providing additions to echconfig for QUIC connection establishment. It basically says that Version is for endpoints, not middleboxes.
I like the idea here, but it seems like the distinction in the text is too subtle. Why not remove this entirely?
By "this", do you mean striking ?
I was actually suggesting removing it from invariants entirely.
I would quibble a bit about whether or not version aliasing really violates the existing text, but I still think this change is a good one. For example, if we fail to prevent ossification then we're going to end up with this being the "fake" version while the real version is buried in the TPs.
The invariants spec currently defines Version thusly: This implies that packets in which this field is present are packets for connections that use the associated version. An overzealous, but not unreasonable interpretation of this might lead to a middlebox looking at Version=N and assuming that the packet conforms to QUIC version N. Actions taken on that basis might be detrimental, especially if we consider options like those proposed in draft-duke-quic-version-aliasing or draft-kazuho-quic-authenticated-handshake. In other words, this commits us to something we already know we might not want to commit to. It would be better to simply state the format of the field and that it is used by endpoints to identify the version. I have done this in .
There seems to be support for this issue and , and the change is editorial.
As an individual, I wonder if it would be worthwhile to add text to the draft that explicitly calls out that it is not safe for anybody other than the endpoints to assume knowledge about what protocol version an observed version number refers to. I think this it the implicit goal, making it explicit is IMO more direct. (This could also be something for the ops-drafts to talk about though.)
NAME relabelled the PR as design a few days ago, so it this potentially a design issue?
Looking at the diff, I don't really see a need for labelling it design. NAME why the design label?
It's a subtle change, but it is a change in the design of the invariants.

It's saying that a packet marked version 0x13 isn't necessarily carrying a packet encoded in version 0x13, even if an observer speaks that version. Merely that the bytes 0x00000013 are somehow useful to the recipient in identifying the version. Previously, we made the assertion that the version field indicated what version was used in the packet.
Let's run this through the design issue process to be sure.
So it seems we have a resolution in . Labelling as such.
Change:
first byte being set; packets with a short header have that bit cleared. <ins> QUIC packets might be integrity protected, including the header. However, QUIC Version Negotiation packets are not integrity protected; see vn. </ins> Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length.

Discussion:
Or MAY, but let's leave this probabilistic, because in practice there is no uncertainty: packets are protected. I've changed the header of the section because it isn't just about the header: the subsections are about the specific headers, but this one is about packets as a whole.
Change:
The serialized and encrypted ClientHelloInner structure, AEAD- encrypted using HPKE with the selected KEM, KDF, and AEAD <del> algorithm and key generated as described below.  {:br} </del> <ins> algorithm and key generated as described below. {:br} </ins> If the server accepts ECH, it does not send this extension.  If it rejects ECH, then it sends the following structure in

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.