jiebi/CodeConvo huggingface dataset:
Change:
Abstract <del> DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication.  Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. </del> This document describes how to run DNS service over HTTP using https:// URIs.

Discussion:
... says: """ DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. """ Do we need to be talking about the motivation here? The way it's written sounds like it's using HTTP for tunnelling, which is something we wanted to avoid (especially if future efforts take away the message that HTTPS is the best tunnel).
I think the introduction does a decent job of dealing with the "not just a tunnel" question.. and therefore these motivators can live there and we can have a very simple 1 line abstract. (cutting non normative text is in vogue).. so I'll put up a PR that reflects that.
Change:
shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to <del> compromise of all keying material derived with the EDHOC-Exporter since the last invocation (if any) of the EDHOC-KeyUpdate function. </del> <ins> compromise of all keying material derived with the EDHOC-Exporter. </ins> Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force

Discussion:
Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.
Change:
name server side (which is what answers the query) and a resolver side (which performs the resolution function).  Systems operating in this mode are commonly called "recursive servers".  Sometimes <del> they are called "recursive resolvers".  While strictly the difference between these is that one of them sends queries to another recursive server and the other does not, in practice it is not possible to know in advance whether the server that one is </del> <ins> they are called "recursive resolvers".  In practice it is not possible to know in advance whether the server that one is </ins> querying will also perform recursion; both terms can be observed in use interchangeably.

Discussion:
"each other" is clearer in English. I agree that "whole labels" is better and have changed the text.
At line 139, "each other" may be "others" ? At line 358, "full labels" may be "whole labels" or "each label".
Change:
The copath of C is (D, AB, EFG) <del> The frontier of the tree is (ABCD, EF, G) </del> Each node in the tree is assigned a _node index_, starting at zero and running from left to right.  A node is a leaf node if and only if it has an even index.  The node indices for the nodes in the above

Discussion:
This deals cleanly with groups where the private key size doesn't align neatly with a hash function output size (e.g., X448), and saves a few hash invocations by removing intermediate values. A few editorial changes are included here as well. Depends on .
As discussed on call, folks are comfortable with this. Ready to merge, pending
Please merge when get a chance.
Change:
jump over the years due to increased consumption of entertainment as well as conversational video. <del> TBD: insert charts showing historical relative data usage patterns with error bars by time of day in consumer networks? TBD: Cross-ref vs. video quality by time of day in practice for some case study?  Not sure if there's a good way to capture a generalized insight here, but it seems worth making the point that demand projections can be used to help with e.g. power consumption with routing architectures that provide for modular scalability. </del> 2.5. Although TCP/IP has been used with a number of widely used

Discussion:
I don't remember where this suggestion came from, but it was on the list in the 107 interim slides, so I figured it should be tracked: URL
Maybe refer to Cisco VNI? URL
Cisco VNI link is already a 404, so ... Checking with RFC Editor to see whether they can handle SVG yet.
The point of this is trying to show internet scale growth of video traffic over time, both by proportion and by gross volume, not really about including pictures. This maybe is already covered by our intro paragraph: "Estimates put the total share of internet video traffic at 75% in 2019, expected to grow to 82% by 2022. This estimate projects the gross volume of video traffic will more than double during this time, based on a compound annual growth rate continuing at 34% (from Appendix D of [CVNI])." We should consider just closing this issue.
Related point (perhaps a new issue?): this info may stop being available--prior reports often came from DPI at IXPs or similar to monitor traffic, but since the dawn of ubiquitous encryption this info will stop being available, and we'll (probably?) only have reports from servers.
We're thinking this is Won't Fix - at a minimum, this isn't information we can update in the future.
Pulled these out of the text of the draft as part of this issue, from the bottom of section "2.4 Predictable Usage Profiles": TBD: insert charts showing historical relative data usage patterns with error bars by time of day in consumer networks? TBD: Cross-ref vs. video quality by time of day in practice for some case study? Not sure if there's a good way to capture a generalized insight here, but it seems worth making the point that demand projections can be used to help with e.g. power consumption with routing architectures that provide for modular scalability.
Change:
CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. <del> To address such environments, this document defines how to transport </del> <ins> Emerging standards such as Lightweight Machine to Machine LWM2M currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments in existing CoAP implementations and deployments.  Although HTTP/2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP. To address these requirements, this document defines how to transport </ins> CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. layering illustrates the layering:

