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

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

inline:

On 22 Sep 2015, at 12:32, Harald Alvestrand wrote:

> 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)

I didn't see a response to the above. IIUC, these are distinct from 
Colin's and Elwyn's other points that I had copied below.

>>
>> 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.

It's probably worth poking Colin to make sure he's paying attention (I 
will do so.) But if we don't see a quick response, then I will agree 
with your assessment.

>>>
>>> -- 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.

I think that's a reasonable response, and a change is probably not 
needed.

>>
>> 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.