jiebi/TextFlow huggingface dataset:
Original text:
that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered in the PHY layer coding and are out of the scope of this document.  fig:existing_network presents the status of the reliability schemes deployment in satellite systems. discussions. X2 embodies the physical-layer, applied to the PLFRAME, to <del> optimize the satellite capacity usage.  At the physical layer, FEC mechanisms can be exploited. </del>  Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques.  Based on public information,

Reviewer comments:
John Border: Forward Error Correction (FEC) coding below the network layer takes us a long way. At the same time, I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough. I do see that the referenced taxonomy document includes Forward Erasure Correction. This “FEC” is described as an application layer technique. The overlapping use of “FEC” is unfortunate for those of who work down at the lower layers. In any case, it is not always clear which “FEC” the document is referring to.
I understand that there is some confusion on the usage of the accronym. We have clarified in the document that "Following the taxonomy document [RFC8406], channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." We have added in PR that this document considers FEC above the network layer.

Revised text:
that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <ins> This document considers FEC as coding mechanisms above the network layer only. </ins> fig:existing_network presents the status of the reliability schemes deployment in satellite systems. discussions. X2 embodies the physical-layer, applied to the PLFRAME, to  <ins> optimize the satellite capacity usage.  At the physical layer, other coding mechanisms can be exploited. </ins> Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques.  Based on public information,
Original text:
this scenario in fig:rel_multi. A multicast flow (M) is forwarded to both satellite terminals A and <del> B.  However packet Ni (resp.  Nj) get lost at terminal A (resp.  B), </del>  and terminal A (resp.  B) returns a negative acknowledgment Li (resp. Lj), indicating that the packet is missing.  Then either the access gateway or the multicast server includes a repair packet (rather than feedback link is available, or File Delivery over Unidirectional Transport (FLUTE) RFC6726 otherwise.  Note that both NORM and FLUTE are limited to block coding, none of them supporting sliding window <del> encoding schemes RFC8406. </del>  4.3.

Reviewer comments:
Answer to issue
John Border: Section 4.2, 2nd Paragraph "Unidirectional" implies (to me) no ACKs. Without ACKs, FLUTE must do repair in such a way as to not need to know exactly what was lost. This seems different enough to me to be explained separate from NORM.
Our objective is not to discuss about NORM and FLUTE, which is out of scope of the document. We cite these protocols as possible usage example. Also note that although FLUTE is unidirectional, the RFC keeps a door open proposing bidirectional communications for security purpose and to enable full reliability transfer. As a result, we move this sentence at the end of this section as a complementary material and completed the FLUTE description.

Revised text:
this scenario in fig:rel_multi. A multicast flow (M) is forwarded to both satellite terminals A and  <ins> B.  However packet Ni (resp.  Nj) gets lost at terminal A (resp.  B), </ins> and terminal A (resp.  B) returns a negative acknowledgment Li (resp. Lj), indicating that the packet is missing.  Then either the access gateway or the multicast server includes a repair packet (rather than feedback link is available, or File Delivery over Unidirectional Transport (FLUTE) RFC6726 otherwise.  Note that both NORM and FLUTE are limited to block coding, none of them supporting sliding window  <ins> encoding schemes RFC8406.  Note that although FLUTE is defined as an unidirectional protocol, the RFC proposes a bidirectional communication method to enable full reliability transfer and for security purpose. </ins> 4.3.
Original text:
SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2 <del> and layer-1 encapsulations.  PEP could host coding techniques and thus support the use-cases that have been discussed in this document. </del>  Deploying coding schemes at the TCP level in these equipment could be relevant and independent from the specific characteristics of a <del> SATCOM link.  However, there is a research issue in the recurrent trade-off in SATCOM systems: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? </del>  4.2.  Related to the foreseen virtualized network infrastructure, coding techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This to a virtualized SATCOM terminals is the management of limited buffered equipments. <del> 4.3. </del>  In the context of the deep-space communications, establishing communications from terrestrial gateways to satellite platforms can

Reviewer comments:
This section deserves a small introduction where you explain that you discuss a few topics, without trying to be exhaustive. Section 5.1 Are PEP part of "Network Functions"? What's their position in the architecture of Fig. 1?I don't understand why the question on code rate to use is in a challenge called "increased deployability". I'd rather put it in a challenge on dynamic adaptation (which is not identified).
Corrected and answered in PR

Revised text:
SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2  <ins> and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus support use-cases that have been discussed in this document. </ins> Deploying coding schemes at the TCP level in these equipment could be relevant and independent from the specific characteristics of a  <ins> SATCOM link.  This leads to research question on the interaction between coding schemes and TCP congestion controls. </ins> 4.2. <ins> The recurrent trade-off in SATCOM systems remains: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? 4.3. </ins> Related to the foreseen virtualized network infrastructure, coding techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This to a virtualized SATCOM terminals is the management of limited buffered equipments.  <ins> 4.4. </ins> In the context of the deep-space communications, establishing communications from terrestrial gateways to satellite platforms can
Original text:
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>  1.

Reviewer comments:
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.

Revised text:
Abstract  <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.
Original text:
acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME <del> with additional information (e.g. related to synchronization); </del>  QEF: Quasi-Error-Free; VNF: Virtual Network Function.  2. This section describes the components in a satellite system based on 3. This section details use-cases where coding techniques could improve <del> the overall performance of a SATCOM system (e.g. considering a more </del>  efficient usage of the satellite resource, delivery delay, delivery ratio). This use-case is mostly relevant for when mobile users are considered or when the chosen band induce a required physical-layer coding that may change over time (Q/V bands, Ka band, etc.).  Depending on the <del> use-case (e.g. very high frequency bands, mobile users) or depending on the deployment use-cases (e.g. performance of the network between </del>  each individual block), the relevance of adding coding techniques is different.

Reviewer comments:
Introduction physical-layer reliability mechanisms -- hyphenate adjectival terms style: e.g. should be in a clause separated by commas, not brackets. 500 ms one-way delivery delay (or path -- i.e. not propagation)
Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. .
I think PR solves the issue.

Revised text:
acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME  <ins> with additional information (e.g., related to synchronization); </ins> QEF: Quasi-Error-Free; VNF: Virtual Network Function. <ins> This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. </ins> 2. This section describes the components in a satellite system based on 3. This section details use-cases where coding techniques could improve  <ins> the overall performance of a SATCOM system (e.g., considering a more </ins> efficient usage of the satellite resource, delivery delay, delivery ratio). This use-case is mostly relevant for when mobile users are considered or when the chosen band induce a required physical-layer coding that may change over time (Q/V bands, Ka band, etc.).  Depending on the  <ins> use-case (e.g., very high frequency bands, mobile users) or depending on the deployment use-cases (e.g., performance of the network between </ins> each individual block), the relevance of adding coding techniques is different.
Original text:
deployment in satellite systems. X1 embodies the source coding techniques that could be used at <del> application level for instance within QUIC or other video streaming applications.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </del>  X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited).

Reviewer comments:
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

Revised text:
deployment in satellite systems. X1 embodies the source coding techniques that could be used at  <ins> application level for instance within QUIC.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </ins> X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited).
Original text:
Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <del> FEC (also called Application-Level FEC) operate above the network layer. </del>  This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding

