Original text:
Media Distributor or an endpoint are authenticated hop-by-hop. To enable all of the above, this framework defines the use of two <del> security contexts and two associated encryption keys; an "inner" key (E2E Key(i); i={a given endpoint}) for authenticated encryption of RTP media between endpoints and an "outer" key (HBH Key(j); j={a given hop}) for the hop between an endpoint and a Media Distributor or between Media Distributor.  Reference the following figure. The PERC Double draft specification I-D.ietf-perc-double uses standard SRTP keying material and recommended cryptographic transform(s) to first form the inner, end-to-end SRTP cryptographic context.  That end-to-end SRTP cryptographic context MAY be used to encrypt some RTP header extensions along with RTP media content.  The output of this is treated like an RTP packet and encrypted again using the outer hop-by-hop cryptographic context.  The endpoint executes the entire Double operation while the Media Distributor just performs the outer, hop-by-hop operation. </del>  RTCP can only be encrypted hop-by-hop, not end-to-end.  This framework introduces no additional step for RTCP authenticated To ensure the confidentiality of E2E keys shared between endpoints, endpoints will make use of a common Key Encryption Key (KEK) that is known only by the trusted entities in a conference.  That KEK, <del> defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKTKey, will be used to subsequently encrypt SRTP master keys used for E2E authenticated encryption (E2E Key(i); i={a given endpoint}) of media sent by a given endpoint. </del>  4.3. transmitted during the life of a conference. Thus, endpoints MUST maintain a list of SSRCs from received RTP flows <del> and each SSRC's associated E2E Key(i) information.  Following a change of the KEK (i.e., EKTKey), prior E2E Key(i) information SHOULD be retained for a period long enough to ensure that late-arriving or out-of-order packets from other endpoints can be successfully decrypted.  The endpoint MUST discard the E2E Key(i) and KEK information no later than when it leaves the conference. </del>  If there is a need to encrypt one or more RTP header extensions end- to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those <del> header extensions encrypted with E2E keys. </del>  4.4. an endpoint and a Media Distributor, as well between Media Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the <del> respective hop (HBH Key(j); j={a given hop}).  Each HBH Key(j) is distinct per hop and no two hops ever intentionally use the same SRTP master key. </del>  Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media <del> Distributor to establish HBH keys for transmitting RTP and RTCP </del>  packets to that peer Media Distributor.  The Key Distributor does not <del> facilitate establishing HBH keys for use between Media Distributors. </del>  4.5.1. association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to receive E2E key <del> information, Key Encryption Key (KEK) information (i.e., EKTKey), and HBH key information.  At the same time, the Key Distributor can </del>  securely provide the HBH key information to the Media Distributor. The key information summarized here may include the SRTP master key, SRTP master salt, and the negotiated cryptographic transform. 4.5.2. Following the initial key information exchange with the Key <del> Distributor, endpoints will be able to encrypt media end-to-end with their E2E Key(i), sending that E2E Key(i) to other endpoints encrypted with KEK, and will be able to encrypt and authenticate RTP packets using local HBH Key(j).  The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any endpoint's E2E key and subsequently decrypting media. The KEK (i.e., EKTKey) may need to change from time-to-time during </del>  the life of a conference, such as when a new participant joins or leaves a conference.  Dictating if, when or how often a conference is to be re-keyed is outside the scope of this document, but this framework does accommodate re-keying during the life of a conference. <del> When a Key Distributor decides to rekey a conference, it transmits a </del>  specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to each of the conference participants.  The endpoint MUST create a new SRTP master key and prepare to send that key inside a Full EKT Field endpoints in conference to finish re-keying, senders MUST delay a short period of time before sending media encrypted with the new master key, but it MUST be prepared to make use of the information <del> from a new inbound EKTKey immediately.  See Section 2.2.2 of I- </del>  D.ietf-perc-srtp-ekt-diet. 5.

Reviewer comments:
This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM

