Change:
including CC): refers to the rate at which a congestion control decides to transmit packets, based on 'network information'. <del> 'signaling about losses and/or repaired packets' (input control plane for the FEC): refers to the information a FEC sender can obtain from a FEC receiver about the performance of the FEC solution as seen from the receiver. </del> <ins> 'signaling repaired packets' (input control plane for the FEC): refers to the information a FEC sender can obtain from a FEC receiver about the performance of the FEC solution as seen from the receiver. </ins> 'coding rate' (output control plane for the FEC): refers to the coding rate that is used by the FEC solution.

Discussion:
Looks good to me !
I see a major scoping problem in these sections. What does this document really aim at? It is said earlier: This document discusses how FEC and CC relate. Here we see architectural discussions on advantages/drawbacks instead. There is also the additional idea of how it relates to transport reliability mechanism which is (in theory) out of scope. I'd like to see more info about what concretely can be done (examples). The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting. I also think the application (as data source) is potentially involved in the big picture: an application generating a real-time data flow is not the same as an application generating background traffic. In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions. It means that without adapting the data flow there is probably no solution. In the second case (which includes François's experiments with tail losses)
item 1: I think this is now addressed by careful phrasing in the para that mentions reliability, in PR . Item 2: I agree but I'd greatly prefer if we could postpone this to the next version. I think we should include multipath considerations too, so this will be quite a bit of work. Item 3: I agree... someone should write something :)
Item 1 addressed by PR Open for next submission I'd like to see more info about what concretely can be done (examples). The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting. I also think the application (as data source) is potentially involved in the big picture: an application generating a real-time data flow is not the same as an application generating background traffic. In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions. It means that without adapting the data flow there is probably no solution. In the second case (which includes François's experiments with tail losses)
I am not sure I completely get the last item though. More specifically, I don't know what to say about this in this draft about the relations between coding and the congestion control.

We could state that the application can provide information about importance or deadline concerning its data, but I think the optimal FEC pattern , with or without congestion, will likely depend on the application's requirements in the end ? Does anybody have a clearer idea on what we could state on this ? Let's discuss this here before writing ?
I think you're trying to find a solution, whereas we're only describing a situation. The latter is simpler: we can basically repeat what Vincent has told us: "an application generating a real-time data flow is not the same as an application generating background traffic. In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions. It means that without adapting the data flow there is probably no solution." Just point it out.
Looks good to me. Thank you !
The application requirements aspect have been covered by PR
The current version of hte draft seems to go for a more "server" side discussion. We should not forget to speak about the client.
I agree - but maybe delay this until the next version of the draft?
I have pushed some content with some more details on the server side solutions. I think we may be soon ready to either submit this version or had a small section on the receiver side. It can be very simple IMHO: " The receiver must not use CC channel signals to acknowledge the recovery of data packets with the coding schemes. The information on recovered packets must be reported on the FEC channel."
I agree with both approaches. I'd vote for shipping it as-is (better to have a more useful discussion on the receiver side - surely we can come up with something more for the next version of the draft?)
Thanks for the feedback - I would vote the same. Any other thoughts ?
This is done in PR
LGTM modulo a minor suggestion, but that was from a quick glance only... can't dedicate more time this round, sorry!