jiebi/CodeConvo huggingface dataset:
Change:
discussed in the TCPM working group I-D.ietf-tcpm-converters. To cope with packet loss (due to either end-user mobility or <del> physical-layer impairments), coding could be introduced in both the CPE and at the concentrator. </del> <ins> physical-layer impairments), coding techniques could be introduced both at the CPE and at the concentrator. </ins> 3.4. <del> This use-case considers the usage of coding to cope with cases where channel condition can change in less than a second and where the physical-layer codes could not guarantee a Quasi-Error-Free (QEF) transmission. </del> <ins> This use-case considers the usage of coding techniques to cope with cases where channel condition can change in less than a second and where the physical-layer codes could not guarantee a Quasi-Error-Free (QEF) transmission. </ins> The architecture is recalled in fig:varying_capa.  In these cases, Adaptative Coding and Modulation (ACM) may not adapt the modulation

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:
frames uses the following format (using the notation from the "Notational Conventions" section of QUIC): <del> A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated with, divided by four (the division by four stems from the fact that HTTP requests are sent on client-initiated bidirectional streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 -1, so the largest legal value of Quarter Stream ID is 2 -1.  Receipt of a frame that includes a larger value MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR. The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. </del> Receipt of a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR.

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
connection IDs for distinguishing packets sent to that node over different paths. <ins> Each endhost may use several IP addresses to serve the connection. In particular, the multipath extension supports the following scenarios. The client uses multiple IP addresses and the server listens on only one. The client uses only one IP address and the server listens on several ones. The client uses multiple IP addresses and the server listens on several ones. </ins> This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths are assumed to be handled by the application that is using the QUIC <del> multipath extension.  Further, this proposal only specifies a simple basic packet scheduling algorithm, in order to provide some basic </del> <ins> multipath extension.  This is sufficient to address the first aforementioned scenario.  However, this document does not prevent future extensions from defining mechanisms to address the remaining scenarios.  Further, this proposal only specifies a simple basic packet scheduling algorithm, in order to provide some basic </ins> implementation guidance.  However, more advanced algorithms as well as potential extensions to enhance signaling of the current path state are expected as future work.

Discussion:
This draft only enables clients to open a new path, so the most common scenario is that the client has another interface and opens a new path from a new IP address. However, if the client knows another IP that the server is listing on to accept new paths for an existing quic connection (e.g. provided on the higher layer or out of band), that can be used as well. It would be useful to discussion this case more in the draft to ensure that it is clear that this case is supported.
I think as people who implement multipath will mostly refer to this draft, we may want to clarify all scenarios supported by this draft: (1) client has multiple IPs while server listens on single IP, (2) client uses single IP while server listens on multiple IP, and (3) client uses multiple IPs and the server also uses multiple IPs.
LGTM
Change:
[RFCthis] <ins> 10.  References 10.1.  URIs [1] http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml </ins>

Discussion:
URL Ensure that all "Section N" references are updated.
URL Cl.8.5: I think it would be easier for IANA if the coaps+tcp and coap+tcp URI schemes were described like the websockets ones in 8.5.1 and 8.5.2. This is another case with a heavy dependency on RFC7252 references.
URL We need to fill in the template.
URL s/are potentially accessible/are intended to be accessible/ [Editor] Same language is used for coap+wss. [Editor] Ironically, "potentially accessible" was copied from CoAP Classic - RFC7252. ~
URL Cl.6.2: This indicates ABNF is used for the definitions. However clause 6.1.1 and 6.1.2 make no mention of the ABNF syntax or reference to RFC3986. The descriptions of the definitions of the URI schemes in 6.2, 6.1.1 and 6.1.2 should be harmonised. This could be more consistent. Currently, coap+tcp and coaps+tcp rely on references to coap and coaps in RFC7252: The semantics defined in [RFC7252], Section 6.1, apply to this URI scheme, with the following changes and require that the reader is also familiar with URL The syntax of the "coap" and "coaps" URI schemes is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", "query", "segment", "IP-literal", "IPv4address", and "reg-name" are adopted from [RFC3986].
Additional feedback - URL CoAP URIs In this section, the terms "client" and "server" are used WRT the TCP connection, not WRT CoAP, and that may be very confusing. Maybe use different terms here (initiator/responder)? [Note from editor] - The terms are used in the coaps+tcp section on ALPN. Since there are already references to ClientHello and ServerHello perhaps it could be clarified with "TCP client" and "TCP server"? 6.1.

CoAP over TCP and TLS URIs Not sure this belongs here, but it also should apply to 6.2, so maybe move it up to 6. Ditto. s/potentially reachable/intended to be reached/ The following paragraph applies to 6.1.1, 6.1.2, and this subsection. (Move up to 6.) (They can't be in a CoAP request; not sure what the MUST NOT means. But again, this also applies to the TCP/TLS case.) 6.2.1. Decomposing and Composing URIs Wrong use of MUST. (MUST it be included or is this a MUST NOT if equal?) Ditto.
The outline for the URI scheme definitions needs to follow the guidance in URL which now requires:
Change:
There are three different approaches to racing the attempts for different nodes of the connection establishment tree: <del> Immediate </del> <ins> Simultaneous </ins> <del> Delayed </del> <ins> Staggered </ins> Failover Each approach is appropriate in different use-cases and branch types. However, to avoid consuming unnecessary network resources, <del> implementations should not use immediate racing as a default </del> <ins> implementations should not use simultaneous racing as a default </ins> approach. The timing algorithms for racing should remain independent across

Discussion:
Opening this to follow up on a comment by NAME on that is now closed. "Simultaneous" and "Staggered" would be better names than "Immediate" and "Delayed". Just from these terms, I would normally think that "Immediate" means to start racing right away, whereas "Delayed" means that nothing would happen for some time. So these two terms are slightly misleading in my opinion.)
I agree this would be an improvement.
LGTM (of course :-) )Thanks, looks good!
Change:
if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of <del> type TRANSPORT_PARAMETER_ERROR. </del> <ins> type TRANSPORT_PARAMETER_ERROR.  If an endpoint receives a Chosen Version equal to zero, or any Other Version equal to zero, it MUST treat it as a parsing failure. </ins> Every QUIC version that supports version negotiation MUST define a method for closing the connection with a version negotiation error.