Discussion:
Replacing "CoAP over TCP, TLS and Websockets" with "CoAP over reliable transports" is a good idea to reduce repetition. I feel it might be a good idea to clarify when we refer to reliable transports, that we actually refer to stream-based reliable transports. Datagram-based reliable transports (eg DCCP, QUIC, etc) exist, which render the Message Framing layer in Figure 1 unnecessary. I'm not advocating that we run CoAP over QUIC, DCCP etc but perhaps clarification would be wise.
See also
I would add a note to the terminology section that CoAP over reliable transports refers to stream-based transport protocols, such as TCP.
Sounds reasonable: The term "reliable transport" only refers to stream-based transport protocols such as TCP.
URL The term "reliable transport" only refers to stream-based transport protocols such as TCP. We could say more explicitly: sequenced/order-preserving, reliable... (Stream might be byte stream or message stream.) s/only refers/is used only to refer/
NAME - I would probably avoid "sequenced" which suggests sequence numbers and acknowledgements which are the mechanism to provide reliability. Perhaps too much detail? How about: The term "reliable transport" is used only to refer to transport protocols such as TCP which provide reliable and ordered delivery of a byte-stream.
NAME wrote: This concisely clarifies my initial concern, and I'm ok with this.
Change:
Section 16 of QUIC.  The context ID value of 0 is reserved for UDP payloads, while non-zero values are dynamically allocated: non-zero even-numbered context IDs are client-allocated, and odd-numbered <del> context IDs are server-allocated.  Implementations will provide a context ID allocation service.  That service will allow extensions to request a unique context ID that they can subsequently use for their own purposes.  This means that an HTTP client implementation of the context ID allocation service MUST only provide even-numbered IDs, while a server implementation MUST only provide odd-numbered IDs. The context allocation service MUST NOT return the same context ID twice, however it MAY return IDs in any order.  Once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. Additionally, note that the context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be simultaneously assigned different semantics in distinct requests, potentially with different semantics. </del> <ins> context IDs are server-allocated.  The context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be simultaneously assigned different semantics in distinct requests, potentially with different semantics.  Context IDs must not be re-allocated within a given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. </ins> Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does

Discussion:
Can you elaborate on what the motivation for this is? Introducing the "context ID allocation service" concept means that extensions can conveniently say "Then request a context ID from the allocation service and doo foo with it". If we remove this text, it'll make extension specs harder to write.
Occam's Razor. It's unnecessary complication that makes this text harder to read. I don't agree. The job of the specification is to document external behavior. I don't agree that it makes future specs more difficult. They can just say "allocate a context ID". It's an internal detail of the implementation that there is a context ID allocation service.
How about the following? It removes the concept but keeps the requirements we need.
I prefer removing the allocation service as a concept and specifying the requirements. I did find this a bit confusing in David's proposed text I think the point is clear already and the rationale is not required. Maybe remove this clause?
This text still has the problem that it first says you can allocate each context ID once and then later it says actually you can allocate it once per namespace. Why not say this upfront as in my PR?
My apologies NAME I think I had missed the added sentence in the middle when looking at this the first time. This LGTM modulo removal of the optional sentence at the end.
Change:
packet number for the range, the smallest value is determined by the formula: <del> An ACK Range acknowledges all packet numbers between the smallest packet number and the largest, inclusive. </del> <ins> An ACK Range acknowledges all packets between the smallest packet number and the largest, inclusive. </ins> The largest value for an ACK Range is determined by cumulatively subtracting the size of all preceding ACK Ranges and Gaps.

Discussion:
Packets are acknowledged, though packet numbers are communicated to acknowledge them.
One high-level comment. I believe the intent was to move most of the text about sending ACKs from recovery to transport. Also, if we defined ack-eliciting in transport, I think this PR and some other text would read more clearly. I can do that in a follow up PR.
Thanks for cleaning this up. One more TODO down.
Change:
2. <del> WebTransport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3 correspondingly). </del> <ins> WebTransport servers are identified by an HTTPS URI as defined in Section 4.2.2 of HTTP. </ins> When an HTTP/2 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to

Discussion:
This might seem unfortunate, but it's how the protocol works. Update the link to point to HTTP spec instead.
Change:
RFC5246 and TLS SignatureAlgorithm registries RFC5246: The values in this registry are only applicable to (D)TLS protocol <del> versions prior to 1.3. </del> <ins> versions prior to 1.3.  (D)TLS 1.3 and later versions' values are registered in the TLS SignatureScheme registry. </ins> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS

Discussion:
An open issue was whether to close the HashAlgorithms and SignatureAlgorithms registries or just reserve the values and point to the new 1.3 schemes. WRT opening a closed registry, IANA told me that opening a closed registry required another RFC or if we put in the IANA considerations section IESG Approval. With that info and the fact that at least one person was like "woah wait I might need to register some algorithms for TLS1.2", I don’t really see the point in closing the registry so I propose that we leave it as is, but that we update the text as noted in the PR to explicit point to the SignatureScheme registry.
I think that reserving them is the right thing for now. TLS 1.2 and earlier will take a while to disappear, so the ability to assign more values if there is a huge surprise seems prudent.
NAME PTAL
Change:
A frame was received on a stream where it is not permitted. <del> A Push ID greater than the current maximum Push ID was referenced. </del> <ins> A Stream ID, Push ID, or Placeholder ID greater than the current maximum for that identifier was referenced. </ins> A Push ID was referenced in two different stream headers.

