Change:
There are some RTP related extensions that need special consideration to be used by a relay when using the double transform due to the end- to-end protection of the RTP.  The repair mechanism, when used with <del> double, typically operate on the double encrypted data then take the results of theses operations and encrypted them using only the HBH key.  This results in three cryptography operation happening to the repair data sent over the wire. </del> <ins> double, typically operates on the double encrypted data and encrypts them using only the HBH key.  This results in three cryptography operation happening to the repair data sent over the wire. </ins> 7.1. When using RTX RFC4588 with double, the cached payloads MUST be the encrypted packets with the bits that are sent over the wire to the other side.  When encrypting a retransmission packet, it MUST be <del> encrypted in packet repair mode. </del> <ins> encrypted the packet in repair mode. </ins> A typical RTX receiver would decrypt the packet, undo the RTX <del> transformation, then process the resulting packet using the normally by using the steps in decrypt. </del> <ins> transformation, then process the resulting packet normally by using the steps in decrypt. </ins> 7.2. When using RED RFC2198 with double, the primary encoding MAY contain RTP header extensions and CSRC identifiers but non primary encodings <del> can not. </del> <ins> cannot. </ins> <del> The sender takes encrypted payloads from the cached packets to form </del> <ins> The sender takes encrypted payload from the cached packets to form </ins> the RED payload.  Any header extensions from the primary encoding are <del> copied to the RTP packet that will cary the RED payload and the other RTP header information such as SSRC, SEQ, CSRC, etc are set to the same as the primary payload.  The RED RTP packet is then encrypted in repair mode and sent. The receiver decrypts the payload to find the RED payload.  Note a media relay can do this decryption as the packet was sent in repair mode that only needs the hop-by-hop key.  The RTP headers and header extensions along with the primary payload and PT from inside the RED payload are used to form the encrypted primary RTP packet which can then be decrypted with double.  The RTP headers (but not header extensions or CSRC) along with PT from inside the RED payload are used for from the non primary payloads.  The time offset information in the RED data MUST be used to adjust the sequence number in the RTP header by using the timestamp offset and packet rate to find a sequence number offset to adjust by.  At this point the non primary </del> <ins> copied to the RTP packet that will carry the RED payload and the other RTP header information such as SSRC, SEQ, CSRC, etc are set to the same as the primary payload.  The RED RTP packet is then encrypted in repair mode and sent. The receiver decrypts the payload to find the encrypted RED payload. Note a media relay can do this decryption as the packet was sent in repair mode that only needs the hop-by-hop key.  The RTP headers and header extensions along with the primary payload and PT from inside the RED payload (for the primary encoding) are used to form the encrypted primary RTP packet which can then be decrypted with double. The RTP headers (but not header extensions or CSRC) along with PT from inside the RED payload corresponding to the redundant encoding are used to from the non primary payloads.  The time offset and packet rate information in the RED data MUST be used to adjust the sequence number in the RTP header.  At this point the non primary </ins> packets can be decrypted with double. Note that Flex FEC I-D.ietf-payload-flexible-fec-scheme is a superset

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF