Subject: Gen-ART review of draft-ietf-avtext-client-to-mixer-audio-level-05.txt

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Sep 2011 22:44:30 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ 
at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other comments you may receive.

Document: draft-ietf-avtext-client-to-mixer-audio-level-05.txt
Reviewer: Alexey Melnikov
Review Date: 2011-09-25
IETF LC End Date: 2011-10-04
IESG Telechat date:

Summary: The document is ready for publication as a standards track RFC.

Major issues: none

Minor issues:

Question: are the two encoding of the audio level indication option 
specified in the document really necessary?

Nits/editorial comments:

6.  Security Considerations

    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, if a device relys on audio level data from

s/relys/relies ???

    untrusted endpoints, it SHOULD periodically audit the level

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Sep 2011 23:24:56 +0100

Jonathan Lennox wrote:

>Hi, Alexey -- thank you for the Gen-ART review.
>  
>
Hi Jonathan,

>Alexey Melnikov writes:
>  
>
>>Question: are the two encoding of the audio level indication option specified in the document really necessary?
>>    
>>
>
>Do you mean the one-byte vs. two-byte forms of the header extension (Figure 1 vs. Figure 2)?  These are the two forms of the generic header extensions defined by RFC 5285.
>
I understood that. Does RFC 5285 require that both forms should be allowed?
In general, it would be good to avoid multiple representations of the 
same thing.

>The actual payload (one byte containing the V and level bits) is identical in the two cases; the only difference is the container.  We can add some text clarifying this point if you think it would be helpful.
>  
>
>>Nits/editorial comments:
>>s/relys/relies ???
>>    
>>
>Thanks, will fix.
>  
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Sep 2011 10:20:31 +0100

Emil Ivov wrote:

> Hey Alexey,

Hi Emil,

> On 27 sept. 2011, at 00:24, Alexey Melnikov <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Jonathan Lennox wrote:
>>
>>> Do you mean the one-byte vs. two-byte forms of the header extension 
>>> (Figure 1 vs. Figure 2)?  These are the two forms of the generic 
>>> header extensions defined by RFC 5285.
>>
> It doesn't explicitly say so but it It actually does, yes. Here's what 
> it says:
>
>   A stream MUST contain only one-byte or two-byte
>   headers: they MUST NOT be mixed within a stream.
>
>
> Audio level headers can find themselves in streams that also have 
> other, longer extensions, which do require the two-byte header. The 
> above lines mandate that in such cases they all use the two-byte header.

Ok, this is good enough for me. Thanks for explaining.

> In the same regard, although probably a bit less likely, nothing 
> prevents having another sixteen header extensions in a stream that 
> also has levels. In that case we'd need to switch to two-byte headers 
> in order to be able to fit all the IDs.
>
> Cheers,
> Emil
>
> --sent from my mobile
>
>>> The actual payload (one byte containing the V and level bits) is 
>>> identical in the two cases; the only difference is the container. 
>>>  We can add some text clarifying this point if you think it would be 
>>> helpful.
>>
>>>
>>>> Nits/editorial comments:
>>>
>>>> s/relys/relies ???
>>>
>>>>   
>>>
>>> Thanks, will fix.
>>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 26 Sep 2011 17:55:46 -0400

> Question: are the two encoding of the audio level indication option specified in the document really necessary?

Do you mean the one-byte vs. two-byte forms of the header extension (Figure 1 vs. Figure 2)?  These are the two forms of the generic header extensions defined by RFC 5285.  The actual payload (one byte containing the V and level bits) is identical in the two cases; the only difference is the container.  We can add some text clarifying this point if you think it would be helpful.

Thanks, will fix.

-- 
Jonathan Lennox
[email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Tue, 27 Sep 2011 06:20:37 +0200

Hey Alexey,

> I understood that. Does RFC 5285 require that both forms should be allowed?

It doesn't explicitly say so but it It actually does, yes. Here's what it says:

Audio level headers can find themselves in streams that also have other, longer extensions, which do require the two-byte header. The above lines mandate that in such cases they all use the two-byte header.

In the same regard, although probably a bit less likely, nothing prevents having another sixteen header extensions in a stream that also has levels. In that case we'd need to switch to two-byte headers in order to be able to fit all the IDs.

Cheers,
Emil

--sent from my mobile

> In general, it would be good to avoid multiple representations of the same thing.
>