Re: [payload] New version of draft-ietf-payload-vp8

[Colin Perkins <[e-mail]>]

> On 10 Sep 2015, at 17:24, Harald Alvestrand <[e-mail]> wrote:
> 
> On 09/10/2015 03:28 AM, Colin Perkins wrote:
>>> On 9 Sep 2015, at 23:12, Ben Campbell <[e-mail]> wrote:
>>> 
>>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote:
>>> 
>>>> We have made no technical changes to the document, but have added a number of grammar updates and clarifications. Some of the important clarifications are as follows:
>>> Payload participants: Please note that there are in fact changes to 2119 language in this version. I won't quibble about whether or not those count as "technical" changes, but please take a moment to review them. If people object to any of them please say so asap , as this draft will likely be on the agenda for the IESG telechat next week.
>> The new text about the Payload Type in Section 4.1 says:
>> 
>>  Payload type (PT):  In line with the policy in Section 3 of
>>     [RFC3551], applications using the VP8 RTP payload profile MUST
>>     assign a dynamic payload type number to be used in each RTP
>>     session and provide a mechanism to indicate the mapping.  See
>>     Section 6.2 for the mechanism to be used with the Session
>>     Description Protocol (SDP) [RFC4566].
>> 
>> This would be okay, except that RTP profiles that don’t derive from RFC 3551 could be defined. A better wording might be:
>> 
>>  Payload Type (PT): The assignment of an RTP payload type for this
>>  packet format is outside the scope of this document and will not be
>>  specified here.  It is expected that the RTP profile for a particular
>>  class of applications will assign a payload type for this encoding,
>>  or if that is not done, then a payload type in the dynamic range
>>  SHALL be chosen by means of an out-of-band signaling protocol. See
>>  Section 6.2 for the mechanism to be used with the Session Description
>>  Protocol (SDP) [RFC4566].
>> 
>> 
>> In Section 4.2, rather than add a note that “this X bit is not to be confused with the X bit in the RTP header”, would it not make sense to rename this X bit?
> 
> We considered this option, but decided that having a large existing body
> of documentation outside of the IETF that refers to the "X bit" and
> having a payload type registration that called it something else, it ws
> better to keep the name and just make a note that it’s different.

Makes sense.

>> Similarly for the M bit in the extension data fields, and the P bit in the payload header (which isn’t mentioned). Or, at least, annotate each mention of these fields to say which X, M, or P bit it required (e.g., “the P bit in the payload header” or “the P bit in the RTP header” rather than “the P bit”).
> 
> This can be done, and probably should be done for any reference that
> occurs outside of the section describing the VP8 payload descriptor
> (section 4.2) - I couldn’t find any such references.

For clarity, I’d suggest it be done for all references in that section too. 

> There is no P bit in the VP8 payload descriptor, but there is one in the
> VP8 payload header, which is why we missed warning about the name
> collision there. It's never referred to in text.

Sure, but I think it does need to be highlighted that there’s a name collision.

None of these name collisions are a big deal, my main comment was on the wording around PT, but I do think they’d make things clearer.

Colin







-- 
Colin Perkins
https://csperkins.org/