Change:
already congested networks.  The coding ratio needs to be carefully designed. <del> 7. </del> <ins> 4. </ins> This memo includes no request to IANA. <del> 8. </del> <ins> 5. FEC and CC schemes can contribute to DoS attacks.  This is not specific to this document. </ins> <del> There is no security considerations required for this document. </del> <ins> More information TBD. </ins>

Discussion:
Never say what follows: There is no security considerations required for this document. There are security considerations in most documents, because it does change something (which is fortunate) and therefore it can introduce threats. Here CC and FEC coding rate could be leveraged to create DoS. Although it's not specific to this document, saying the opposite is not appropriate.
Done in PR
I appreciate to see these three sections, but I think they should be grouped as subsections of a single one entitled: "Recommendations depending on the CC versus FEC layering" or something like that. And adding a small introduction text would be fine too. There's really an ambiguity about what is coded data: does it include source data packets or not? And why data rather than packets? Have a look at our terminology RFC and stick with it. I do not agree about the following wording: The drawback of this approach is that it is useless if the transport guarantees data delivery by retransmitting packets. This is only a drawback if one is stupid enough to do FEC protection on top of a reliable transport protocol. I'd rather say: Of course, this approach requires that that the transport protocol does not include a reliability (e.g., based on lost packet retransmition). This approach is perfectly fine with UDP which is pretty usual. This is suggested in the figure ("sending rate or window"), but not detailed in text. There is preferably a feedback between CC and FEC entities.
Covered in PR
Section 3.1 is pretty concise. What type of "transmission"? In intro you say that tunnels are out of scope, which should be clarified and justified here. Do you restrict yourself to transport protocols (where CC is usually found)? Do you want to extend to application protocols as well (with the difficulty of defining what is an application protocol, since we see more and more protocols on top of UDP). Do you consider multipaths? Do you keep multicast as out of scope as there is a dedicated CC that is pretty different? A new idea is introduced here, that of "fairness with non-coding solutions". It should prominently mentioned in abstract and introduction as well. I'm surprised to see "Section 3.3. Objective of the document" at this moment in the document.

Please put it before. The first two sentences about mixing the CC and FEC channels should also be moved at the end of section 2, it does not belong to the objectives.
About fairness: I'd rather say that this only concerns the case in section 6, FEC below the transport, and should be discussed only there.
This section may not be relevant if we move all the discussions of the scope in the Introduction. This is what has been done in PR
Mention of fairness has been removed and the present focus of the draft is unicast single path transfer.
A detail: arrows are missing in fig. 1. Or perhaps it is indicated by the use of { and }, but in that case it's not very clear. Using plural is also preferable. A detail: there is no "coded data" but "coded packets".It is said: "signaling from the receiver about losses and/or repaired blocks" The use of "blocks" here is erroneous, we talk about packets. I'd also suggest that you change the mention "information about repaired ratio" in fig. 2 by what you say here, in the text. What exact information is given back to the FEC entity really depends on the use-case, but I like the way it's written in the text: it's some information about what is lost and what is recovered thanks to FEC coding. It is said: However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, There is no horizontal double arrow! And I cannot really decide whether entities refer to client/server or CC/FEC. typo: potiential => potential
Thanks. Updated in PR
Minor comment: It is said (2nd sentence): ... for the server to detect tail losses... Make it clear that in this document, the server sends data. Ambiguous: One objective is to help the research community consider congestion control aspects when proposing and comparing coding solutions. I'd rather say: Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. Rationals: this is another objective; comparing FEC Schemes without considering congestion control makes sense if the goal is to compare those schemes only.
Thanks.

This is covered in PR
I do not understand: This document can help the comparison of FEC schemes by identifying at which level they are operating with respect to the transport congestion control. What does "the comparison of FEC schemes" refer to? Between one another? I guess this is not the intent (and this is explained later on). Global comment, title including: using "coding" without any further information, is ambiguous. I'd prefer FEC coding or erasure correction coding, at least in the abstract/introduction.
The intent is indeed to help the comparison of different FEC schemes. There are cases where a FEC scheme A hide losses to a congestion control, while a FEC scheme B do not. Comparing A and B is not fair. The comment on using "coding" is dealt with in PR