jiebi/TextFlow huggingface dataset:
Original text:
datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard.  5. A WebTransport session over HTTP/3 is considered terminated when

Reviewer comments:
If a connection carrying WebTransport sessions receives a GOAWAY, is the sender allowed to continue 1) sending datagrams 2) creating new WT streams 3) receiving new WT streams I assume it's ok to continue sending data on already open WT streams and the CONNECT stream, but clarification would be good. Also, are the rules any different after sending a GOAWAY? Can the sender continue doing the above?
I'll just note that because in H2 WT streams are contained to a single stream, they are implicitly allowed there unless we forbid them.
Chair: discussed at IETF 113, consensus to have GOAWAY not prevent opening new WT streams on existing WT sessions. NAME will write a PR

Revised text:
datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard. <ins> 4.6. HTTP/3 defines a graceful shutdown mechanism (Section 5.2 of HTTP3) that allows a peer to send a GOAWAY frame indicating that it will no longer accept any new incoming requests or pushes.  This mechanism applies to the CONNECT requests for new WebTransport sessions.  A GOAWAY frame does not affect data streams for existing WebTransport sessions; those can continue to be opened even after the GOAWAY frame has been sent or received. </ins> 5. A WebTransport session over HTTP/3 is considered terminated when
Original text:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  8. 8.1.

Reviewer comments:
Porting URL originally posted to W3C WT NAME New connections should be throttled to avoid being a DoS vector. Maybe we will just have some language in the standard to permit and encourage throttling, and leave the details to browsers.
Shouldn't the throttling be performed at the W3C layer? If throttling happens, should the W3C API let the caller know?
I think this is a back-to-front way of suggesting that WebTransport include something like the guidance in URL (which I found , linked from URL
Oh thanks for finding that. I'm supportive of adding something like that.
I'm actually not sure that the specific requirement in WebSocket spec is useful, compared to just recommending throttling (or other forms of resource limits) in general.
The WebSocket throttling in RFC6455 requires you to implement it close to the socket layer (in particular, after DNS lookup), which is messy in practice. I think it may be sufficient to leave the details of the throttling to the implementation. If we want to ensure it is interoperable, a per-network-partitiion delay based on the number of pending and recently-failed connections should be sufficient.
So given that this is over HTTP/3, what is the anticipated throttling? Is it really just trying to tell HTTP clients to not make lots of requests? Is WebTransport sufficiently more expensive than other types of requests? I'm struggling to see language we would include here that is needed over language we have in QUIC or HTTP/3 already
Generally a browser will only make one HTTP/3 connection per server, regardless of how many resources the page requests. So servers don't need to worry about a well-behaved browser initiating large numbers of simultaneous QUIC handshakes. However, when WebTransport connections are not pooled, it is valid to make several at the same time. If there were no restrictions, a badly-behaved web page could request thousands of WebTransport connections simultaneously, DoSing the server.
Thanks Adam. I think phrasing thing as a design deviation from HTTP/3's recommendation to use one connection is good idea.
From what I can read from this discussion, there isn't that much in terms of design here, and this mostly requires writing up that throttling is up to the implementation.

Revised text:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <ins> A client could attempt to exhaust resources by opening too many WebTransport sessions at once.  In cases when the client is untrusted, the user agent SHOULD limit the number of outgoing sessions the client can open. </ins> 8. 8.1.
Original text:
3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by <del> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  That parameter is only defined for HTTP/2.  This document does not create a new multi- purpose parameter to indicate support for extended CONNECT in HTTP/3; instead, the SETTINGS_ENABLE_WEBTRANSPORT setting implies that an endpoint supports extended CONNECT. </del>  3.3.

Reviewer comments:
currently states: That is not well-defined: it relies on which only discusses HTTP/2, and the relevant changes between HTTP/2 and HTTP/3 are subtle. Since we have that is now in the RFC Editor Queue, WebTransport needs to instead refer to that and require servers to send .
This sounds like an obvious way forward. That said, I would personally prefer to wait until we make another breaking wire protocol change.
Sounds good to me, there's no rush here - in my personal opinion we just need to get this in before WGLC
More generally, it looks like we may want to remove any implied support and just require endpoints to explicitly signal support for each "layer" of capabilities that we're relying on.
Discussed at IETF 115, consensus in room to require all the relevant settings and transport parameters to be sent individually - for this issue means: require that SETTINGSENABLECONNECT_PROTOCOL be sent

Revised text:
3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by  <ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL setting.  That setting is defined for HTTP/3 by RFC9220.  An endpoint supporting WebTransport over HTTP/3 MUST send both the SETTINGS_ENABLE_WEBTRANSPORT setting and the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with values set to "1". </ins> 3.3.
Original text:
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) MUST be set to "webtransport".  The ":scheme" field MUST be "https". Both the ":authority" and the ":path" value MUST be set; those fields <del> indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided within the request. </del>  Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP/3 server can check if it has a

