jiebi/CodeConvo huggingface dataset:
Change:
messages, such as UDP, can only be used with Messages that are Safely Replayable. <del> Final: when this is true, this means that a transport connection can be closed immediately after transmission of the message. </del> <ins> Final: when this is true, this means that the sender will not send any further messages.  The Connection need not be closed (in case the Protocol Stack supports half-close operation, like TCP).  Any messages sent after a Final message will result in a SendError. </ins> Corruption Protection Length: when this is set to any value other than "Full Coverage", it sets the minimum protection in protocols <del> that allow limiting the checksum length (e.g.  UDP-Lite). </del> <ins> that allow limiting the checksum length (e.g.  UDP-Lite).  If the protocol stack does not support checksum length limitation, this property may be ignored. </ins> Reliable Data Transfer (Message): When true, the property specifies that the Message must be reliably transmitted.  When

Discussion:
Section 5.1.2: "the implementation should hold off on processing Messages until the batch is complete" assumes that there is indeed a context-switch penalty. Batch semantics are only for hints to the implementation/protocol stack, and this advice only applies when that hint allows the stack to reduce context switch penalty. Correct? (If so, this should be noted explicitly)
Actually 5.1.3. This reads odd to me, I'd expected myself more like: "When this is used, the implementation can defer the processing Messages until the batch is complete." (eliminating "off on", also from this sentence?)
Agreed, I think your text reads better NAME should it be "... defer the processing of Messages ..." though? I think it also solves the question from NAME as it is now expressed as an opportunity for the implementation.
I believe these are all editorial. First, this list needs some front matter: "protocols should implement each of the following Message Properties on send as follows" or similar. "Ordered" should state that protocols that do not support configurable ordering may ignore the property. "Final" should note that it is not mandatory to close the connection after a Final message. "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. One open question: is it an error to send a Message after a Final message, and does the protocol implementation need to handle this itself?
... "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. ... In protocols such as UDP-Lite, various tunnels would, DCCP allows, etc.
I think it should be an error to send a Message after a Final message and the implementation of the transport services system should handle it. If it is not an error, then it will fail sometimes and sometimes not depending on if the connection is closed or not, that seems less useful to me.
Change:
Abstract <del> This memo details a multi-gateway satellite system to identify multiple opportunities on how coding techniques could be deployed at a wider scale. </del> <ins> This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).  This document follows the taxonomy document RFC8406 and considers coding as a linear combination of packets that operate above the network layer.  In this context, this memo details a multi-gateway satellite system to identify use-cases where coding is relevant.  As example, coding operating above the network layer can be exploited to cope from residual losses or provide reliable multicast services.  The objective is to contribute to a larger deployment of such techniques in SATCOM systems.  This memo also identifies open research issues related to the deployment of coding in SATCOM systems, such as the interaction between congestion controls and coding techniques. </ins> 1.

Discussion:
abstract This memo details a multi-gateway satellite system to identify multiple opportunities on how network coding techniques could be deployed at a wider scale. this is talking about network coding, and this draft needs to be perfectly clear throughout that it is doing so, otherwise people who know and use other coding and have had little use for network coding previously will simply stop reading. Blurring the coding case is not helping your cause. I called this out previously. This is important.
Vincent: Abstract: The current abstract is not sufficiently detailed: which type of coding? Do you refer to FEC or NC (say so) since it may also be used for other types of coding. The notion of "wider scale" also suggests it is already deployed (is it the case?), or that it may be used outside of the multi-gateway satellite system itself. On the whole, this abstract is pretty ambiguous.
abstract must mention the origin. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).
We have rephrased the whole abstract and we think PR cover this issue.
Change:
and Traversal Using Relays around NAT (TURN) RFC5766, and then checks the connectivity of each local-address-remote-address pair in order to select the best one.  The addresses that are collected usually <del> consist of an endpoint's private physical/virtual addresses and its public Internet addresses. </del> <ins> consist of an endpoint's private physical or virtual addresses and its public Internet addresses. </ins> <del> These addresses are exposed upwards to the web application, so that they can be communicated to the remote endpoint for its checks.  This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. </del> <ins> These addresses are provided to the web application so that they can be communicated to the remote endpoint for its checks.  This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. </ins> The information revealed falls into three categories:

