Change:
"This section describes the components in satellite system that layson SATCOM systems dedicated to broadband Internet access that follows the DVB standards" -- This section describes the components of a satellite system that follows the ETSI DVB standards to provide broadband internet access. (Actually, DVB-S standards). Following the DVB standards has effects on draft scope and terminology. Are you sure you want to do that? The current approach to DVB-S seems to be to pick and choose whatever is convenient to the argument. A high-level description of a multi-gateway satellite network is provided. "a bi-directional' - elide a, elide - Fig 1 doesn't resemble the multi-gateway DVB satellite systems that I have worked on. Indoor and outdoor unit typically refers to the customer satellite terminal pieces as well, not jut a piece of the gateway. (Indoor - network to/from intermediate frequency IF. Outdoor: IF to/from RF) The satellite link appears to be in the wrong place, or the terminal needs breaking down further. And there's no mention of FECFRAME? PLFRAME is the structure, the data gets turned into FECFRAME. But that has "FEC" in it and this draft aims to downplay FEC... awks. Encaps like GSE or MPE have been skipped, but that's really just added flavour.
Vincent : First sentence is not very clear (structure (that ... that...), missing "a" in "in statellite system that lays...", etc. Last sentence "Coding schemes could be applied on both single and aggregated traffic." deserves to be detailed. Will it be discussed later on in this document?
We have proposed some changes in PR . On the comment on following DVB standards : These documents let us have a common view of the different components of a SATCOM system. If you have any public pointer with other naming, we would be happy to have it to see if there are main issues with the actual naming in the document. On the comment on Fig 1, indoor and outdoor unit: We think we have clarified the usage of FEC in the document. The notion of physical gateway is not actually standardised, but the proposed figure let us explain the different use-cases. This is the main rational of this figure.

Discussion:
2. <del> This section describes the components in a satellite system based on SATCOM systems dedicated to broadband Internet access that follows the DVB standards.  A high-level description of a multi-gateway satellite network is provided.  There are multiple SATCOM systems, such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific.  In this context, the increase of the available capacity that is carried out to end users and reliability requirements lead to multiple gateways for one unique satellite platform. </del> <ins> This section describes a satellite system that follows the ETSI DVB standards to provide broadband Internet access.  A high-level description of a multi-gateway satellite network is provided.  There are multiple SATCOM systems, such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific.  In this context, the increase of the available capacity that is carried out to end users and reliability requirements lead to multiple gateways for one unique satellite platform. </ins> In this context, fig:sat_gateway shows an example of a multi-gateway satellite system.  In a multi-gateway system, some elements may be centralized and/or gathered: the relevance of one approach compared to another depends on the deployment scenario.  More information on these discussions and a generic SATCOM ground segment architecture <del> for a bi-directional Internet access can be found in SAT2017. </del> <ins> for bidirectional Internet access can be found in SAT2017. </ins> Some functional blocks aggregate the traffic of multiple users. <del> Coding techniques could be applied on both single and aggregated traffic. </del> 3.