Change:
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> <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

Discussion:
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