Discussion:
This reverts commit 0dac1b124828835c5785c4ae703c26ad3d19f65f.
Change:
10.1. <del> Informally, the primary security and privacy goals of ECH against an active attacker are as follows: </del> <ins> ECH considers two types of attackers: passive and active.  Passive attackers can read packets from the network.  They cannot perform any sort of active behavior such as probing servers or querying DNS.  A middlebox that filters based on plaintext packet contents is one example of a passive attacker.  In contrast, active attackers can write packets into the network for malicious purposes, such as interfering with existing connections, probing servers, and querying DNS.  In short, an active attacker corresponds to the conventional threat model for TLS 1.3 RFC8446. Given these types of attackers, the primary goals of ECH are as follows. </ins> Use of ECH does not weaken the security properties of TLS without ECH.

Discussion:
cc NAME
In just a few sentences, let's define the anonymity set and say what it means for connections to end points in this set to be indistignuishable. We might also enumerate non-goals (though we still need consensus on what these are).
I've not yet gotten around to the PR yet, but here's the gist: Attackers: Passive attackers are those which cannot probe, e.g., buggy middleboxes that filter based on plaintext packet contents. Active attackers can probe, e.g., censors. Goals: ECH does not negatively affect any existing security properties of TLS 1.3. ECH connections to servers in the same anonymity set are indistinguishable from one another for passive and active attackers, modulo traffic analysis. (Note: an anonymity set is determined by the client and server parameters, e.g., the SNI, supported application protocols, and so on.) ECH support is secret from passive attackers who don't know the ECH configuration, but not active attackers. ECH usage is secret from passive attackers who don't know the ECH configuration, but not active attackers. More specifically: Passive attackers with a known ECH configuration can distinguish between a connection that negotiates ECH with that configuration and one which does not (GREASEd or using a different configuration). Passive attackers without the ECH configuration cannot distinguish between a connection that negotiates ECH and one which does not (but GREASEd). Active attackers can distinguish between a connection that negotiates ECH and one which does not (but GREASEd).
Yeah this looks good.
From the interim: merge this as a PR and then address censorship separately (if desired).
Change:
An endpoint has reached the confidentiality or integrity limit for the AEAD algorithm used by the given connection. <ins> An endpoint has determined that the network path is incapable of supporting QUIC.  An endpoint is unlikely to receive CONNECTION_CLOSE carrying this code except when the path does not support a large enough MTU. </ins> The cryptographic handshake failed.  A range of 256 values is reserved for carrying error codes specific to the cryptographic handshake that is used.  Codes for errors occurring when TLS is

Discussion:
This is a bit of a niche code, as it is only narrowly useful for signaling loss of paths. But people wanted it and it doesn't code that much. Note the target of this pull request. For .
I'm going to leave this for a bit, but if people like the idea, I plan to merge it into .
Thank you for the PR. This error code will be useful, as the only other way of closing the connection would be to use NO_ERROR. Then, it would be impossible to know why the connection was abruptly closed.Yes, there's value in having a way to fail URL suggestion, but lgtm
Change:
in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter value SHALL be either "0" or "1", with "0" being the default; an endpoint that receives a value other than "0" or "1" MUST close the <del> connection with the H3_SETTINGS_ERROR error code.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating QUIC DATAGRAM extension SHALL result in a H3_SETTINGS_ERROR error. HTTP3 requires client's "initial_max_bidi_streams" transport parameter to be set to zero.  Existing implementation might enforce this requirement before negotiating settings; thus, the client MUST send a non-zero MAX_STREAMS for client-initiated bidirectional streams after receiving an appropriate SETTINGS frame from the server. </del> <ins> connection with the H3_SETTINGS_ERROR error code. The client MUST NOT send a WebTransport request until it has received the setting indicating WebTransport support from the server. Similarly, the server MUST NOT process any incoming WebTransport requests until the client settings have been received, as the client may be using a version of WebTransport extension that is different from the one used by the server. </ins> 3.2.

Discussion:
NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!
Change:
second case, the expert is instructed to ascertain that a basic specification does exist, even if not complete or published yet. <del> 6. </del> <ins> 7. </ins> TBD

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:
exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. <del> 4.8. </del> <ins> 4.9. </ins> QUIC Connection IDs are opaque byte fields that are expressed consistently across all QUIC versions QUIC-INVARIANTS, see rebinding.

