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

[Harald Alvestrand <[e-mail]>]

On 09/22/2015 11:00 PM, Colin Perkins wrote:
> Remind me?
Suggested text (suggested in a way that was a bit hard to follow):

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

I'm all for separation of concerns.

>
>> On 22 Sep 2015, at 21:57, Harald Alvestrand <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> Would you be OK with the shorter version I suggested?
>>
>> Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins
>> <[e-mail] <mailto:[e-mail]>>:
>>
>>         On 22 Sep 2015, at 18:32, Harald Alvestrand
>>         <[e-mail] <mailto:[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] <mailto:[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]
>>                 <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/listinfo/payload 
>>
>>         -- Surveillance is pervasive. Go Dark.
>>         ------------------------------------------------------------------------
>>         payload mailing list [e-mail]
>>         <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/payload 
>>
>>
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
> -- 
> Colin Perkins
> https://csperkins.org/