S 1 Introduction p 2 "link layers" -> "link layer"
S 1 Introduction p 3 "an non-negligible" -> "a non-negligible"
S 1 Introduction p 3 "FEC... operate" -> "FEC... operates"
S 1 Introduction p 3 "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document... considers coding... as a linear combination and not as a content coding" don't we want to use the standard terms "channel coding" and "source coding" as in RFC 8406 section 3? also do we want to restrict solution approaches in the Abstract and Introduction of what appears to be a problem space overview?
S 1 Introduction p 3 Figure 1 E2E, NC, IntraF, InterF, SPC, MPC abbrevations/acronyms neither spelled out on first use (as they were in earlier versions of this draft), included in this draft's glossary, nor defined in RFC 8406
S 1 Introduction p 4 "PEP... include" -> "PEP... including"
S 2 A note on satellite topology p 5 acronyms DVB etc. not spelled out on first use etc.
S 2 A note... p 6 Figure 2 seems to cover only the case where a single [simple] user device is connected by the satellite terminal (leaves out e.g. firewall/router on user end of satellite link); if this is intentional just to avoid unnecessary complication of the figure, a note explaining this would be in order
S 3.1 Two-way channel mode p 7 "computationnal" -> "computational"
S 3.2 Reliable multicast p 8 NORM does not require a feedback link, although it benefits significantly from one, and a single receiver with a feedback link can NACK on behalf of all receivers for all commonly experienced impairments; also "for security purpose" -> "for security purposes" or "for a security purpose"
S 3.1 & S 3.2 Do we want to consider more general multi-source multi-sink multicast topologies than the base case in 3.1, or combinations of 3.1 & 3.2?
S 3.3 Hybrid access p 9 "transport level" -> "transport layer", "using multiple path does not" -> "using multiple paths does not", "appart" -> "apart", "envisionned" -> "envisioned"
S 3.4 Dealing with LAN losses p 9 "cope from" -> "cope with"
S 3.4 Dealing with LAN losses p 10 Figure 6 is confusing: it omits explicitly showing the WiLAN; it uses an undefined label "C" (presumably indicating something relating to encryption, but why would that end at the Access Gateway?)
S 3.5 Dealing with varying channel conditions p 10 "cope from" -> "cope with"
S 3.5 Dealing with varying... p 10 "physical-layer codes could not guarantee" -> "physical-layer codes could not efficiently guarantee" as heavy FEC could be used always even when channel conditions are good
S 3.5 Dealing with varying... p 10 "mechanisms that is" -> "mechanisms that are", "higher layers redundancy" -> "higher layer redundancy", "chosen band induce a required" -> "chosen band induces a required" or "chosen band requires a"
S 3.5 Dealing with varying... p 10 discussion of use cases and deployment use cases is confusing
S 3.5 Dealing with varying... p 10 Figure 7 again uses undefined label "C"
S 3.6 Improving the gateway handovers p 11 "The control plane manager is in charge of taking the decision to change the communication gateway and the consequent routes." There may not always be an explicit control plane manager.
S 4 Research challenges p 11 "This section proposes to discuss few research challenges related to the introduction and the use of..." Do we mean "This section identifies a few research challenges related to the introduction and the use of..." or "This section proposes a few potential approaches to introduce and use..."?
S 4.1 On the joint-use of coding techniques and congestion control in SATCOM systems p 12 transparent transport layer PEPs are increasingly difficult to insert due to TLS; the NORM Proxy (NORP) might deserve a mention here; also "leads to research question" -> "leads to research questions"
S 4.2 On the efficient usage of satellite ressource p 12 HARQ / incremental redundancy ARQ / adaptive FEC might deserve a mention here; also "ressource" -> "resource"
S 4.3 Interaction with virtualized satellite gateways and terminals p 12 "VNF functions deployment" -> "VNF deployment", "an efficient radio usage" -> "efficient radio usage", "a virtualized SATCOM terminals" -> "virtualized SATCOM equipment", "limited buffered equipments" -> "limited buffer capacities"
S 4.4 Delay/Disruption Tolerant Networks p 12 "In the context of deep-space communications, establishing communications from terrestrial gateways to satellite platforms" -> "Communications among deep-space platforms and terrestrial gateways"
S 4.4 DTN p 12-13 "such links" -> "such paths"; "disruptions." -> "disruptions; indeed, contemporaneous E2E connectivity may be available only intermittently or never."?
S 4.4 DTN p 13 dtnrg members have been experimenting with NORM as a DTN Bundle Protocol convergence layer (bundle transport protocol for an E2E Internet path comprising a single hop in a DTN)
NicoKos
commented
5 years ago
Abstract p 1 "cope from" -> "cope with"
S 1 Introduction p 2 "cope from" -> "cope with"
S 1 Introduction p 2 "link layers" -> "link layer"
S 1 Introduction p 3 "an non-negligible" -> "a non-negligible"
S 1 Introduction p 3 "FEC... operate" -> "FEC... operates"
S 1 Introduction p 3 Figure 1 E2E, NC, IntraF, InterF, SPC, MPC abbrevations/acronyms neither spelled out on first use (as they were in earlier versions of this draft), included in this draft's glossary, nor defined in RFC 8406
S 1 Introduction p 4 "PEP... include" -> "PEP... including"
S 2 A note on satellite topology p 5 acronyms DVB etc. not spelled out on first use etc.
S 2 A note... p 6 Figure 2 seems to cover only the case where a single [simple] user device is connected by the satellite terminal (leaves out e.g. firewall/router on user end of satellite link); if this is intentional just to avoid unnecessary complication of the figure, a note explaining this would be in order
S 3.1 Two-way channel mode p 7 "computationnal" -> "computational"
S 3.2 Reliable multicast p 8 NORM does not require a feedback link, although it benefits significantly from one, and a single receiver with a feedback link can NACK on behalf of all receivers for all commonly experienced impairments; also "for security purpose" -> "for security purposes" or "for a security purpose"
S 3.1 & S 3.2 Do we want to consider more general multi-source multi-sink multicast topologies than the base case in 3.1, or combinations of 3.1 & 3.2?
S 3.3 Hybrid access p 9 "transport level" -> "transport layer", "using multiple path does not" -> "using multiple paths does not", "appart" -> "apart", "envisionned" -> "envisioned"
S 3.4 Dealing with LAN losses p 9 "cope from" -> "cope with"
S 3.4 Dealing with LAN losses p 10 Figure 6 is confusing: it omits explicitly showing the WiLAN; it uses an undefined label "C" (presumably indicating something relating to encryption, but why would that end at the Access Gateway?)
S 3.5 Dealing with varying channel conditions p 10 "cope from" -> "cope with"
S 3.5 Dealing with varying... p 10 "mechanisms that is" -> "mechanisms that are", "higher layers redundancy" -> "higher layer redundancy", "chosen band induce a required" -> "chosen band induces a required" or "chosen band requires a"
S 3.5 Dealing with varying... p 10 discussion of use cases and deployment use cases is confusing
S 3.5 Dealing with varying... p 10 Figure 7 again uses undefined label "C"
S 3.6 Improving the gateway handovers p 11 "The control plane manager is in charge of taking the decision to change the communication gateway and the consequent routes." There may not always be an explicit control plane manager.
S 4 Research challenges p 11 "This section proposes to discuss few research challenges related to the introduction and the use of..." Do we mean "This section identifies a few research challenges related to the introduction and the use of..." or "This section proposes a few potential approaches to introduce and use..."?
S 4.1 On the joint-use of coding techniques and congestion control in SATCOM systems p 12 transparent transport layer PEPs are increasingly difficult to insert due to TLS; the NORM Proxy (NORP) might deserve a mention here; also "leads to research question" -> "leads to research questions"
S 4.2 On the efficient usage of satellite ressource p 12 HARQ / incremental redundancy ARQ / adaptive FEC might deserve a mention here; also "ressource" -> "resource"
S 4.3 Interaction with virtualized satellite gateways and terminals p 12 "VNF functions deployment" -> "VNF deployment", "an efficient radio usage" -> "efficient radio usage", "a virtualized SATCOM terminals" -> "virtualized SATCOM equipment", "limited buffered equipments" -> "limited buffer capacities"
S 4.4 Delay/Disruption Tolerant Networks p 12 "In the context of deep-space communications, establishing communications from terrestrial gateways to satellite platforms" -> "Communications among deep-space platforms and terrestrial gateways"
S 4.4 DTN p 12-13 "such links" -> "such paths"; "disruptions." -> "disruptions; indeed, contemporaneous E2E connectivity may be available only intermittently or never."?
S 4.4 DTN p 13 dtnrg members have been experimenting with NORM as a DTN Bundle Protocol convergence layer (bundle transport protocol for an E2E Internet path comprising a single hop in a DTN)
5 Conclusion p 13 "'network function' block gather" -> "'network function' block gathers"
8 Security Considerations p 14 "togething" -> "together"