Subject: [avtext] WGLC comments on draft-ietf-avtext-client-to-mixer-audio-level-03

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Jul 2011 23:59:41 +0200

No technical issues identifies. These are primarily editorial.

1)	Normative references to RFC 3550. At the moment the only reference in the text is in section 1, which is really meant to be a description section, and the reference here cannot really be inferred to be normative. I have no doubt you probably do need this as a normative reference, but it is currently carried implicitly in the normative reference to RFC 5285 made at the start of section 3. Why not add an explicit reference to RFC 3550 to the first paragraph there.

2)	Section 1

Need to remove non RFC 2119 usage of lower case "should".

   In a centralized Real-Time Transport Protocol (RTP) [RFC3550] audio
   conference, an audio mixer or forwarder receives audio streams from
   many or all of the conference participants.  It then selectively
   forwards some of them to other participants in the conference.  In
   large conferences, it is possible that such a server might be
   receiving a large number of streams, of which only a few should be
   forwarded to the other conference participants.

Believed what is meant here is "...of which only a few are intended to be forwarded...".

3)	Section 5

This appears to be intended as an informative section. Therefore use of lower case "should" and "must" that might be mistaken for normative language are best avoided.

   Mixers and forwarders generally should not base audio forwarding
   decisions directly on packet-by-packet audio level information, but
   rather should apply some analysis of the audio levels and trends.
   This general rule applies whether audio levels are provided by
   endpoints (as defined in this document), or are calculated at a
   server, as would be done in the absence of this information.  This
   section discusses several issues that mixers and forwarders may wish
   to take into account.  (Note that this section provides design
   guidance only, and is not normative.)

   Additionally, different participants may have their audio input set
   differently.  It may be useful to apply some sort of automatic gain
   control to the audio levels.  There are a number of possible
   approaches to acheiving this, e.g. by measuring peak audio levels, by
   average audio levels during speech, or by measuring background audio
   levels (average audio level levels during non-speech).

Is best rendered as:

   It is not desirable that mixers and forwarders base audio forwarding
   decisions directly on packet-by-packet audio level information, and 
   instead, better to apply some analysis of the audio levels and trends.
   This general rule applies whether audio levels are provided by
   endpoints (as defined in this document), or are calculated at a
   server, as would be done in the absence of this information.  This
   section discusses several issues that mixers and forwarders may wish
   to take into account.  (Note that this section provides design
   guidance only, and is not normative.)

   Additionally, different participants can have their audio input set
   differently.  It can be useful to apply some sort of automatic gain
   control to the audio levels.  There are a number of possible
   approaches to achieving this, e.g. by measuring peak audio levels, by
   average audio levels during speech, or by measuring background audio
   levels (average audio level levels during non-speech).

Note also typo in "acheiving"

4)	Section 6

   A malicious endpoint could choose to set the values in this header
   extension falsely, so as to falsely claim that audio or voice is or
   is not present.  It is not clear what could be gained by falsely
   claiming that audio is not present, but an endpoint falsely claiming
   that audio is present could perform a denial-of-service attack on an
   audio conference, so as to send silence to suppress other conference
   members' audio.  Thus, a device relying on audio level data from
   untrusted endpoints SHOULD periodically audit the level information
   transmitted, taking appropriate corrective action if endpoints appear
   to be sending incorrect data.  

Suggest a minor rewording of the requirement as follows as " if endpoints appear to be sending incorrect data" cannot be part of the condition.

   A malicious endpoint could choose to set the values in this header
   extension falsely, so as to falsely claim that audio or voice is or
   is not present.  It is not clear what could be gained by falsely
   claiming that audio is not present, but an endpoint falsely claiming
   that audio is present could perform a denial-of-service attack on an
   audio conference, so as to send silence to suppress other conference
   members' audio.  If a device relies on audio level data from
   untrusted endpoints, then the device SHOULD periodically audit the level 
   information transmitted, taking appropriate corrective action. This
   provides a level of protection against endpoints sending incorrect data.  

5)	Section 6

(Note that as it is valid for an
   endpoint to choose to measure audio levels prior to encoding, some
   degree of discrepancy SHOULD be tolerated.)

Preceding a "SHOULD" with "Note..." and putting it in parentheses is liable to lead to lack of clarity as to whether it is normative or informative. I suggest it is probably informative and it should be reworded accordingly.

Regards

Keith