Original text:
2.1. fig:sep-channel presents the notations that will be used in this <del> document and introduces the Congestion Control (CC) and Forward Erasure Correction (FEC) channels.  The Congestion Control channel carries source packets from a sender to a receiver, and packets signaling information about the network (number of packets received vs. lost, Explicit Congestion Notification (ECN) marks, etc.) from the receiver to the sender.  The Forward Erasure Correction channel carries repair symbols (from the sender to the receiver) and </del>  information from the receiver to the sender (e.g. signaling which packets have been repaired, loss rate prior and/or after decoding, <del> etc.). </del>  Inside a host, the CC and FEC entities can be regarded as conceptually separate: coding rate that is used by the FEC solution (i.e.  proportion of transmitted symbols that carry useful data). <del> 'source and/or repair symbols' (data plane for both the FEC and the CC): refers to the data that is transmitted.  The sender can decide to send source symbols only (meaning that the coding rate is 0), repair symbols only (if the solution decides not to send the original source packets) or a mix of both. </del>  The inputs to FEC (incoming data packets without repair symbols, and signaling from the receiver about losses and/or repaired symbols) are 2.3. The application layer may be composed of several streams above FEC <del> and transport layers instances.  The different streams could exploit different paths between the sender and the receiver or not.  The document considers one application layer stream as input packets above a combination of FEC and transport layers.  In fig:multi-scope, each of stream 1 and stream 2 are considered in the scope of the document but a combination of stream 1 and stream 2 is not.  The case of multiple application level streams above multiple FEC and transport layers instances is out of the scope of the document and not further described. </del>  2.4. be envisioned. Full reliability: The receiver may hold symbols until the decoding <del> of source packets is possible.  In particular, if the codec does not enable a subset of the linear system to be inverted, the receiver would have to wait for a certain minimum amount of repair packets before it can recover all the source packets. Partial reliability: The receiver cannot deliver source packets that could not have been decoded to the upper layer.  If the size of the encoding window (for Sliding Window Coding) and the size of the blocks (for Block Coding) are large, the chances of recovering the erased symbols would increase.  However, this would impact on memory requirements and the cost of encoding and decoding processes. </del>  2.5. services. This approach requires that the transport protocol does not implement <del> a fully reliable data transfer service (e.g., based on lost packet retransmission).  QUIC with unreliable datagram extension I-D.ietf- quic-datagram is an example of a protocol for which this is relevant. In cases where QUIC traffic is blocked and a fall-back to TCP is proposed, there is a risk for bad interactions between TCP's full reliability and coding schemes.  For reliable transfers, coding usage does not guarantee better performance; instead, it would mainly reduce goodput. </del>  3.1. 3.2. <del> The congestion control mechanism may not be able to differentiate repair symbols from actual source packets.  The relevance of adding coding at the application layer is related to the needs of the application.  For real-time applications using an unreliable or partially reliable transport, this approach may reduce the number of losses perceived by the application. </del>  3.3. 4.6. <del> The application may require partial reliability.  In this case, the transport and FEC mechanisms could be conjointly designed.  As one example, the reliability offered by FEC may be sufficient, with no retransmission required.  This depends on application needs and the trade-off between latency and loss.  Partial reliability impacts the type of FEC and type of codec that can be used, such as discussed in subsec:def_code. </del>  4.7.

Reviewer comments:
I think this PR solves most of the issues that have been raised (and will close them if we merge this PR). What do you think NAME NAME NAME ?
I'm ok with whatever all others decide :)
In section 4.6: With coding, you can recover packets a-priori and a-posteriori, so I do not see any conjoint design between coding and the transport layer: if you replace the retransission mechanism by coding, you are more general as you can also recover packets a-priori and coding can offer full reliability if needed or partial reliability if the full reliability is not necessary. So I do not see any need of a conjoint design here: simply replace the retransmission-based reliability mechanism by the coding-based one. I do not really understand what we are trying to say here talking about a conjoint design. What do you think ?
I don't get it either... could we just remove this?
Commit URL in PR could solve it all.
It is a bit complicated for me to understand correctly the details of Figure 6 : In my opinion, the app does not sublit packets nor a sending rate to the transport layer, so the two arrows above the sender seem a bit weird for me. The app generally submits data, sometimes messages and maybe a minimal transmission rate but it is the transport layer that packetizes the data and sends packets. I guess that the arriws between the sender and the receiver are the wire or the layers below transport. Thus I would replace "source and/or repair packets" by "packets containing source and/or repair symbols" Did I misunderstand the Figure ?
I agree; I think the "sending rate" arrow can be removed (I'd say that the rate is at least implicit, in how fast the application gives data to the stack, but this just complicates matters - no need for this arrow anyway). I also think that "source packets" could just be "data" (next to the arrows on the top). This applies to figure 5 too ("source packets" can be replaced with "data" next to these arrows), and in figure 3, in the top left corner, the arrow could also be called "data" instead of "source packets".
There have been some changes due to the issue - I proposed a commit URL and commit URL in pr to clarify the unnecessary arrow.
In section 3, we can read the following: I would emphasize on en in-order delivery which is the real problem for FEC here, as a reliable messaging system without in-order delivery would work. I would thus replace the parenthesis by the following:
I agree but I'd use a different replacement: I think it's good to point out that this is about reliability from something different than coding, and the in-order issue is more than just a refinement in the bracket. So, I would suggest the following: a fully reliable in-order data transfer service (e.g., like TCP).
Dealt with in commit URL of PR
In section 2.4, we say the following: Either I misunderstood the statement or the sentence is not true. In my opinion, with an equal number of sent repair symbols, if the window/block size is larger, the recovery probability is lower as they are likely more lost source symbols in the window/blocks (with a fixed number of repair symbols).
Could be clarified by commit URL of PR
In section 2.4 : Why are we talking about a linear system here ? To be more general on the recovery algorithms that are used, maybe should we use the term "block or window" instead of "linear system" What do you think ?
The commit URL of PR makes it more general.
I am not totally sure of the meaning of section 2.3 and Figure 4. More specifically: are we saying that multiple data streams transiting through one single protocol instance are out of the scope of the document ? Do we consider only one single stream on one single protocol instance ? If this is the case, does that mean that we do not consider QUIC's use-case ? What makes me think all of this is the following sentence:
I hope PR and in particular commit URL clarifies everything
In section This is an echo from a previous issue that was not really addressed or "resolved". I will rephrase the problem from scratch and let me know if you agree with me or not. :-) We describe the FEC channel (maybe should we call it the Coding channel as repair symbols could also be sent a-posteriori) and say that it carries repair symbols while the CC channel carries source packets. What do you think of rephrasing it like the following: "The CC channel carries network packets and the coding channel carries source symbols and repair symbols" ? source symbols are an abstract view on the application (and sometimes control) data that we want to protect. For example, several source symbols could be present in a single network packet, or several network packets could form one single source symbol. This is why network packets can be very different than source symbols. This also goes in our vision that CC and NC are separated channels and separated entities: they do not even share the concept of packets. What do you think ?
I agree there was some confusion here. I tried to solve this in commit URL of PR
Thank you for this great PR. Only one comment, otherwise this is good for me !