Discussion:
Should an endpoint be required to reject a transport parameter that contains 0?
Sure.
CC with ?
That's what I currently have in my implementation :)
Off topic but what if version 0 is included in Supported Version of a VN packet?
That would make the VN packet malformed. I'd suggest either dropping such packets or ignoring the zero.
OK. I modified my client to drop such packets as same as the case of the original version included.
I considered treating it as an error, but as it is an unauthenticated packet, it's better to drop it. I've done the same for ours.
Change:
3.4.5.2. An "index-wild-selector" selects the nodes of all member values of an <del> object as well as of all elements of an array.  The behaviour is unpredictable for an object with duplicate names. </del> <ins> object as well as of all elements of an array. </ins> Applying the "index-wild-selector" to a primitive JSON value (that is, a number, a string, "true", "false", or "null") selects no node.

Discussion:
Centralize the text that explains how non-interoperable JSON may cause unpredictable behavior. This is a little clumsy as the sections to be referenced are currently unnumbered.
Solves a few "behaviours", too :-)
This centralizing approach is a good thing. I suggest to reuse the phrase "duplicate names" for better recognition of the wording in RFC8259, though is more general, as it addresses more than two.
There may be scope for fine-tuning the section cross-referencing, but this can be deferred to purely editorial activity
Change:
Issuing new credentials, <del> Validating existing credentials against a reference identifier, and </del> <ins> Validating a credential against a reference identifier, and </ins> Validating whether or not two credentials represent the same user.

Discussion:
Replaces Not compact.
When deploying MLS, the deployer/implementer needs a certain set of choices made. For example, authentication authorities, transport choices, how to interpret application data, etc. This draft could create a succinct summary format that a deployer could use as a checklist to make sure they've done the legwork necessary to be able to deploy MLS safely. this came up in the IETF 113 meeting.
If the draft describes such a summary as a template, then maybe some of the existing deployments could try filling it in, so we could see whether it's sufficient.
I actually think the answer here is fairly compact, and mostly laid out in the arch spec, so it's mainly a question of pulling together the threads. Basically, the application needs to define: An authentication service A delivery service What the content of the messages will be
compact is good and it looks like your list aligns roughly with the intuitions i opened this issue with, so that's good too. Are there any choices about cryptographic primitives that need to be decided as well (e.g. ciphersuite limitations or requirements, expected credential types)? What about MLS extensions or MLS proposals that clients connected to this deployment are expected to support or avoid?
I have no idea whether the template i outlined in is correct, let alone exhuastive. I offer it as a starting point, and won't be upset if anyone wants to step in to improve/correct it.
Really like this direction, few small tweaks.This looks good. Thanks Brendan, Thanks Richard!
Change:
necessarily includes any transport and application layer delay at both sides. <del> The spin bit experiment, detailed in QUIC-SPIN, provides an additional method to measure intraflow per-flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit described in that document changes value once per round-trip time (RTT).  An on-path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end-to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </del> <ins> The spin bit provides an additional method to measure intraflow per- flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit on short header packets changes value once per round-trip time (RTT).  An on- path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end- to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </ins> An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit

Discussion:
Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.
Change:
The TLS handshake is a lock-step cryptographic protocol.  Messages must be transmitted and received in a defined order; any other order is an error.  The DTLS handshake includes message sequence <del> numbers to enable reassembly in the correct order in case datagrams are lost or reordered. </del> <ins> numbers to enable fragmented message reassembly and in-order delivery in case datagrams are lost or reordered. </ins> During the handshake, messages are implicitly acknowledged by other handshake messages.  Some handshake messages, such as the

