Change:
Other than revisiting section 3.1.1 and 5.3 after changes to other drafts are complete, these changes either directly, or in-spirit, address all of the feedback/comments.
Just a couple of comments inline.

Discussion:
Hop-by-Hop (HBH): Communications between an endpoint and a Media Distribution Device or between Media Distribution Devices. <del> Endpoint: An RTP flow terminating entity that has possession of E2E media encryption keys and terminates E2E encryption.  This may </del> <ins> Trusted Endpoint: An RTP flow terminating entity that has possession of E2E media encryption keys and terminates E2E encryption.  This may </ins> include embedded user conferencing equipment or browsers on computers, media gateways, MCUs, media recording device and more that are in the trusted domain for a given deployment.

which includes, but not limited to, having no access to RTP media unencrypted and having limits on what RTP header field it can alter. <del> Key Distributor: An entity that is a logical function which passes keying material and related information to endpoints and Media Distributor(s) that is appropriate for each.  The Key Distributor might be co-resident with another entity trusted with E2E keying material. </del> <ins> Key Distributor: An entity that is a logical function which distributes keying material and related information to trusted endpoints and Media Distributor(s), only that which is appropriate for each.  The Key Distributor might be co-resident with another entity trusted with E2E keying material. </ins> Conference: Two or more participants communicating via trusted endpoints to exchange RTP flows through one or more Media Distributor. <ins> Call Processing: All tusted endpoints in the conference connect to it by a call processing dialog, such as with the Focus defined in the Framework for Conferencing with SIP RFC4353. </ins> Third Party: Any entity that is not an Endpoint, Media Distributor, Key Distributor or Call Processing entity as described in this document.

Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is <del> authorized. </del> <ins> authorized.  Trusted endpoint authorization is described in the (add ref to new signaling draft here). </ins> A Media Distributor MUST perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects of denial of service attacks (refer to attacks), etc, to a level <del> equal to or better than traditional conferencing (i.e. pre-PERC) </del> <ins> equal to or better than traditional conferencing (i.e. non-PERC) </ins> deployments. A Media Distributor or associated conferencing infrastructure may

Endpoints will take measures to mitigate the adverse effects of denial of service attacks (refer to attacks) from other entities, including from other endpoints, to a level equal to or better than <del> traditional conference (i.e., pre-PERC) deployments. </del> <ins> traditional conference (i.e., non-PERC) deployments. </ins> 3.2.2.

User Agent would send an INVITE message containing SDP for the media session along with the endpoint's certificate fingerprint, which can be signed using the procedures described in RFC4474 for the benefit <del> of forwarding the message to other entities.  Other entities can now verify the fingerprints match the certificates found in the DTLS-SRTP connections to find the identity of the far end of the DTLS-SRTP connection and check that is the authorized entity. </del> <ins> of forwarding the message to other entities by the Focus RFC4353. Other entities can now verify the fingerprints match the certificates found in the DTLS-SRTP connections to find the identity of the far end of the DTLS-SRTP connection and check that is the authorized entity. </ins> Ultimately, if using session signaling, an endpoint's certificate fingerprint would need to be securely mapped to a user and conveyed

5.3. <del> The Key Distributor is responsible for knowing what endpoints are allowed in a given conference.  Thus, the Key Distributor and the </del> <ins> The Key Distributor needs to know what endpoints are to being added to in a given conference resource.  Thus, the Key Distributor and the </ins> Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique