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

[Harald Alvestrand <[e-mail]>]

On 09/22/2015 04:40 PM, Ben Campbell wrote:
> 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?
I asked in response if we can delete the whole thing about payload type
assignment, since it's not a proper concern of the payload type. I did
not get a response, so I thought it couldn't be important.
>>
>> -- 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?

On this matter, we thought the text was clear that those streams would
be illegal, and we don't specify the processing of illegal streams. But
if it isn't clear that it's illegal, we may want to reconsider.
>
> 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


-- 
Surveillance is pervasive. Go Dark.