jiebi/CodeConvo huggingface dataset:
Change:
blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be <del> opened for each chunk/message.  However, a QUIC receiver has a maximum number of concurrently open streams.  If the stream limit is exhausted a sender is able to indicate that more streams are needed, however, this does not automatically lead to an increase of the maximum number of streams by the receiver.  Therefore it can be valuable to expose this maximum number to the application, or the number of currently still available, unused streams, and make the mapping of data to streams dependent on this information. </del> <ins> opened for each chunk/message.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver. Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </ins> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually not be reached with current applications.  Applications that send chunks of data over a very long period of time (such as days, months, <del> or years), should rather utilize the 0-RTT seesion resumption ability </del> <ins> or years), should rather utilize the 0-RTT session resumption ability </ins> provided by QUIC, than trying to maintain one connection open. 4.1.

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
connecting to a device from the Internet unless the connection was initiated by the device. <del> This document specifies the means for nodes with limited reachability to communicate using simple extensions to CoAP.  The extensions enable publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes. Furthermore the extensions facilitate many-to-many communication using CoAP. </del> <ins> For some applications the client/server and request/response communication model is not optimal but publish-subscribe communication with potentially many senders and/or receivers and communication via topics rather than directly with endpoints may fit better. This document specifies simple extensions to CoAP for enabling publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes.  This model facilitates communication of nodes with limited reachability, enables simple many-to-many communication, and eases integration with other publish-subscribe systems. </ins> 2.

Discussion:
This mechanism is also useful for cases where the pub/sub paradigm instead of classic req/resp is desired (one-to-many, many-to-one, many-to-many communications, etc.).
Change:
The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect, <del> using the system's current default interface or path, and starting a TCP handshake to establish a stream to the specified IP address. However, each step may also differ depending on the requirements of the connection: if the endpoint is defined as a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple interfaces or paths available, other than the default system interface; and some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. </del> <ins> using the system's current default path (i.e., using the default interface), and starting a TCP handshake to establish a stream to the specified IP address.  However, each step may also differ depending on the requirements of the connection: if the endpoint is defined as a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple paths available, (in this case using an interface other than the default system interface); and some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. </ins> Whenever an implementation has multiple options for connection establishment, it can view the set of all individual connection

Discussion:
After reading , I reviewed the latest text. I'm unsure I want to make changes to Arch/API: I see path as "network path", that is the set of hops through which the packet is forwarded (the local interface being the first local hop, and PvD information/PMTU/etc relating to something non-local). This changes the examples using interface to align with this.
Impl draft, section 4.1.2: "Each node will be summarized by a tuple of three elements: Endpoint, Path, and Protocol. The above example can now be written more succinctly as: 1 [URL, Any, TCP] 1.1 [URL, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.2 [URL, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]" looking at the example I would not call this "Endpoint, Path, and Protocol" but "Remote Endpoint, Local Endpoint or interface, and Protocol". Not sure we have defined the term Path well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair.
Yeah, it is "remote endpoint", "interface/local endpoint", and "protocol".
note that the wording needs to be fix at least in a few more places, so whoever puts the PR in should probably reach for the word path and ensure it's used correctly...
especially 4.1.3.2. (Alternate Paths) wouldn't fit that well anymore and would probably need some rewriting...
Change:
TRANSPORT is used. The quic_transport_parameters extension is carried in the ClientHello <del> and the EncryptedExtensions messages during the handshake. </del> <ins> and the EncryptedExtensions messages during the handshake.  Endpoints MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST terminate the TLS handshake with a fatal missing_extension alert (an error of 0x16d). </ins> While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the