Reviewer comments:
Q (Dave Oran): in or above network layer (above means no re-encoding in the router)? A: both - and the document is clear about it - no layer 2 coding. Q (Stew Card): what are the "C" is the architecture picture? A: this is where we could put the coding.
Done with PR and

Revised text:
Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document.  <ins> FEC (also called Application-Level FEC) operate in and above the network layer. </ins> This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding
Original text:
document RFC8406: Channel and link codings are gathered in the PHY layer coding and <del> are out of the scope of this document. </del>  FEC (also called Application-Level FEC) operates in and above the network layer.

Reviewer comments:
I'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode, dealing with varying channel conditions (yet without using channel codings), etc. They're stated as out of scope...
If the intent is treating the overall end-to-end path as some sort of virtual 'channel' that coding packets are applied to, this needs to be said explicitly upfront. If 'channel' means more than one concatenated physical path here, this needs to be said. Unless your audience is only network coding people... the title should likely be 'network coding applicability to satellite-based scenarios' or similar, too. Needs to be really specific for clarity.
In PR , we have changed: "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." by "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. It focuses on situations where coding is not widely deployed in current SATCOM systems." For the comment on the end-to-end path, the notion of virtual 'channel' depends on the use-case and coding is not applied at the same level. For the title, we have moved from "Network coding and satellites" to "Coding techniques for satellite systems" from version 04 and 05 of the document to be more generic. I guess we should not go back to the "network coding"-like title.

