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

["Ben Campbell" <[e-mail]>]

Hi Harald,

I will check with Alissa to see if her concerns have been addressed.

Has there been closure on Elwyn's Gen-ART telechat review and on Colin's 
comments on the payload list? I was under the impression that at least 
Colin's comments might result in an update (although we can handle minor 
changes with RFC editor notes)

Also, I had some comments a while back to which I do not recall seeing a 
response:

> -- section 3, Payload Type: "... the VP8 RTP payload profile MUST 
> assign a dynamic payload type number ..."
>
> If I read correctly, Colin Perkins objected to this change. Did you 
> consider his objection?
>
> -- 4.2
>
> I didn't see anything addressing Elwyn's Gen-ART (last call) review 
> question about: “What happens if L=1 but both T=0 and K=0 so that 
> there is no TID value present? Or indeed if T=0 but K=1 so that the 
> TID field is there but 'MUST be ignored by the receiver'  (definition 
> of TID field)?” Did I miss something?

Thanks!

Ben.


On 10 Sep 2015, at 11:24, Harald Alvestrand 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.
>
>> 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.
>
> 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.
>
>
>>
>> Colin
>>
>>
>>
>>
>>
>>
>>
>
>
> -- 
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload