Change:
To summarize what is encrypted and authenticated, we will refer to all the RTP fields except headers created by the sender and before <del> the pay load as the initial envelope and the RTP payload information </del> <ins> the payload as the initial envelope and the RTP payload information </ins> with the media as the payload.  Any additional headers added by the sender or Media Distributor are referred to as the extra envelope. <del> The sender uses the end-to-end key to encrypts the payload and authenticate the payload + initial envelope which using an AEAD </del> <ins> The sender uses the end-to-end key to encrypt the payload and authenticate the payload + initial envelope, which using an AEAD </ins> cipher results in a slight longer new payload.  Then the sender uses the hop-by-hop key to encrypt the new payload and authenticate the <del> initial envelope extra envelope and the new payload. </del> <ins> initial envelope, extra envelope and the new payload. </ins> The Media Distributor has the hop-by-hop key so it can check the authentication of the received packet across the initial envelope, extra envelope and payload data but it can't decrypt the payload as it does not have the end-to-end key.  It can add or change extra envelope information.  It then authenticates the initial plus extra <del> envelope information plus payload with a hop-by-hop key.  This hop- by-hop for the outgoing packet is typically different than the hop- </del> <ins> envelope information plus payload with a hop-by-hop key.  The hop-by- hop key for the outgoing packet is typically different than the hop- </ins> by-hop key for the incoming packet. The receiver can check the authentication of the initial and extra envelope information from the Media Distributor.  This, along with <del> the OHB, is used to construct a synthetic packet that is should be identical initial envelope plus payload to one the sender created and the receiver can check that it is identical and then decrypt the original payload. </del> <ins> the OHB, is used to construct a synthetic packet which should be identical to the initial envelope plus payload to one the sender created and the receiver can check that it is identical and then decrypt the original payload. </ins> The end result is that if the authentications succeed, the receiver <del> knows exactly what the payload and initial envelope the sender sent, as well as exactly which modifications were made by the Media Distributor and what extra envelope the Media Distributor send.  The </del> <ins> knows exactly the payload and initial envelope the sender sent, as well as exactly which modifications were made by the Media Distributor and what extra envelope the Media Distributor sent.  The </ins> receive does not know exactly what extra envelope the sender sent. <del> It is obviously critical that the intermediary has only the outer (hop-by-hop) algorithm key and not the half of the key for the the inner (end-to-end) algorithm.  We rely on an external key management protocol to assure this property. </del> <ins> It is obviously critical that the intermediary has access to just the outer (hop-by-hop) algorithm key and not the half of the key for the the inner (end-to-end) algorithm.  We rely on an external key management protocol to ensure this property. </ins> Modifications by the intermediary result in the recipient getting two values for changed parameters (original and modified).  The recipient

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