Reviewer comments:
This is vaguely based on the similar text in the WebSocket RFC.
In draft 03 the following requirement is made WebTransport's closest equivalent in this regard is WebSockets, which doesn't mandate the origin header; see URL This requirement makes it weird to use for user agents that have no concept of an origin model. So the MUST level seems a bit overzealous.
It is not just the user agent. Take for example the proposed use of . That application does not have any concept of "origin" -- indeed, there is no mention of the word "origin" in that draft.

Revised text:
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) MUST be set to "webtransport".  The ":scheme" field MUST be "https". Both the ":authority" and the ":path" value MUST be set; those fields  <ins> indicate the desired WebTransport server.  If the WebTransport session is coming from a browser client, an "Origin" header RFC6454 MUST be provided within the request; otherwise, the header is OPTIONAL. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP/3 server can check if it has a
Original text:
to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has an error code of 0 and an empty error string.  6. [[RFC editor: please remove this section before publication.]]

Reviewer comments:
This is mostly based on what Chrome currently does in production.
Chair: discussed during editor's meeting, plan is to remove text about 3 PTO and note that delivering other open streams is best-effort. Also add rationale and mention that this aligns with what QUIC does - this message has similar delivery guarantees as the close_connection in QUIC
A common use (at least for non-pooled WebTransport connections) will be to close the underlying QUIC connection when closing the WebTransport session. This is inherently racy: The sender will send both a CLOSEWEBTRANSPORTSESSION capsule and a QUIC CONNECTIONCLOSE frame (unless you wait for the peer's FIN on the request stream, but why would you?). It's undetermined which one of the two will be received / processed first by the receiver. This is not a problem if the sender uses the same error code and error message for the CONNECTIONCLOSE frame and for the CLOSEWEBTRANSPORTSESSION capsule. Assuming the QUIC stack properly exposes these values on its API, the receiver will be able to learn error code and error message. Should we add that as a recommendation, or even a requirement?
Chair: discussed during editor's meeting, see URL

Revised text:
to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has an error code of 0 and an empty error string. <ins> In some scenarios, an endpoint might want to send a CLOSE_WEBTRANSPORT_SESSION with detailed close information and then immediately close the underlying QUIC connection.  If the endpoint were to do both of those simultaneously, the peer could potentially receive the CONNECTION_CLOSE before receiving the CLOSE_WEBTRANSPORT_SESSION, thus never receiving the application error data contained in the latter.  To avoid this, the endpoint SHOULD wait until all of the data on the CONNECT stream is acknowledged before sending the CONNECTION_CLOSE; this gives CLOSE_WEBTRANSPORT_SESSION properties similar to that of the QUIC CONNECTION_CLOSE mechanism as a best-effort mechanism of delivering application close metadata. </ins> 6. [[RFC editor: please remove this section before publication.]]
Original text:
The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3: <del> The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated bidirectional streams to be used by WebTransport: </del>  0x41

Reviewer comments:
This updates the IANA considerations section for Frame Type to match URL, by including "server-initiated" in the type of bidirectional streams allowed by the frame.

Revised text:
The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3:  <ins> The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated and server-initiated bidirectional streams to be used by WebTransport: </ins> 0x41
Original text:
closing the connection.  The message takes up the remainder of the capsule, and its length MUST NOT exceed 1024 bytes. <del> A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the sender side.  If any additional stream data is received on the CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be reset with code H3_MESSAGE_ERROR.  The recipient MUST close the stream upon receiving a FIN.  If the sender of CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it SHOULD send STOP_SENDING on the CONNECT stream. </del>  Cleanly terminating a CONNECT stream without a CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent

Reviewer comments:
After sending the CLOSEWEBTRANSPORTSESSION capsule and sending the FIN on the stream, it would make sense to also stop reading on the stream (by sending a STOP_SENDING). Should that be the recommended behavior in the spec?
Chair: discussed at IETF 114, consensus in the room to allow but not require sending STOP_SENDING
The spec currently reads: So it currently recommends setting a timer and then issuing a STOPSENDING. I guess the request here is to send indicate the sender of CLOSEWEBTRANSPORTSESSION may send the STOPSENDING immediately. I'm going to remove the bit about the timer since it's not really relevant? If the closing endpoint wants to wait to see if there's any other messages in flight on the CONNECT stream that's fine. The CLOSEWEBTRANSPORTSESSION + FIN + must-respond-with-FIN is an implicit STOP_SENDING.
Fix the typo, raise an issue for the other thing.

Revised text:
closing the connection.  The message takes up the remainder of the capsule, and its length MUST NOT exceed 1024 bytes.  <ins> An endpoint that sends a CLOSE_WEBTRANSPORT_SESSION capsule MUST immediately send a FIN.  The endpoint MAY send a STOP_SENDING to indicate it is no longer reading from the CONNECT stream.  The recipient MUST close the stream upon receiving a FIN.  If any additional stream data is received on the CONNECT stream after receiving a CLOSE_WEBTRANSPORT_SESSION capsule, the stream MUST be reset with code H3_MESSAGE_ERROR. </ins> Cleanly terminating a CONNECT stream without a CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent
Original text:
amount of redundancy to add, as a function of the transport layer protocol and application requirements. <del> For the FEC within transport case, the addition of coding may hide congestion losses and proposing methods to signal such events to end point could be propose. </del>  For the FEC below transport case, there are opportunities for introducing interaction between congestion control and coding schemes proposing and comparing FEC coding solutions in communication systems.  As one example, this draft proposes discussions on the impact of the proposed FEC solution on the congestion control, <del> especially loss-based congestion control such as CUBIC. </del>  8.

Reviewer comments:
Added some precisions on the research section. When authors improve throughput by hiding the congestion signal, I propose to compare using FEC to hide the congestion signal with replacing the current congestion control by one that similarly ignores the loss signal without using any FEC. Concerning the solutions proposing to disambiguate the ACKs from the recoveries, I cited QUIC-FEC. We should also cite TENTET. NAME do you have a reference of an article about TENTET ? Do not hesitate to suggest changes before merging.
That looks very fine to me! We may just be missing the reference to tentet before merging the branch

Revised text:
amount of redundancy to add, as a function of the transport layer protocol and application requirements.  <ins> For the FEC within transport case, recovering lost symbols may hide congestion losses to the congestion control.  Some existing solutions already propose to disambiguate acked packets from rebuilt packets QUIC-FEC.  New signalling methods and FEC-recovery-aware congestion controls could be proposed. </ins> For the FEC below transport case, there are opportunities for introducing interaction between congestion control and coding schemes proposing and comparing FEC coding solutions in communication systems.  As one example, this draft proposes discussions on the impact of the proposed FEC solution on the congestion control,  <ins> especially loss-based congestion control such as CUBIC.  When a research work aims at improving the throughput by hiding the packet loss signal from the congestion control, the authors should 1) discuss the advantages of using the proposed FEC solution compared to replacing the congestion control by one that ignores a portion of the encountered losses, 2) critically discuss the impact of hiding packet loss from the congestion control mechanism. </ins> 8.
Original text:
control, it may be possible to signal to the congestion control mechanism that there was congestion (loss) even when a packet has been recovered, e.g. using ECN, to reduce the impact on the non-coded <del> flows (see subsec:cc-recov-inter-below). </del>  6.3. recovered is to exploit existing signaling that is understood by the congestion control mechanism.  An example would be to indicate to a TCP sender that a packet has been recovered (i.e., congestion has <del> occurred), by using ECN signaling. </del>  6.4.

