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

[Harald Alvestrand <[e-mail]>]

Would you be OK with the shorter version I suggested?

Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins <[e-mail]>:
>> On 22 Sep 2015, at 18:32, Harald Alvestrand <[e-mail]>
>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)
>>> 
>>> 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.
>
>I thought the question was for others in the working group. My opinion
>is that we do need text here, and I proposed something I thought
>appropriate, although I’m open to other suggestions. The current text
>does need to be changed, however.
>
>Colin
>
>
>
>
>
>>>> 
>>>> -- 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.
>> 
>> _______________________________________________
>> payload mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/payload
>
>
>
>-- 
>Colin Perkins
>https://csperkins.org/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.