Revised text:
2.1. fig:sep-channel presents the notations that will be used in this  <ins> document and introduces the Forward Erasure Correction (FEC) and Congestion Control (CC) channels.  The Forward Erasure Correction channel carries repair symbols (from the sender to the receiver) and </ins> information from the receiver to the sender (e.g. signaling which packets have been repaired, loss rate prior and/or after decoding,  <ins> etc.).  The Congestion Control channel carries network packets from a sender to a receiver, and packets signaling information about the network (number of packets received vs. lost, Explicit Congestion Notification (ECN) marks, etc.) from the receiver to the sender.  The network packets that are sent by the Congestion Control channel may be composed of source packets and/or repair symbols. </ins> Inside a host, the CC and FEC entities can be regarded as conceptually separate: coding rate that is used by the FEC solution (i.e.  proportion of transmitted symbols that carry useful data).  <ins> 'network packets' (output data plane for the CC): refers to the data that is transmitted by a CC sender to a CC receiver.  The network packets may contain source and/or repair symbols. 'source and/or repair symbols' (data plane for the FEC): refers to the data that is transmitted by a FEC sender to a FEC receiver. The sender can decide to send source symbols only (meaning that the coding rate is 0), repair symbols only (if the solution decides not to send the original source symbols) or a mix of both. </ins> The inputs to FEC (incoming data packets without repair symbols, and signaling from the receiver about losses and/or repaired symbols) are 2.3. The application layer may be composed of several streams above FEC  <ins> and transport layers instances.  The transport layer may exploit a multipath mechanism.  The different streams could exploit different paths between the sender and the receiver or not.  This section describes what is in the scope of this document in regards with multi-streams applications and multipath transport protocols. The different combinations between multi-stream applications and multipath transport are the following: (1) one application layer stream as input packets above a combination of FEC and multipath (Mpath) transport layers (fig:multi-scope-single-stream), and (2) multiple application layer streams as input packets above a combination of FEC and multipath (Mpath) or single path (Spath) transport layers (fig:multi-scope-multi-stream).  In fig:multi-scope- single-stream, each of stream 1 and stream 2 are considered in the scope of the document.  In fig:multi-scope-multi-stream, the case with single path transport is considered in the scope of this document but the cases with mutipath transport is not.  The case of multiple application level streams above multiple transport layers instances is out of the scope of the document and not further described. </ins> 2.4. be envisioned. Full reliability: The receiver may hold symbols until the decoding  <ins> of source symbols is possible.  In particular, if the codec does not enable a subset of the system to be inverted, the receiver would have to wait for a certain minimum amount of repair packets before it can recover all the source symbols. Partial reliability: The receiver cannot deliver source symbols that could not have been decoded to the upper layer.  For a fixed size of encoding window (for Sliding Window Coding) or of blocks (for Block Coding) containing the source symbols, increasing the amount of repair symbols would increase the chances of recovering the erased symbols.  However, this would impact on memory requirements, on the cost of encoding and decoding processes and on the network overhead. </ins> 2.5. services. This approach requires that the transport protocol does not implement  <ins> a fully reliable in-order data transfer service (e.g., like TCP). QUIC with unreliable datagram extension I-D.ietf-quic-datagram is an example of a protocol for which this is relevant.  In cases where QUIC traffic is blocked and a fall-back to TCP is proposed, there is a risk for bad interactions between TCP's full reliability and coding schemes.  For reliable transfers, coding usage does not guarantee better performance; instead, it would mainly reduce goodput. </ins> 3.1. 3.2.  <ins> The congestion control mechanism receives network packets and may not be able to differentiate repair symbols from actual source ones.  The relevance of adding coding at the application layer is related to the needs of the application.  For real-time applications using an unreliable or partially reliable transport, this approach may reduce the number of losses perceived by the application. </ins> 3.3. 4.6.  <ins> The application may require partial reliability.  The reliability offered by FEC may be sufficient, with no retransmission required. This depends on application needs and the trade-off between latency and loss.  Partial reliability impacts the type of FEC and type of codec that can be used, such as discussed in subsec:def_code. </ins> 4.7.