Revised text:
document RFC8406: Channel and link codings are gathered in the PHY layer coding and  <ins> are out of the scope of this document.  It focuses on situations where coding is not widely deployed in current SATCOM systems. </ins> FEC (also called Application-Level FEC) operates in and above the network layer.
Original text:
4.1. <del> SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward </del>  TCP packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., <del> the quickly varying channel conditions use-case. </del>  4.3.

Reviewer comments:
section 4.1 - PEP is Enhancing, not Enhancement. PEPs usually split... section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well. ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist
Thanks for the nits on the PEP. For the comment on ACM, we have updated the text (PR ) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough." We have updated the conference in PR and PR

Revised text:
4.1.  <ins> SATCOM systems typically feature Performance Enhancing Proxy (PEP) RFC3135.  PEPs usually split TCP end-to-end connections and forward </ins> TCP packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g.,  <ins> the quickly varying channel conditions use-case where ACM may not be reacting quickly enough. </ins> 4.3.
Original text:
The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2.  The WTHEADERS frame has one extra field, Connect Stream ID. WTHEADERS frames can be sent on a stream in the "idle", "open", or "half-closed (remote)" state, see stream-states.

Reviewer comments:
As in the , We should document how we provide a unidirectional stream, likely by adding that as a parameter to the Connect stream.
Looking good! Few minor formatting nits, but nothing major.

Revised text:
The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2. <ins> The WTHEADERS frame has an additional flag, Unidirectional (0x40). When this flag is present, the stream starts in a half-closed state. The sending endpoint stream state is "half-closed (remote)" and the receiving endpoint state is "half-closed (local)". </ins> The WTHEADERS frame has one extra field, Connect Stream ID. WTHEADERS frames can be sent on a stream in the "idle", "open", or "half-closed (remote)" state, see stream-states.
Original text:
2. <del> WebTransport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3 correspondingly). </del>  When an HTTP/2 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to

Reviewer comments:
This might seem unfortunate, but it's how the protocol works. Update the link to point to HTTP spec instead.

Revised text:
2.  <ins> WebTransport servers are identified by an HTTPS URI as defined in Section 4.2.2 of HTTP. </ins> When an HTTP/2 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to
Original text:
3.2. <del> RFC8441 defines an extended CONNECT method in Section 4, enabled by </del>  the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint does not need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT In order to create a new WebTransport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) <del> MUST be set to "webtransport" (Section 7.1 WEBTRANSPORT-H3).  The </del>  ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided

Reviewer comments:
There was a local reference that was just typed out. The references to other documents cargo-culted from QUIC, but that only works if the documents are in the same repo. You have to pull references from the datatracker. Use the nice reference format in a few places.

Revised text:
3.2.  <ins> RFC8441 defines an extended CONNECT method in features, enabled by </ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint does not need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT In order to create a new WebTransport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441)  <ins> MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The </ins> ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided
Original text:
MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired <del> 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 server can check if it has a

Reviewer comments:
Two things: Say what the header contains Limit it to the Web And fix the xref formatting.

Revised text:
MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired  <ins> WebTransport server.  In a Web context, the request MUST include an "Origin" header field ORIGIN that includes the origin of the site that requested the creation of the session. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server can check if it has a