If the recovery is done by the receiver using FEC, it is suggested not to retransmission the packets at the sender. If the lost packets are repair symbol, the sender should not retransmission it. I think we should add such suggestion in the text, what do you think?

How to associate the source symbol with repair symbol? Is it in the repair symbol payload which is implementation based? Do you think we should define it clearly in the draft?

There're 2 usages of QUIC FEC. One is for flows of RTC applications which is this draft mainly for; another, which in our case, is to protect short messages in some scenarios where BDP is large and applications are delay sensitive, e.g., instant messaging, control channels for multimedia conferencing.
In the latter case, short message FEC mechanism uses FEC to produce multiple FEC packets together sent with original packets instead of sending multiple duplicate packets. It would be useful to include texts to prove the current approach can suppport both scenarios. We can help to add some texts if necessary:)

FEC redundancy can be dynamically adjusted during transmission based on network conditions, e.g., loss rate. To support this, FEC redundancy can be periodically sent by the sender. There are maybe 2 ways to do this, either encoded in the FEC repair symbol or together with FEC_window.

Alternative 1 is more like a nesting frame, it may add some cost when supporting in an existing QUIC implementation. Would it be more simple to use alternative 2? what do you mean "the SID frame is not idempotent"?