Change:
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

Discussion:
<del> Network coding and satellites </del> <ins> Coding techniques for satellite systems </ins> draft-irtf-nwcrg-network-coding-satellites-05 Abstract This memo details a multi-gateway satellite system to identify <del> multiple opportunities on how network coding techniques could be deployed at a wider scale. </del> <ins> multiple opportunities on how coding techniques could be deployed at a wider scale. </ins> 1.

transmission losses within a negligible delay compared to link delay. However, when retransmissions are triggered, this leads to an non- negligible additional delay in particular over GEO link.  Further <del> exploiting coding schemes at application or transport layers is an </del> <ins> exploiting coding techniques at application or transport layers is an </ins> opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. The notations used in this document are based on the taxonomy <del> document RFC8406: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SPC) and Multi-Path Coding (MPC).  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.  This document considers FEC as coding mechanisms above the network layer only. </del> <ins> document RFC8406: Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. FEC (also called Application-Level FEC) operate above the network layer. This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding (e.g., to compress a video flow). </ins> fig:existing_network presents the status of the reliability schemes deployment in satellite systems. <del> X1 embodies the source coding that could be used at 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> <ins> X1 embodies the source coding techniques that could be used at 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. </ins> <del> X2 embodies the physical-layer to optimize the satellite capacity usage.  At the physical layer, other coding mechanisms can be exploited. </del> <ins> X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited). This is out of the scope of the document. </ins> <del> 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. </del> <ins> We notice an active research activity on coding techniques 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> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows:

for a bi-directional Internet access can be found in SAT2017. Some functional blocks aggregate the traffic of multiple users. <del> Coding schemes could be applied on both single and aggregated </del> <ins> Coding techniques could be applied on both single and aggregated </ins> traffic. 3. <del> This section details use-cases where coding schemes could improve the overall performance of a SATCOM system (e.g. considering a more </del> <ins> This section details use-cases where coding techniques could improve the overall performance of a SATCOM system (e.g. considering a more </ins> efficient usage of the satellite resource, delivery delay, delivery ratio).

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

may change over time (Q/V bands, Ka band, etc.).  Depending on the 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 is different. </del> <ins> each individual block), the relevance of adding coding techniques is different. </ins> 3.5.

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 mechanisms and </del> <ins> and layer-1 encapsulations.  PEP could host coding techniques and </ins> thus support the use-cases that have been discussed in this document. Deploying coding schemes at the TCP level in these equipment could be

4.2. Related to the foreseen virtualized network infrastructure, coding <del> schemes could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This trend can also be seen in cellular networks, making these discussions </del> <ins> techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This trend can also be seen in cellular networks, making these discussions </ins> extendable to other deployment scenarios I-D.chin-nfvrg-cloud-5g- core-structure-yang.  As one example, the coding VNF functions deployment in a virtualized environment is presented in I-D.vazquez-

proposed in subsec:varying would legitimize the usage of coding within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding <del> inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in CCSDS-131.5-O-1.  A research challenge would be on how such coding can be integrated in the IETF DTN stack. </del> <ins> techniques inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in CCSDS-131.5-O-1.  A research challenge would be on how such coding can be integrated in the IETF DTN stack. </ins> 5.