Discussion:
addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.
Change:
updated root key after an Update operation, it cannot compute any derived secrets. <ins> In the case where the client could have been compromised (device loss...), the client SHOULD signal the delivery service to expire all the previous ClientInitKeys and publish fresh ones for PCS. </ins> 12.4. Initialization keys are intended to be used only once and then

Discussion:
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 5 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there were no stargazers. - - 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 .
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors.

:bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - 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:
6. <del> Note: This section is still very early and is likely to significantly change as we get a better understanding of a) the use cases for this b) the implications at the protocol level c) feedback from implementors on what they can do. </del> <ins> It is possible to change elements in the SDP returned from createOffer before passing it to setLocalDescription.  When an implementation receives modified SDP it MUST either: Accept the changes and adjust its behavior to match the SDP. Reject the changes and return an error via the error callback. Changes MUST NOT be silently ignored. </ins> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription, since

Discussion:
Sure, I can do that.
Justin and I discussed on the call and this is still borked due to some git pilot error.
PTAL now.
LGTM
Section 6 indicates that programmers can edit the SDP and lists changes which can and cannot be made. It explicitly is preliminary and needs to be fleshed out.
There are three categories - must reject, must act on , and ones that the browser can do whatever it wants but if it is not acted on then an error is generated
General approach is most things are in the "browser can do what it wants case"
Discussed in DC: this applies only to changes on the local side; the gap between createOffer/createAnswer and setLocalDescription. Proposed path is to mandate one of two actions: Accept the changes and apply them Reject the changes outright We will enumerate certain changes that fall into either category, but these lists will not be exhaustive. All unspecified changes will either be accepted or rejected, and that decision will be left to the browser, but they cannot be ignored. Obviously, some types of changes will be ignored. For instance, reordering of a= lines might not be detected as a change. These might carry semantics (as a=group-id does), but we can't require perfect detection.
Change:
(PWMCW) defined in RFC4385.  An aggregation label (A-Label) is a special case of S-Label used for aggregation. <del> A node operating on a DetNet flow in the Detnet service sub- layer,uses the local context associated with that S-Label, provided by a received F-Label, to determine what local DetNet operation(s) are applied to that packet.  An S-Label may be taken from the platform label space RFC3031, making it unique, enabling DetNet flow </del> <ins> A node operating on a DetNet flow in the Detnet service sub-layer, uses the local context associated with that S-Label, provided by a received F-Label, to determine what local DetNet operation(s) are applied to that packet.  An S-Label may be taken from the platform label space RFC3031, making it unique, enabling DetNet flow </ins> identification regardless of which input interface or LSP the packet arrives on.

Discussion:
Thanks for Don's fine tuning.
NAME cam you review and merge if you're good with the changes.
Change:
Properties may be Generic, applying regardless of transport protocol, or Specific, applicable to a single implementation of a single transport protocol stack.  Generic Connection Properties are defined <del> in connection-props below.  Specific Protocol Properties are defined in a transport- and implementation-specific way, and MUST NOT be assumed to apply across different protocols.  Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol are simply ignored, and do not raise an error; however, too much reliance by an application on Specific Protocol </del> <ins> in connection-props below. Protocol Specific Properties are defined in a transport- and implementation-specific way, and MUST NOT apply across different protocols.  Too much reliance by an application on Protocol Specific </ins> Properties can significantly reduce the flexibility of a transport services implementation.

Discussion:
Section 6 says. "Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol are simply ignored, and do not raise an error" Should this be normative? "Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol MUST be ignored, and MUST NOT raise an error" I note that this a random sentence where spotted that normative language could be used. I don't look for these kind of occasion systematically...
I could see a case that the first requirement to ignore, I think this actually a requirement for predictable interop? (in which case we could motivate that?) I am much less sure of the second MUST, and think an error notification is not an interop issue?
The first MUST is definitely important for code portability, and so I think this is a good suggestion. I'm also less sure of the second MUST, but I think it's good to keep: yes, errors can be ignored by an application, but they can also lead to application code like: adjust QUIC properties if error: adjust TCP properties If an application absolutely must do this and must find out what's going on, it can, it's ok for a Transport Services system to make everything readable... but throwing errors in addition is yet another hint for a programmer to start developing code like this. We should discourage such code. That's why I'd keep the MUST NOT (as a counter-example, "SHOULD NOT" would mean that there would have to be a good reason for the designer of a Transport Services system to make an exception - what would such a reason be? "This particular function of this particular protocol is so important, I think here I should really throw an error after all?" - Nah...).