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

From: Henrik Lundin <[email-masked]>
Date: Wed, 9 Sep 2015 23:01:59 +0200

Payload WG:

After the second Last Call, we have done a review of the document against
the comments that were pointed out to us on this document and on previous
versions of the document.

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:

We have added a number of definitions that were previously only in
referenced documents.

With regard to indexes that start at random numbers and wrap, we’ve
switched to consistently using “wrap”. The text about not starting at zero
is just to say that starting at zero is not required; there is no security
benefit that we know of.

We have removed some material that was repeated from RFC 6386; it was clear
that the explanation copied up was not sufficient for understanding, and we
found it better to refer to the more complete specification in RFC 6386 for
that material.

The definition of the Y-bit and structure of temporal layers has been
strengthened.

SLI and RPSI have been explained with more links back to RFC 4585.

We note that the text about pathological data noted in the sec-dir review
comes from the RTP HOWTO - we have updated the copied text to be consistent
with version -14 of the RTP HOWTO draft.

The Gen-ART review suggested to add a definition of temporal base layer. We
added an informal reference to an article on scalable video coding, and
think that the general definitions of scalability found therein apply to
this draft too.

The Gen-ART review also suggested that the VER field in the VP8 Payload
Header should be validated by the depacketizer. We disagree with this, and
argue that the VER field should be verified by the VP8 decoder.

For minor updates, please refer to the diff at
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-17.

With this update, we believe the document is ready for publication.

Sincerely,
/Henrik

-- 
Henrik Lundin | WebRTC Software Eng | [email-masked] | +46 70 646 13 41

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 09 Sep 2015 17:12:16 -0500

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.

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 09 Sep 2015 17:18:00 -0500

Hi,

Thanks for submitting this. I plan to put it on the agenda for the 
September 17 telechat.

In the interim, I had a few comments when you sent me the diff a while 
back that I think still apply (copied below for reference) I sent a 
separate email to the payload list point out the changes to 2119 
language.

Thanks!

Ben.

>
> This revision makes changes to normative language. Please make sure 
> those changes are mentioned on the working group list with enough time 
> for anyone to object prior to final approval. (This doesn't 
> necessarily need a WGLC unless the chairs wish it, but people should 
> at least see the changes and have a few days to complain if they don't 
> like it.)
>
>
> -- 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 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 9 Sep 2015, at 16:01, Henrik Lundin wrote:

> number

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Sep 2015 11:28:22 +0100

> On 9 Sep 2015, at 23:12, Ben Campbell <[email-masked]> 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? 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”).

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Sep 2015 09:24:41 -0700

On 09/10/2015 03:28 AM, Colin Perkins wrote:
> 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.

-- 
Surveillance is pervasive. Go Dark.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 11 Sep 2015 17:50:50 +0100

> On 10 Sep 2015, at 17:24, Harald Alvestrand <[email-masked]> wrote:
> 
> better to keep the name and just make a note that it’s different.

Makes sense.

> (section 4.2) - I couldn’t find any such references.

For clarity, I’d suggest it be done for all references in that section too. 

> collision there. It's never referred to in text.

Sure, but I think it does need to be highlighted that there’s a name collision.

None of these name collisions are a big deal, my main comment was on the wording around PT, but I do think they’d make things clearer.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 13 Sep 2015 15:31:26 -0700

>   Protocol (SDP) [RFC4566].
One question about this suggestion (from a general considerations
perspective): Is there any value at all in having this text in a payload
type registration?

What we want to say is that this document doesn't change any rules for
payload type registration - it's simply not relevant to this memo.

That would make the text shorter - we could stop after "will not be
specified here" in Colin's suggested text.

If the WG thinks the longer text has value, I'm happy to include it, but
I'm even happier if we can leave it out.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Sep 2015 09:40:32 -0500

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:

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

>>> 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.
>> This would be okay, except that RTP profiles that don’t derive from 
>> RFC 3551 could be defined. A better wording might be:
>>
>> 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?
>
>> 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”).
>
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Sep 2015 19:32:33 +0200

On 09/22/2015 04:40 PM, Ben Campbell wrote:
> 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:
>
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.
>> 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.
>>>>> 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:
>>>> 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.
>>> 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?
>>
>>> required (e.g., “the P bit in the payload header” or “the P bit in
>>> the RTP header” rather than “the P bit”).
>>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Sep 2015 12:43:26 -0500

inline:

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

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

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

>>>> be

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Sep 2015 12:50:13 -0500

Colin, did Harald's response address your concern?

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Sep 2015 12:51:34 -0500

> Colin's and Elwyn's other points that I had copied below.

On re-reading the list, I think I was mistaken about the comments being 
distinct--never mind about this part.

Thanks!

Ben.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Sep 2015 21:51:55 +0100

> On 22 Sep 2015, at 18:32, Harald Alvestrand <[email-masked]> wrote:
> 
> 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

-- 
Colin Perkins
https://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Sep 2015 22:57:45 +0200

Would you be OK with the shorter version I suggested?

Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins <[email-masked]>:
>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
>>>> 

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Sep 2015 22:00:42 +0100

Remind me?

> On 22 Sep 2015, at 21:57, Harald Alvestrand <[email-masked]> wrote:
> 
>  https://www.ietf.org/mailman/listinfo/payload <https://www.ietf.org/mailman/listinfo/payload>
>  
>  
>  -- 
>  https://www.ietf.org/mailman/listinfo/payload <https://www.ietf.org/mailman/listinfo/payload>
> 
> 
> 
> -- 

-- 
Colin Perkins
https://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Sep 2015 07:41:05 +0200

> 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 <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins
>> <[email-masked] <mailto:[email-masked]>>:
>>
>>         On 22 Sep 2015, at 18:32, Harald Alvestrand
>>         <[email-masked] <mailto:[email-masked]>> 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 9 Sep 2015, at 23:12, Ben Campbell
>>                         <[email-masked] <mailto:[email-masked]>>
>>                         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 [email-masked]
>>                 <mailto:[email-masked]>
>>         -- Surveillance is pervasive. Go Dark.
>>         ------------------------------------------------------------------------
>>         payload mailing list [email-masked]
>>         <mailto:[email-masked]>
>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
> -- 
> Colin Perkins
> https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 23 Sep 2015 08:14:24 +0100

> On 23 Sep 2015, at 06:41, Harald Alvestrand <[email-masked]> wrote:
> 
> "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.

Yes, that works for me.

Colin

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Sep 2015 09:26:32 +0200

>> I’m all for separation of concerns.
Ben, based on the set of threads until now - can we publish an updated
draft with this single change without revisiting the IESG, or would you
prefer to handle this by an RFC Editor note?

I don't think there are any other changes that we all agree on are
improvements that matter.

Harald

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Sep 2015 07:30:55 -0500

> improvements that matter.

Let's do the RFC Editor note.

Do I understand correctly that this replaces the "Payload Type" 
definition in section 4.1 in it's entirety? That is:

OLD:
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].
NEW:
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."
END:

Ben.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Sep 2015 15:26:01 +0200

>       format is outside the scope of this document and will not be

Yes, that was what I intended to propose.

Thanks!