Reviewer comments:
There are two possibilities either: "Point-to-point transmetting method based on the use of an erasure coding scheme and TCP/IP protocol", ISAE-SUPAERO (2019) EP 3 432 500 A1, WO 2019015931 (A1). URL "On the joint use of TCP and Network Coding", Emmanuel Lochin, IETF'100 NWCRG session, November 2017. URL
Since this is IPR protected content I gather the IPR declaration is up to date?
Yes Le mer. 28 oct. 2020 à 10:40, patibulon a écrit :
done in PR

Revised text:
control, it may be possible to signal to the congestion control mechanism that there was congestion (loss) even when a packet has been recovered, e.g. using ECN, to reduce the impact on the non-coded  <ins> flows (see subsec:cc-recov-inter-below and TENTET). </ins> 6.3. recovered is to exploit existing signaling that is understood by the congestion control mechanism.  An example would be to indicate to a TCP sender that a packet has been recovered (i.e., congestion has  <ins> occurred), by using ECN signaling TENTET. </ins> 6.4.
Original text:
Coding enables E2E reliable communication over DTN with adaptive re- encoding, as proposed in THAI15.  In this case, the use-cases <del> proposed in subsec:varying would legitimate the usage of coding </del>  within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding inside a Consultative Committee for Space Data Systems (CCSDS)