Revised text:
Media Distributor or an endpoint are authenticated hop-by-hop. To enable all of the above, this framework defines the use of two  <ins> security contexts and two associated encryption keys: an "inner" key (an E2E key distinct for each transmitted media flow) for authenticated encryption of RTP media between endpoints and an "outer" key (HBH key) known only to media distributor and the adjacent endpoint) for the hop between an endpoint and a Media Distributor or between Media Distributor.  Reference the following figure. The PERC Double specification I-D.ietf-perc-double uses standard SRTP keying material and recommended cryptographic transform(s) to first form the inner, end-to-end SRTP cryptographic context.  That end-to- end SRTP cryptographic context MAY be used to encrypt some RTP header extensions along with RTP media content.  The output of this is treated like an RTP packet and encrypted again using the outer hop- by-hop cryptographic context.  The endpoint executes the entire Double operation while the Media Distributor just performs the outer, hop-by-hop operation.  (See keyinventory for a description of the keys used in PERC and packetformat for an overview of how the packet appears on the wire.) </ins> RTCP can only be encrypted hop-by-hop, not end-to-end.  This framework introduces no additional step for RTCP authenticated To ensure the confidentiality of E2E keys shared between endpoints, endpoints will make use of a common Key Encryption Key (KEK) that is known only by the trusted entities in a conference.  That KEK,  <ins> defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKT Key, will be used to subsequently encrypt the SRTP master key used for E2E authenticated encryption of media sent by a given endpoint.  Each endpoint in the conference will create a random SRTP master key for E2E authenticated encryption, thus participants in the conference MUST keep track of the E2E keys received via the Full EKT Field for each distinct SSRC in the conference so that it can properly decrypt received media.  Note, too, that an endpoint may change its E2E key at any time and advertise that new key to the conference as specified in I-D.ietf-perc-srtp-ekt-diet. </ins> 4.3. transmitted during the life of a conference. Thus, endpoints MUST maintain a list of SSRCs from received RTP flows  <ins> and each SSRC's associated E2E key information.  Following a change in an E2E key, prior E2E keys SHOULD be retained by receivers for a period long enough to ensure that late-arriving or out-of-order packets from the endpoint can be successfully decrypted.  Receiving endpoints MUST discard old E2E keys no later than when it leaves the conference. </ins> If there is a need to encrypt one or more RTP header extensions end- to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those  <ins> header extensions encrypted with an E2E key. </ins> 4.4. an endpoint and a Media Distributor, as well between Media Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the  <ins> respective hop.  Each HBH key is distinct per hop and no two hops ever intentionally use the same SRTP master key. </ins> Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media  <ins> Distributor to establish the HBH key for transmitting RTP and RTCP </ins> packets to that peer Media Distributor.  The Key Distributor does not  <ins> facilitate establishing a HBH key for use between Media Distributors. </ins> 4.5.1. association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to receive E2E key  <ins> information, Key Encryption Key (KEK) information (i.e., EKT Key), and HBH key information.  At the same time, the Key Distributor can </ins> securely provide the HBH key information to the Media Distributor. The key information summarized here may include the SRTP master key, SRTP master salt, and the negotiated cryptographic transform. 4.5.2. Following the initial key information exchange with the Key  <ins> Distributor, an endpoints will be able to encrypt media end-to-end with an E2E key, sending that E2E key to other endpoints encrypted with the KEK, and will be able to encrypt and authenticate RTP packets using a HBH key.  The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any endpoint's E2E key and subsequently decrypting media. The KEK (i.e., EKT Key) may need to change from time-to-time during </ins> the life of a conference, such as when a new participant joins or leaves a conference.  Dictating if, when or how often a conference is to be re-keyed is outside the scope of this document, but this framework does accommodate re-keying during the life of a conference.  <ins> When a Key Distributor decides to re-key a conference, it transmits a </ins> specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to each of the conference participants.  The endpoint MUST create a new SRTP master key and prepare to send that key inside a Full EKT Field endpoints in conference to finish re-keying, senders MUST delay a short period of time before sending media encrypted with the new master key, but it MUST be prepared to make use of the information  <ins> from a new inbound EKT Key immediately.  See Section 2.2.2 of I- </ins> D.ietf-perc-srtp-ekt-diet. 5.