Discussion:
Generalizes HTTPPUSHLIMITEXCEEDED to HTTPLIMIT_EXCEEDED and mandates use of that error code where a PRIORITY frame attempts to prioritize a stream the client isn't permitted to open yet. This has the effect of bounding priority tree state to requests the client could initiate (though might not have yet).
RFC 7540 at some length, especially what to do with priority information after a stream is closed. In addition to this, in HTTP/3, we have to deal with priority information before a stream is opened. That is: just how large is the tree allowed to grow before the referenced streams' frames begin to come in? The draft should provide some recommendations. I can think of two ways to do limit this "front-loaded" state: Open the stream when a PRIORITY frame referencing it arrives on the control stream. This will invoke the stream limit checks. Limit number of priority entries to number -- perhaps a function of the total number of maximum unidirectional and bidirectional streams.
Just clarifying: this would be advice to implementations, nothing normative, right?
I don't know. I think I will be happy as long as something is put into the draft.
Assuming that PRIORITY can only reference a stream that already "exists" client-side, the maximum number would be the number of permitted client-initiated bidirectional streams. Perhaps the requirements should simply be that PRIORITY cannot reference a stream that the client isn't permitted to open? I don't really want to "actually open" the stream when the PRIORITY frame arrives, but checking that it's less than the MAXSTREAMID on receipt seems like a reasonable server-side check.
Change:
Explicit support for multistreaming and multipath transport protocols, and the grouping of related Connections into Connection <del> Groups through cloning of Connections.  This allows applications to take full advantage of new transport protocols supporting these features. </del> <ins> Groups through "cloning" of Connections (see groups).  This function allows applications to take full advantage of new transport protocols supporting these features. </ins> 3.

Discussion:
The concept of cloning is used in the overview without introduction. I've suggested an earlier discussion of it in the architecture document, which would help, but even in this document, there should be an introduction or forward reference.
Change:
If the decryption fails, a fatal "bad_record_mac" alert MUST be generated. <ins> An AEAD cipher MUST NOT produce an expansion of greater than 256 bytes.  An endpoint that receives a record that is larger than 2^14+256 octets MUST generate a fatal "record_overflow" alert. </ins> As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL

Discussion:
As discussed on list.
Minor suggestions: 1) Explicitly specify the expectation of a "record_overflow" alert after the two "MUST NOT"s. 2) Also drop the issue "OPEN ISSUE" note that's on line 1087-1088. 3) Amend the changelog to mention this. 4) Add a sentence noting the overhead cap has changed to the "Note: In versions of TLS prior to 1.3" paragraph, or elsewhere.
As NAME suggests, I've updated the PR. I have not added the Note. I don't like those. The change log is enough.
Why was the changelog amended as for draft-09? The draft-08 hasn't been published yet. Is it in the progress of being released? (not shown on DataTracker and releases haven't been tagged on GitHub since draft-05)
Pilot error. Please feel free to submit a PR. , Dave Garrett EMAIL wrote:
This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later. This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.
Proposal at interim: 256 octets total.
Change:
Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or <del> obfuscated in any way.  For other kinds of packets, version 1 of QUIC </del> <ins> protected in any way.  For other kinds of packets, version 1 of QUIC </ins> cryptographically obfuscates other information in the packet headers: packet number: All packets except Version Negotiation and Retry

Discussion:
The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...
Change:
When a single application has the capability to process various data formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling <del> (e.g.  text, pdf, etc). </del> <ins> (e.g., TEXT, PDF). </ins> 5.

Discussion:
Addressing Lars' .
Debating adding more context than just "document". Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/1T23l8-kN8pEMqnQvh1ir3MsGVw). Did you mean "documents" here instead of "Internet-Drafts"? All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. File types are normally capitalized. A period is needed after the abbreviation "etc.".
Change:
5.2.1. <del> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. The nonce length MUST be no fewer than 4 and no more than 16 octets. </del> <ins> The nonce length MUST be no fewer than 4 octets. </ins> <del> The server ID length and nonce length MUST sum to 19 or fewer octets, and SHOULD sum to 15 or fewer octets to allow space for server use. </del> <ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. </ins> 5.2.2.

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
The certificate message contains an opaque string called certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is <del> provided, the certificate_request_context can be chosen arbitrarily. </del> <ins> provided, the certificate_request_context can be chosen arbitrarily but MUST be unique within the scope of the connection and be unpredictable to the peer. </ins> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version

Discussion:
NAME The crc can be derived in two places: the authenticator request and the unsolicited authenticator. I want to make sure the requirement is clear in both places.
Issue raised by Jonathan Hoyland at IETF 102
So you just wanted to repeat the requirement? Because that first bit already said no repeats.