Reviewer comments:
Just corrected legitimize.
legitimate -> legitimize. This entire section is unnecessary. With this draft on a multi-gateway satellite system and DVB, you're talking about geostationary satellites which are always visible. Little disruption. 600ms or so delay is coped with by Internet protocols (RFC829 SATNET work etc.) So, not a significant delay issue either. It's out of scope for the abstract. And geostationary satellites generally don't use CCSDS for broadband; TDRSS is so much a special case. Since we're not standards track, References aren't split informative/normative -- but given the DVB starting point, I'd expect to see more DVB-S references. EN 302 307, which details extensions of the original satellite transmission standard DVB-S (EN 300 421), etc.
We need to discuss this point. Just corrected legitimize in

Revised text:
Coding enables E2E reliable communication over DTN with adaptive re- encoding, as proposed in THAI15.  In this case, the use-cases  <ins> proposed in subsec:varying would legitimize the usage of coding </ins> within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding inside a Consultative Committee for Space Data Systems (CCSDS)
Original text:
The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: <del> ACM : Adaptative Coding and Modulation; </del>  BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; <del> CPE: Customer Premise Equipment; </del>  COM: COMmunication; ETSI: European Telecommunications Standards Institute; <del> FEC: Forward Erasure Correction; </del>  FLUTE: File Delivery over Unidirectional Transport; NORM: NACK-Oriented Reliable Multicast; <del> PEP: Performance Enhanced Proxy RFC3135 - a typical PEP for </del>  satellite communications include compression, caching and TCP acceleration;

Reviewer comments:
ACM : Adaptative Coding and Modulation; -- Adaptive. This error repeats. CPE: Customer Premise Equipment; -- Premises. (My premise is that this is unfortunate.) FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help. FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo. PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's Enhancing and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for. PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
I have corrected the accronyms in PR We do not mention FECFRAME because it is an internal format and we focus on what is exchanged between access and physical gateways.

Revised text:
The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows:  <ins> ACM : Adaptive Coding and Modulation; </ins> BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer;  <ins> CPE: Customer Premises Equipment; </ins> COM: COMmunication; ETSI: European Telecommunications Standards Institute;  <ins> FEC: Forward Error Correction; </ins> FLUTE: File Delivery over Unidirectional Transport; NORM: NACK-Oriented Reliable Multicast;  <ins> PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for </ins> satellite communications include compression, caching and TCP acceleration;
Original text:
8. <del> Security considerations are inherent to any access network.  SATCOM systems introduce standard security mechanisms.  On the specific scenario of NC in SATCOM systems, there are no specific security considerations. </del> 

Reviewer comments:
The way it's said may call for comments during SecDir review. I'd rather say: Security considerations are inherent to any access network, and in particular SATCOM systems. The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section 3). However this is not specific to the SATCOM use-case and this document does not further elaborate on it.
Thanks for this suggestion. Closed by PR

Revised text:
8.  <ins> Security considerations are inherent to any access network, and in particular SATCOM systems.  The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section sec:use_cases).  However this is not specific to the SATCOM use-case and this document does not further elaborate on it. </ins>
Original text:
opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. <del> We have noticed an active research activity on coding and SATCOM in the past.  That being said, not much has actually made it to industrial developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. </del>  This document follows the taxonomy of coding techniques for efficient network communications RFC8406.

Reviewer comments:
"We have noticed an active research activity on coding and SATCOM in the past." -- if it's active, it's not in the past. if it's in the past, it's not active. Do you mean 'in the past we have noticed'? that's redundant.
You are right. This leads to some confusion. We propose to change as in PR

Revised text:
opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems.  <ins> We notice an active research activity on coding and SATCOM.  That being said, not much has actually made it to industrial developments. In this context, this document aims at identifying opportunities for further usage of coding in these systems. </ins> This document follows the taxonomy of coding techniques for efficient network communications RFC8406.