A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication
draft-ietf-avtext-mixer-to-client-audio-level-06

1. Lionel Morand made in his OPS-DIR review a number of comments which I suggest to be taken into consideration by the authors or RFC Editor: 

* Overall comment: the document defines a new optional RTP header extension to support a new service capability. However, it should be clarified somewhere (e.g. in the protocol description) the condition of service applicability e.g. all the entities involved need to support this extension.

* In section 1, figure 1: even if it is just for illustration, please indicate what would be the meaning of (S) and (M)

* In section 3: I'm not a specialist of RTP and use of mixers. However it might be desirable to extend the section dealing with the possible cascade of mixers. It is not obvious how each mixer will be involved along the path. Especially, it is not clear what is the rational that leads to the conclusion:
"it is likely that in such situations average audio levels would be perceptibly different for the participants located behind the different mixers."
 
* In section 5, it is said:
   "Conferencing clients that support audio level indicators and have no
   mixing capabilities would not be able to provide content for this
   audio level extension and would hence have to always include the
   direction parameter in the "extmap" attribute with a value of
   "recvonly".  Conference focus entities with mixing capabilities can
   omit the direction or set it to "sendrecv" in SDP offers.  Such
   entities would need to set it to "sendonly" in SDP answers to offers
   with a "recvonly" parameter and to "sendrecv" when answering other
   "sendrecv" offers."

Question: Is the setting of the direction parameter purely informative (sorry for my ignorance)? If not i.e. there are associated requirements, the above text is not appropriate (e.g. "would have to always", "would need") and "MUST" should be used instead.

* Figure 4 and 5: The description of each example should be put above the figures. Even if obvious, please indicate for clarification "SDP Offer:" and "SDP Answer:" on top of the lists of SDP parameter.

* Figure 4:
   "A client-initiated example SDP offer/answer exchange negotiating an
   audio stream with one-way flow of of audio level information."

s/one-way flow of of audio/one-way flow of audio

2. Please expand CSRC at first occurence

3. Please replace the conditional language in the first paragraph of the IANA considerations section. 

I noted the same things as Stephen.

Same comments as for client-to-mixer

(1) If vad can expose encrypted vbr, then why don't the security
considerations here say "if encrypting vbr and doing vad then you
MUST use apply commemsurate protection to both"? I don't get the
logic in the current section 6 where it says "if encrypting vbr
and doing vad then you SHOULD use some additional mechanism" -
what's the exceptional case that justifies the SHOULD there and
why would you ever do something appreciably weaker or stronger?

(2) Is the alternative to srtp-encrypted-header-ext to use IPsec
or TLS or what? It'd be better to reference those since if you
don't then I don't get how srtp-encrypted-header-ext isn't a
normative reference? I'd suggest adding a reference to either TLS
or IPsec, whichever is more likely to be used.