Discussion:
== COMMENTS == -- Section 3 -- s/TLS cannot be used directly in datagram environments/TLS cannot be used directly over a datagram transport/ ? [Hannes] DTLS is also used over non-IP-based networks (e.g. LoRaWAN, NB IoT, Bluetooth Smart) and "datagram transport". What would be the right term to describe "environments" that include transport layer protocols like UDP as well as those non-IP-based networks? Bullet 2) s/to enable reassembly in the correct order/to enable reordering/ ? [Hannes] The complete sentence is: " The DTLS handshake includes message sequence numbers to enable reassembly in the correct order in case datagrams are lost or reordered. " I believe that saying sequence numbers enable reassembly in the correct order is correct. -- Section 3.1 -- Should there be a hint to a maximum retry count ? [Hannes] There will be a retry count in an implementation. Do we need to say that if we don't have a number to suggest? Not sure. -- Section 3.3 -- I understand the motivation (and no need to reply), but, sigh... implementing frag/reassembly above the transport layer... [Hannes] Seems to be common these days. Examples: CoAP, and QUIC
I don't think I found the PR to match up with the "pr-exists" label; could I get a pointer?
My bad. URL
Change:
<del> Encrypted ClientHello for TLS 1.3 </del> <ins> TLS Encrypted Client Hello </ins> draft-ietf-tls-esni-latest Abstract <del> This document defines a mechanism for encrypting a TLS 1.3 ClientHello. </del> <ins> This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. </ins> 1.

Discussion:
Seeing no pushback on the list, this moves the draft from Experimental to ST.
The design can apply to TLS 1.4 and beyond (presumably).
Done in .
Change:
RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD <del> at the same time, but that is not expected to supported by typical EP implementations.  Any such registrations are independent of each other. For this case to occur, the EP would need to be explicitly configured to register multiple times: either by having multiple discovery mechanisms or addresses configured (which are not merely fallbacks to each other), or by having several sets of registration data to register with (eg. multiple endpoint names). </del> <ins> at the same time if explicitly configured to do so, but that is not expected to be supported by typical EP implementations.  Any such registrations are independent of each other.  The usual expectation when multiple discovery mechanisms or addresses are configured is that they constitute a fallback path for a single registration. </ins> 3.3.

Discussion:
The implementors in RIOT asked about whether a registrant could possibly maintain multiple registrations at different RDs, and how they interact. I think what I'm saying in this PR is obvious (though not redundant, as we don't talk about that topic otherwise), but given it was asked about, it's probably not. What are your opinions?
(Text updated after I learned more about what they thought was expected from Registrant-EPs.)
Shortened and merged.
A registrant-ep cannot be forbidden to register with multiple RDs anyway. May be a bit too much text for an obvious fact.
Change:
The extension type is specified as follows. The extension_data field of this extension, when included in the <del> ClientHello, MUST contain the CID structure, which contains the CID </del> <ins> ClientHello, MUST contain the CID structure, which carries the CID </ins> which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.
Change:
particular .  Oblivious HTTP uses a one-to-one mapping between ; see proxy-state for more details. <del> This information allows the to make a request of a with that resource having only a limited ability to correlate that request with the IP or other requests that the might make to that server. </del> <ins> This information allows the to send HTTP requests to the for forwarding to a .  The does not learn the client's IP address or any other identifying information that might be revealed from the client at the transport layer, nor does the learn which of the requests it receives are from the same . </ins> <del> In order to make a request to a , the following steps occur, as shown in fig-overview: </del> <ins> In order to forward a request for a to the , the following steps occur, as shown in fig-overview: </ins> The constructs an HTTP request for a .

Discussion:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM
Change:
value of the capsule type) allows a client to inform the server that datagram contexts will not be used with this stream.  It also informs the server of the encoding and semantics of datagrams associated with <del> this stream.  Its Capsule Data field consists of: </del> <ins> this stream. </ins> A variable-length integer that defines the semantics and encoding of the HTTP Datagram Payload field of datagrams, see datagram-

Discussion:
The thing that sucks here is that the diagram won't auto expand , so we can't easily ref the section. Manually referring to the section is a maintenance pain. So instead just state the actual type in the text an the diagram. I have a feeling you were linking to the section to avoid the maintenance hassle of updating type codes in multiple place. But I'm quite happy to take that burden because I find it more pleasant to read this way.
Perfectly reasonable
QUIC and HTTP/3 style is to define the general format and then in each instance define the object including all of its fields. This would look like This can later be updated with the actual type value once things settle down
Fine by me.
There's a disparity between the largest flow ID that can be carried in the DATAGRAM frame and the largest that we can express in Datagram-Flow-Id. Draft 00 prevents a flow ID allocation of >= 10^15-1 but doesn't seem to address the case where a DATAGRAM frame contains that value. This is clearly an error, and I'd suggest that it is a connection error; probably or some new codepoint if we really wanted.
I don't think that needs to be an error, we can simply treat this like any other unknown flow ID?
IMO this is clearly a situation that shouldn't happen and indicates the sending endpoint probably has some bug. I'm not sure on what being silent on the matter helps.
This issue is no longer relevant now that we have merged , closing.