Discussion:
All of them have defaults.
If you mean "Is sending TP mandatory", I don't think so. An endpoint that doesn't receive a TP assumes the default value. An endpoint that uses a default value does not need to advertise it.
The issue could have been more precisely worded. The question was about the entire QUIC transport parameters extension. Individual parameters are still clearly optional. We should be very crisp about that. Up until -18, this was mandatory, but we don't need the version parameters any more.
One nice property of making the TLS transport parameters extensions mandatory is that it helps mitigate cross-protocol attacks: QUIC servers can abort the connection if it's missing and TLS over TCP servers can abort if the extension is present.
I think we can call the entire extension as an option. As to NAME point, I'm not sure if it helps in practice. TLS 1.3 stacks that run on top of TCP does not have (and it's doubtful if all of them would have) the capability to detect and raise an error when it sees the QUIC TP extension.
Our defense for cross-protocol attacks is ALPN. Then key separation, and probably other things. While layers of defense is generally a good idea, transport parameters don't need to be another secondary layer.
I agree with NAME and NAME points. This was more of a belt-and-suspenders approach. That said, I still think every single deployment will actually send transport parameters, therefore requiring the extension to be present sounds simpler to implement. But I don't feel too strongly about this.
The question arose when we realized that you can have a perfectly functional stack with the defaults. And it was non- trivial sending any. However, if the client doesn't send any, it prevents the server from sending any. That seems bad.
That argument is more compelling than mine.
Discussed in Prague; no pushback against making them mandatory.
NAME can you make that into a PR?
There already is a PR, it just wasn't tagged properly as closing this issue.
Change:
background-check model, this Evidence may also be revealed to Relying Party(s). <del> 8. </del> <ins> 7. </ins> <del> 8.1. </del> <ins> 7.1. </ins> Today, Evidence tends to be highly device-specific, since the information in the Evidence often includes vendor-specific

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
<del> Network coding and satellites </del> <ins> Coding techniques for satellite systems </ins> draft-irtf-nwcrg-network-coding-satellites-05 Abstract This memo details a multi-gateway satellite system to identify <del> multiple opportunities on how network coding techniques could be deployed at a wider scale. </del> <ins> multiple opportunities on how coding techniques could be deployed at a wider scale. </ins> 1.

Discussion:
A first sentence says quasi-error-free is usually guarranteed thanks to redundancy, while the following sentence tends to say the opposite. Not very clear.The intro fails to clarify the targets. Among them there is "coding to recover from packet losses" (to avoid confusion with bit-error corrections), but also "coding to improve the usage of radio resource". You should also clarify better what is meant by coding: it's not a content coding (e.g., to compress a video flow) but rather a computation of linear combination of packets. Say since the begining you'll rely on RFC8406 whenever possible. Parts of the text currently in section 3 (1st paragraph) deserve to be moved here.Typo: s/to cope from/to cope with/
We have updated the introduction structure and changed the usage of coding in the whole document. We hope this is better. cf PR and PR
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR
"In this context, this document aims at identifying opportunities for further usage of coding in these systems." again, network coding. this pretending that link and channel FEC don't exist and that "coding", i.e. network coding, is somehow new is irksome.
Closed by PR
Change:
of reference for future solution proposals to describe how new technologies address or avoid existing problems. <del> generalized network performance techniques; while things like datacenter design and transit network design can be crucial dependencies for a performant streaming media service, these are considered independent topics better addressed by other documents. </del> <ins> generalized network performance techniques; while considerations such as datacenter design, transit network design, and "walled garden" optimizations can be crucial components of a performant streaming media service, these are considered independent topics better addressed by other documents. </ins> transparent tunnels; while tunnels can have an impact on streaming media via issues like the round-trip time and the maximum

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
If an HTTP/3 Datagram is received and its Quarter Stream ID maps to a stream that cannot be created due to client-initiated bidirectional stream limits, it SHOULD be treated as an HTTP/3 connection error of <del> type H3_ID_ERROR.  Generating an error is not mandatory in this case because HTTP/3 implementations might have practical barriers to determining the active stream concurrency limit that is applied by the QUIC layer. </del> <ins> type H3_ID_ERROR.  Generating an error is not mandatory because the QUIC stream limit might be unknown to the HTTP/3 layer. </ins> Prioritization of HTTP/3 Datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams and MAY

Discussion:
We suggest rephrasing this sentence. The phrase "might have practical barriers to determining..." is difficult to parse. Does the suggested text below accurately convey the intended meaning? Original: Generating an error is not mandatory in this case because HTTP/3 implementations might have practical barriers to determining the active stream concurrency limit that is applied by the QUIC layer. Perhaps: Generating an error is not mandatory in this case because HTTP/3 implementations might present practical barriers when determining the active stream concurrency limit that is applied by the QUIC layer.
The point we're making here is that the implementations might encounter barriers, either because they contain them, or the API the are using presents them. The suggestion doesn't cover these two response. Alternative Perhaps: Generating an error is not mandatory in this case because there might be practical barriers that prevent HTTP/3 implementations from determining the active stream concurrency at the QUIC layer.
How about we just nuke this sentence?
I've just rememberd this text is verbatim copied from URL ADs seem to like justifcations for SHOULD requirements. If we're worried about verbosity, then how about Generating an error is not mandatory because the QUIC stream limit may be unknown to the HTTP/3 layer.
That works for me
Change:
other protocols necessary for safe operation in browsers. Worth noting is that many applications for ultra low-latency delivery <del> do not need to scale to more than one user at a time, which </del> <ins> do not need to scale to more than a few users at a time, which </ins> simplifies many delivery considerations relative to other use cases. <del> For applications that need to replicate streams to multiple users, especially at a scale exceeding tens of users, this level of latency has historically been nearly impossible to achieve except with the use of multicast or planned provisioning in controlled networks. </del> Recommended reading for applications adopting an RTP-based approach also includes RFC7656.  For increasing the robustness of the playback

