* Glossary: FEC defined as an **error** correction technic is misleading in the present document.

* Introduction: A better wording should be feasible for the following sentence:
	"...how much redundancy a system adds to cope with link impairments, without reducing the goodput when the channel quality is good."
  There's necessarily a goodput reduction in good transmission situations.

  The rest of this paragraph is a bit confusing for me. It mentions "physical or link
  layer erasure coding mechanisms" that are (1) out of scope (see abstract) and (2) erroneous
  (it's more probably **error** coding). The sentence:
	"The recovery time depends on the encoding block size."
  is imprecise (add in case of block codes) and confusing ("ça tombe comme un cheveu sur la soupe",
  I don't know the English translation...). If I understand correctly the point, you mean that PHY and
  LL coding protection is usually sufficient to guarranty QEF, with a negligeable delay compared to
  propagation time (e.g., with a GEO sat), but when it fails retransmissions add significant delays,
  hence the use of FEC in upper layers. You'd better say that in this order IMO.

  Later, what does "It" refer to in sentence "It focuses on situations where...". It's not clear to me.

* Fig. 1 introduces context not mentioned so far. I don't know how to fix it. 

* Section 3.1: last sentence is confusing. Do you suggest that on-board coding is not the prefered solution?
  Say that directly. And what does "payloads" mean in: "With On-Board Processing satellite payloads,..."?
  Do you mean "facility"?

* Section 3.2: last sentence, "the RFC proposes a bidirectional communication method to enable ...".
  Which RFC? I think it's sufficient to say that a bidirectional feature could be useful for additional services
  such as full reliability, feedback and coding rate adaptation, security, etc.

* Section 3.3: The first sentence makes several claims but does not provide references to support them
  (I'd also add "(using multiple paths, **per se,** does not...)").

* Section 3.5: second paragraph suggests that adapting coding/modulation in less than a second is feasible.
  Even with a GEO link? And there's a contradiction between saying that a realtime adaptation is feasible
  but it's no longer QEF. A better wording is preferable.
  And I don't know all details, but I have the feeling that ACM is common to all users of the satellite
  beam, whereas with mobile users we are considering individual users. There's also something unclear to me
  here, but perhaps I'm wrong.

* Section 4.1: I don't understand the challenge here. The title suggests something very generic, while
  the last paragraph restricts it to TCP. It's confusing.
  BTW, is the final "s" in "TCP congestion controls" meaningful? Does it depend on which CC algorithm is
  precisely used? Say that clearly if this is what is meant, and update the title accordingly.


typos:

* Abstract: "control" without any final "s" in "between congestion controls and..."
* Intro: add "-" in "Quasi-Error Free"
* Fig. 2: add a ")" in the upper box.
* 4.1: remove final "s" in "in a SATCOM systems."
* 4.2: I think you mean "should" instead of "could" in:
	"At which layer this supplementary coding could be added ?"
* 45.4: what is a "contemporaneous E2E connectivity"?
* Glossary, SATCOM def: add a final "s" in "all kinds"