Original text:
1.  Guaranteeing both physical-layer robustness and efficient usage of the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems.  The trade-off often resided in how developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. <del> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: ACM : Adaptive Coding and Modulation; BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is encapsulated with a Generic Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; CPE: Customer Premises Equipment; COM: COMmunication; DSL: Digital Subscriber Line; DTN: Delay/Disruption Tolerant Network; DVB: Digital Video Broadcasting; E2E: End-to-end; ETSI: European Telecommunications Standards Institute; FEC: Forward Error Correction; FLUTE: File Delivery over Unidirectional Transport; IntraF: Intra-Flow Coding; InterF: Inter-Flow Coding; IoT: Internet of Things; LTE: Long Term Evolution; MPC: Multi-Path Coding; NC: Network Coding; NFV: Network Function Virtualization; NORM: NACK-Oriented Reliable Multicast; PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for satellite communications include compression, caching and TCP acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with additional information (e.g., related to synchronization); QEF: Quasi-Error-Free; QoE: Quality-of-Experience; QoS: Quality-of-Service; SAT: SATellite; SATCOM: generic term related to all kind of SATellite COMmunication systems; SPC: Single-Path Coding; VNF: Virtual Network Function. 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. </del> 2. This section describes a satellite system that follows the ETSI DVB 6. <del> This memo includes no request to IANA. </del>  7.  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

Reviewer comments:
Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front?
In PR : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction.

Revised text:
1. <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.  A glossary is proposed in sec:glossary. </ins> Guaranteeing both physical-layer robustness and efficient usage of the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems.  The trade-off often resided in how developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems.  2. This section describes a satellite system that follows the ETSI DVB 6.  <ins> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: ACM : Adaptive Coding and Modulation; BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is encapsulated with a Generic Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; CPE: Customer Premises Equipment; COM: COMmunication; DSL: Digital Subscriber Line; DTN: Delay/Disruption Tolerant Network; DVB: Digital Video Broadcasting; E2E: End-to-end; ETSI: European Telecommunications Standards Institute; FEC: Forward Error Correction; FLUTE: File Delivery over Unidirectional Transport; IntraF: Intra-Flow Coding; InterF: Inter-Flow Coding; IoT: Internet of Things; LTE: Long Term Evolution; MPC: Multi-Path Coding; NC: Network Coding; NFV: Network Function Virtualization; NORM: NACK-Oriented Reliable Multicast; PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for satellite communications include compression, caching and TCP acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with additional information (e.g., related to synchronization); QEF: Quasi-Error-Free; QoE: Quality-of-Experience; QoS: Quality-of-Service; SAT: SATellite; SATCOM: generic term related to all kind of SATellite COMmunication systems; SPC: Single-Path Coding; VNF: Virtual Network Function. </ins> 7. <ins> This memo includes no request to IANA. 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