Discussion:
Yes, lets add it. Well, I really don't want to imply that right provisioning requires QoS or at least some DSCP marking. Yes, to many, the answer could be just providing enough bandwidth for others, it could be a bit more complicated. If you have seen my recent ANRW talk, I refer to the "QoS" as the first camp (slide 5) and many efforts to date simply failed in that aspect. Paper: URL Slides: URL
I like this text. I have thoughts. Do we need a reference for "bufferbloat"? We haven't used that term in the document yet, and I agree with using it here. I note . I agree with "the right provisioning", but for someone not skilled in the art, that may be like "and then a miracle occurs", and I suspect a lot of people still assume "the right provisioning" means something like "the right bandwidth provisioning", which isn't what we mean at all, is it? ISTM that we might (1) mention DSCP, (2) mention URL as something to be aware of.
Change:
10.5. <del> Connectedness: Unconnected </del> <ins> Connectedness: Connectionless </ins> Data Unit: Datagram

Discussion:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.
Change:
number space, which is the sequence number of Destination Connection ID of the 1-RTT packets which are acknowledged by the ACK_MP frame. If the endpoint receives 1-RTT packets with 0-length Connection ID, <del> it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames. </del> <ins> it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If an endpoint receives a ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </ins> 10.

Discussion:
Should we trigger an connection closure with a MPCONNECTIONERROR in the case an endpoint receives an ACK_MP frame acknowledging packets on a non-existing packet number space ID?
Yes. I just submitted PR for this issue.
PR merged.
LGTM.
Change:
There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it.  Because <del> ICE keepalives are indications, they will not work here.  I-D.ietf- rtcweb-stun-consent-freshness describes the mechanism for providing consent freshness. </del> <ins> ICE keepalives are indications, they will not work here.  RFC7675 describes the mechanism for providing consent freshness. </ins> 4.2.2.

Discussion:
I-D nits complained about a couple of outdated and unused references. This fixes them. Note that a few still remain.
Change:
defines protocol types, the definition format uses the notation from QUIC.  This specification uses the variable-length integer encoding from QUIC.  Variable-length integer values do not need to be encoded <del> on the minimum number of bytes necessary. </del> <ins> in the minimum number of bytes necessary. </ins> Note that, when the HTTP version in use does not support multiplexing streams (such as HTTP/1.1), any reference to "stream" in this

Discussion:
This adds some additional security considerations, touching on privacy considerations at the same time. Do we want to say anything about IP fragmentation, or at least point to some existing guidance around how to avoid sharp edges there? Please feel free to reframe or modify the text as you see fit!
Change:
The "service-limit" is expressed in "quota-units" and has the following syntax: <ins> where quota-units is a non-negative sf-integer. </ins> The "service-limit" SHOULD match the maximum number of acceptable requests.

Discussion:
uses structured fields based on NAME preliminary work: thanks!!!referencing the RFC distinguishing sf-item and sf-integer, since sf-integer do not support parameters whereas sf-item does retaining the intermediate syntaxes (quota-policy, quota-units, service-limit, ...)
LGTM, waiting on ack from NAME before merging.
NAME thanks for reviewing! Can we merge?
It's your draft :)
I take it for a YES :D
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
7.2.1. <del> Packet protection for QUIC v1 is specified is Section 5 of QUIC-TLS. The general principles of packet protection are not changed for QUIC Multipath.  No changes are needed for setting packet protection keys, initial secrets, header protection, use of 0-RTT keys, receiving out- of-order protected packets, receiving protected packets, or retry packet integrity.  However, the use of multiple number spaces for 1-RTT packets requires changes in AEAD usage. </del> <ins> Packet protection for QUIC version 1 is specified is Section 5 of QUIC-TLS.  The general principles of packet protection are not changed for QUIC Multipath.  No changes are needed for setting packet protection keys, initial secrets, header protection, use of 0-RTT keys, receiving out-of-order protected packets, receiving protected packets, or retry packet integrity.  However, the use of multiple number spaces for 1-RTT packets requires changes in AEAD usage. </ins> Section 5.3 of QUIC-TLS specifies AEAD usage, and in particular the use of a nonce, N, formed by combining the packet protection IV with

Discussion:
Be consistent with RFC9000
In order to be consistent with RFC9000, use "QUIC version 1" instead of "QUIC v1" through the document.