RTP Payload Format for VP8 Video
draft-ietf-payload-vp8-17

[Ballot comment]
Why is this a SHOULD:
Applications SHOULD use one or more appropriate strong security mechanisms.

Wouldn't it be more helpful to point out why you would use specific security mechanisms for security considerations?

[Ballot comment]
-- 4.2: Little confused as to why the I and L behavior is specified twice, e.g.:

"I: PictureID present.  When set to one, the PictureID MUST be present
      after the extension bit field and specified as below.  Otherwise,
      PictureID MUST NOT be present."

and

"The PictureID extension:  If the I bit is set to one, the PictureID
      extension field MUST be present, and MUST NOT be present
      otherwise."
     
-- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random values?

-- 6.1: Seconding Pete's old comment that the normative requirements on use of max-fs and max-fr should appear somewhere other than the media type definition.

[Minor edit by Ben Campbell on 9/9/2015]

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Standards track as indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the RTP payload format for the VP8 video codec.
The VP8 codec supports various applications ranging from low-bitrate
peer-to-peer to high-bitrate videoconferencing applications.

Working Group Summary

        The WGLC process was run twice and bunch of comments were addressed in
the latest version. After the second WGLC, there were some comments
submitted by Cullen Jennings and one of the authors responded in the list.
At this time, we are proceeding with publication request. If there are
further comments, they can be submitted during the IETF LC.

[Ben: Since this, the draft has been through an initial IESG evaluation and a second IETF last call]

Document Quality

        The VP8 codec has been used in various applications (most notably by
Google). Earlier versions of codec were used by Skype. The media subtype
registration review was request on 11/28/2012.

Personnel

        Ali Begen is the document shepherd. Ben Campbell is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

        The shepherd reviewed the latest version (-08) and there are no issues.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

        Not at this point.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

        Nope.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

        None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

        Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

        There is one IPR submission from Vidyo (IPR 1622). The WG did not have
concerns about this IPR submission.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

        Several people reviewed this document, mostly who are interested in
implementing this payload. There were no objections from the rest of the
WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

        Nope.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

        There are a few ID nits.

        1) Unused reference: RFC 3984
        2) Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)
        3) Downref: Normative reference to an Informational RFC: RFC 6386

There are also a few minor errors. For example, the subtype has 3 (not 2)
optional parameters.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

        Media subtype registration review was requested:
        http://www.ietf.org/mail-archive/web/media-types/current/msg00455.html

(13) Have all references within this document been identified as
either normative or informative?

        No, which means all references will be considered as "normative".

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

        Nope.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

        There is a downref to RFC 6386, which is the main RFC that describes the
VP8 data format. That RFC is an informational one since it was an
independent submission (not thru a WG).

[Ben: This downref was called out in the second IETF last call.]

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

        No changes to existing documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

        The media subtype registration is compliant with the registration
template (RFC 6838).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

        No new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

        No formal language considerations.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-payload-vp8-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the video subspace of the Media Types namespace located at:

http://www.iana.org/assignments/media-types/

the following video media type will be registered:

Name: VP8
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for VP8 Video) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Payloads
WG (payload) to consider the following document:
- 'RTP Payload Format for VP8 Video'
  as Proposed Standard

This draft contains normative reference to an Informational RFC: RFC 6386

This is a repeated last call. The draft was previously last called and underwent
IESG evaluation in 2013. The last call is being repeated due to the normative
downward reference, and due to the fairly significant changes since that
evaluation.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-07-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo describes an RTP payload format for the VP8 video codec.
  The payload format has wide applicability, as it supports
  applications from low bit-rate peer-to-peer usage, to high bit-rate
  video conferences.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1622/

I'm doing a quick re-look at draft-ietf-payload-vp8-16 before starting a repeat IETF Last Call. I have a few comments. I don't think any of these need delay the last call, so please address them along with any last call comments.

Please bear in mind that I am reconstructing a lot of history here, so I apologize in advance if I bring up things that have already been discussed.

------------

General:

Ted Lemon and Pete Resnick made some AD comments when they were still ADs. Even though they are no longer on the IESG, their comments look reasonable. I don't see evidence that they have been addressed--please consider addressing them.

It looks like you have addressed some, but not all, of Stephen Farrell's comments. Has there been discussion on why the ones not addressed were not addressed?

(Note that in both of the paragraphs above, I don't mean by "addressed" that the draft necessarily needs to change--just that the authors respond to the input--even if only to say why they don't agree with a comment.)

-- 4.5 and 4.5.1: It would be helpful to explain why these are listed as examples. I assume it's one of those cases where this algorithm gives the right results, but others could also do so. If so, some words to that effect would be helpful. It might also be helpful to include a few words indicating why 4.5.1 is a child of 4.5 rather than a peer. (I assume because partition reconstruction is a subset of frame reconstruction?)

-- 7:

I don't see a response to the secdir review ( Secdir review of draft-ietf-payload-vp8-08 ). For the SRTP question, please consider using the boilerplate in the appendix of draft-ietf-payload-rtp-howto-14 (section A.13).

[Ballot comment]
Thanks very much for addressing all my comments.

The downref to RFC 6386 was not called out in the Last Call message; that's required in order to support a downref, unless the referenced document is in the downref registry (which 6386 isn't).  That means we'd need to re-run a two-week last call for that.  I'll leave it to the responsible AD to decide whether to do that or not.  No further blocking from me on the point.

[Ballot comment]
I'm clearing because my first Discuss point about PID fields was addressed, and that was my major concern, but I didn't see any response via e-mail or changed text about my second DIscuss point on wrapping versus restarting at 0.

It's not worth holding the document up for my second Discuss point, but if you meant to either tell me the Discuss point wasn't a problem or change text to address it, I missed that.

Which could have happened, of course.

For reference, that was as follows:

  TL0PICIDX:  8 bits temporal level zero index.  The field MUST be
      present if the L bit is equal to 1, and MUST NOT be present
      otherwise.  TL0PICIDX is a running index for the temporal base
      layer frames, i.e., the frames with TID set to 0.  If TID is
      larger than 0, TL0PICIDX indicates which base layer frame the
      current image depends on.  TL0PICIDX MUST be incremented when TID
      is 0.  The index SHOULD start on a random number, and MUST restart
      at 0 after reaching the maximum number 255.

  KEYIDX:  5 bits temporal key frame index.  The TID/KEYIDX octet MUST
      be present when either the T bit or the K bit or both are equal to
      1, and MUST NOT be present otherwise.  The KEYIDX field MUST be
      ignored by the receiver when the K bit is set equal to 0.  The
      KEYIDX field is a running index for key frames.  KEYIDX MAY start
      on a random number, and MUST restart at 0 after reaching the
      maximum number 31.

I'm not quite sure why PictureID says "MUST wrap" and TL0PICIDX and KEYIDX say
"MUST restart at 0". Are these the same thing (I would have thought so, but I'm
not the codec guy). If they are the same, and you could consider using one term
or the other in the document, that would be great. If they aren't the same,
please say more about that.

[Ballot comment]
I would prefer clearly listing the name of the references section as "Normative References", to make clear that all the references are required for understanding/implementation.

[Ballot discuss]
Regarding Barry's DISCUSS on downref (which I support obviously)
See RFC 3967

    3.  The Procedure to Be Used

      For Standards Track or BCP documents requiring normative reference to
      documents of lower maturity, the normal IETF Last Call procedure will
      be issued, with the need for the downward reference explicitly
      documented in the Last Call itself.  Any community comments on the
      appropriateness of downward references will be considered by the IESG
      as part of its deliberations.

See http://tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
However, idnits shows:

Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack separate sections for Informative/Normative
    References.  All references will be assumed normative when checking for
    downward references.

I guess RFC 6386 should be normative (but not 100% sure). This makes the link with Jari's DISCUSS.

I really wish the IESG would not have to spend time on idnits problems, and I even think the IESG should send the document back to the WG. This elevates my feedback to a DISCUSS, even if the problems have been reported in several DISCUSSes.

[Ballot comment]

I agree with the other discusses and comments. I also
got the impression this either hadn't been that
thoroughly reviewed or else had been so controversial
that folks maybe concentrated only on the difficult
parts and not on ovrerall clarity. I think it'd be
very good to get someone to do a pass over the whole
thing to improve clarity. If there weren't so many
other discusses I think this would have been one.

- section 3: where do I find out how to set up a
reference hierarchy?

- 4.1: "PID MUST NOT be larger than" 7 surely? Also
given the "SHOULD increment" doesn't that mean I can
send PIDs 0,3 and 7 only and that's ok? Do you want
that?

- 4.1: " If the X bit is 0, the extension bit field
MUST NOT be present, and all bits below MUST be
implicitly interpreted as 0." If X=0 then these
octets are not sent so the various flags are not
"bits" really. Suggest s/bits/values/ or similar.

- 4.1: I assume TL0PICIDX etc are defined somewhere.
Where?  Adding some references would seem to be
needed.

- 4.5: Why is this an example? That's confusing.  So
is the structure of 4.5 then 4.5.1.

- Please see the secdir review [1] which raises a
couple more minor issues.

[1] http://www.ietf.org/mail-archive/web/secdir/current/msg04030.html

[Ballot comment]
4.1:

  Sequence number:  The sequence numbers are monotonically increasing
      and set as packets are sent.
     
I think you mean "strictly increasing". "Monotonically increasing" can (in some circles) mean "nondecreasing".

6.1:

      max-fr, max-fs  These parameters MAY be used to signal the
        capabilities of a receiver implementation.  These parameters
        MUST NOT be used for any other purpose.

Putting MAY and MUST NOT like directives *inside* of the media type registration is a way to get them lost. They should be part of the spec. I suggest just moving the above to somewhere else in section 6.

[Ballot comment]
In 4.1, in the caption for figure 1:
  The VP8 payload descriptor and VP8 payload header will be described
  in the sequel.  OPTIONAL RTP padding MUST NOT be included unless the
  P bit is set.

What does "will be described in the sequel" mean?  I looked for an antecedent earlier in the document, and was unable to locate one, and the word "sequel" never appears elsewhere in the document.  I presume this is referring to some follow-on document or later section in the current document, but that isn't clear from the text.  If by sequel you mean "sections 4.2 and 4.3" then you should just say that.  If you are using xml2rfc you can reference a section as described here: http://xml.resource.org/xml2rfcFAQ.html#anchor17

If you are using something other than xml2rfc, I would just say "is described in the following two sections" or else refer to the sections by title.

Also in 4.1:
  Timestamp:  The RTP timestamp indicates the time when the frame was
      sampled at a clock rate of 90 kHz.

Is the frame sometimes sampled at other clock rates?  I suspect you mean something like this:

  Timestamp:  The RTP timestamp indicates the time when the frame was
      sampled.  The granularity of the clock is 90 kHz, so a value of 1 represents
      1/90,000 of a second.

Also, the definition of timestamp doesn't say what the timestamp is relative to.  I think this would prevent interoperation, since absent any additional specification I can think of at least three times it could be relative to: the time the first packet was sent, the time since the beginning of the video at which the current frame occurs, or the time at which the preceding packet was sent.  I was going to make this a DISCUSS, but on reading section 4.5, it looks like this is the time of the frame relative to the beginning of the video, and I suspect implementors will figure this out.  However, I still think you ought to say explicitly.

Also:
  Sequence number:  The sequence numbers are monotonically increasing
      and set as packets are sent.

Do you mean "set in the order that packets are sent"?

At the beginning of 4.3:
  The beginning of an encoded VP8 frame is referred to as an
  "uncompressed data chunk" in [RFC6386], and co-serve as payload
  header in this RTP format.

I guess Barry already hassled you about this; I found it equally puzzling.

From 5.1:
  pictures.  The positive feedback method is useful for VP8 used as
  unicast.  The use of RPSI for VP8 is preferably combined with a

I almost think I know what "VP8 used as unicast" means, but I'm probably wrong.  Could you clarify this sentence?

  Here, First is the macroblock address (in scan order) of the first
  lost block and Number is the number of lost blocks.  PictureID is the
  six least significant bits of the codec-specific picture identifier
  in which the loss or corruption has occurred.  For VP8, this codec-
  specific identifier is naturally the PictureID of the current frame,

What is a macroblock address?  I suspect that this is a VP8-specific term, but it would help to say where the reader could find out more.  Also, searching back through the document I notice that the second paragraph of the introduction talks about "decomposition of frames into square sub-blocks of pixels" and subsequently mentions macroblocks; are macroblocks these square sub-blocks of pixels?  If so, you should say "square sub-blocks of pixels, called macroblocks," so that the reader can clearly see the connection, rather than having to infer it and be uncertain whether the inference is correct.

In section 7:
  Integrity of the RTP packets through suitable
  cryptographic integrity protection mechanism.

Where is the verb?

Thanks for documenting this!

[Ballot comment]
This document would probably be fine were it not for the obvious problems citied in the genart review and the other discusses. imho I have nothing more to add, I wouldn't object to the document were it actually  ready.

[Ballot discuss]
I cannot determine if the references are normative or not. Perhaps a change of the section title would be in order? Clearly some references are normative, but what about these, for instance:

  [RFC6386]  Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
              Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
              Guide", RFC 6386, November 2011.

  [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, January 2013.

[Ballot comment]
See also the Gen-ART review from Elwyn Davies:

s10:  Are all of the refs normative?  If so change the section title.
The only one which I am dubious about is RFC 4566 (and there is  6386 -
see next comment).

[Ballot discuss]
This discuss point should be easy to clear - there were just a couple of places that were too unclear for me to be confident that implementers would read them the same way.

In 4.2.  VP8 Payload Descriptor

  PictureID:  8 or 16 bits including the M bit.  This is a running
      index of the frames.  The field MUST be present if the I bit is
      equal to one.  The 7 following bits carry (parts of) the
      PictureID.  If the extension flag is one, the PictureID continues
      in the next octet forming a 15 bit index, where the 8 bits in the
      second octet are the least significant bits of the PictureID.  If
      the extension flag is zero, there is no extension, and the
      PictureID is the 7 remaining bits of the first (and only) octet.
      The sender may choose 7 or 15 bits index.  The PictureID SHOULD
      start on a random number, and MUST wrap after reaching the maximum
      ID.  The receiver MUST NOT assume that the number of bits in
      PictureID stay the same through the session.

Did I miss (or does everyone know) how to set the PictureID if you're using a 15-bit index, you have a current value that won't fit in 7 bits, and then the sender decides for whatever reason to start using 7-bit indexes? Should the receiver expect to see the lower 7 bits of the incremented 15-bit PictureID, a newly random 7-bit PictureID, 0, or "something else"?

  TL0PICIDX:  8 bits temporal level zero index.  The field MUST be
      present if the L bit is equal to 1, and MUST NOT be present
      otherwise.  TL0PICIDX is a running index for the temporal base
      layer frames, i.e., the frames with TID set to 0.  If TID is
      larger than 0, TL0PICIDX indicates which base layer frame the
      current image depends on.  TL0PICIDX MUST be incremented when TID
      is 0.  The index SHOULD start on a random number, and MUST restart
      at 0 after reaching the maximum number 255.

  KEYIDX:  5 bits temporal key frame index.  The TID/KEYIDX octet MUST
      be present when either the T bit or the K bit or both are equal to
      1, and MUST NOT be present otherwise.  The KEYIDX field MUST be
      ignored by the receiver when the K bit is set equal to 0.  The
      KEYIDX field is a running index for key frames.  KEYIDX MAY start
      on a random number, and MUST restart at 0 after reaching the
      maximum number 31. 

I'm not quite sure why PictureID says "MUST wrap" and TL0PICIDX and KEYIDX say "MUST restart at 0". Are these the same thing (I would have thought so, but I'm not the codec guy). If they are the same, and you could consider using one term or the other in the document, that would be great. If they aren't the same, please say more about that.

[Ballot comment]

In 4.4.  Aggregated and Fragmented Payloads

  An encoded VP8 frame can be divided into two or more partitions, as
  described in Section 1.  One packet can contain a fragment of a
  partition, a complete partition, or an aggregate of fragments and
  partitions.  In the preferred use case, the S bit and PID fields
  described in Section 4.2 should be used to indicate what the packet
  contains.  The PID field should indicate which partition the first
  octet of the payload belongs to, and the S bit indicates that the
  packet starts on a new partition.

I'm not bitching about 2119 lower-case "should"s, but I am wondering if this would be clearer if you just said "is used to indicate", etc. Even in the common English sense of the word, "should be used to" leaves the door open that the S bit and PID fields could be used to do something else. Same for PID field.

In 4.5.1.  Partition reconstruction algorithm

  2: Continue scan to detect end of partition; hence a new S=1
      (previous packet was the end of the partition) is found or the
      marker bit is set.  If a loss it detected before the end of the
                                    ^^ "is detected", I think? but it's a nit.

[Ballot discuss]
Two points, highlighted below...

From the shepherd writeup:

    There are a few ID nits.
    1) Unused reference: RFC 3984
    2) Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)
    3) Downref: Normative reference to an Informational RFC: RFC 6386

Why weren't these fixed before the document went out for Last Call and then IESG Evaluation?  I don't care about #1, but...

On #2, it's not just that 4288 is an obsolete reference.  It's that the template used in Section 6.1 is from 4288, and that template *changed* in 6838.  These idnits warnings have a purpose: you're supposed to fix the reference *and* you're supposed to make sure that the new reference still applies, and make any necessary changes to the document.

The template changed in 6838 ("Fragment identifier considerations" was added; there were a couple of other minor changes, but that's the important one).  The shepherd writeup says, "The media subtype registration is compliant with the registration template (RFC 6838)."  It is not.  The procedure for media-type registrations also changed, but I don't think that affects this document.

DISCUSS POINT 1: Please update the document with respect to RFC 6838.

On #3, the downref was not called out in the Last Call message; that's required in order to support a downref, unless the referenced document is in the downref registry (which 6386 isn't).  That means we'd need to re-run a two-week last call for that.

DISCUSS POINT 2 (for the AD, not the authors): I think we need to re-run the Last Call for this document.

[Ballot comment]
I find a number of things in Section 4.2 to be confusing.  These comments are non-blocking, but I think it would be a very good idea to do some clarification here:

  When the X bit is set to 1 in the first octet, the OPTIONAL extension
  bit field MUST be present in the second octet.  If the X bit is 0,
  the extension bit field MUST NOT be present, and all bits below MUST
  be implicitly interpreted as 0.

This is a very odd use of "OPTIONAL"; it's not optional at all.  The value of the X bit specifies exactly what the state of the extension bit field has to be.  The same is true for the I, L, T, and K fields, which also claim to be OPTIONAL.

I'm not making this a DISCUSS, because I think the likelihood of actual misunderstanding is low, but I really think it's best to remove the "OPTIONAL"s, and to state instead that these fields might or might not be present, depending upon the values of the control bits.

I also do not understand the last clause: what does "and all bits below MUST be implicitly interpreted as 0" mean?

Wait, I think I get it: you mean, "and no extensions (I, L, T, or K) are permitted."  Yes?  Can you say it that way, or in some other, clearer way?

  M: The most significant bit of the first octet is an extension flag.
      The field MUST be present if the I bit is equal to one.  If set
      the PictureID field MUST contain 16 bits else it MUST contain 8
      bits including this MSB, see PictureID.

This is a little disconnected: the second sentence makes the antecedent of the third sentence unclear.  The third sentence appears to have something to do with the I bit.

In fact, I think the whole explanation of the extension fields would be better off with each extension field clearly separated out.  Something like this (if I may indulge in some suggested re-wording):

-------------------

  After the extension bit field follow the extension data fields that
  are enabled.

  The PictureID extension:
      If the I bit is set to one, the PictureID extension field MUST be
      present, and MUST NOT be present otherwise.  The field consists of
      two parts:

      M: The most significant bit of the first octet is an extension flag.
        If M is set, the remainder of the PictureID field MUST contain
        15 bits, else it MUST contain 7 bits.

      PictureID:  7 or 15 bits (not including the M bit).  This is a
        running index of the frames, which SHOULD begin as a random
        number, MUST increase by 1 for each subsequent frame, and MUST
        wrap to 0 after reaching the maximum ID (all bits set).  The
        7 or 15 bits of the PictureID go from most significant to
        least significant, beginning with the first bit after the M bit.
        The sender chooses a 7 or 15 bit index and sets the M bit
        accordingly.

  The TL0PICIDX extension:
      If the I bit is set to one, the TL0PICIDX extension field MUST be
      present, and MUST NOT be present otherwise.  The field consists of
      one part:

      TL0PICIDX:  8 bits temporal level zero index.  TL0PICIDX is a
        running index for the temporal base layer frames, i.e., the
        frames with TID set to 0.  If TID is larger than 0, TL0PICIDX
        indicates which base layer frame the current image depends on.
        TL0PICIDX MUST be incremented when TID is 0.  The index SHOULD
        start on a random number, and MUST restart at 0 after reaching
        the maximum number 255.

  The TID/KEYIDX extension:
      ...etc...

-------------------

-- Section 4.3 --

  The beginning of an encoded VP8 frame is referred to as an
  "uncompressed data chunk" in [RFC6386], and co-serve as payload
  header in this RTP format.

"co-serve"?  What's that mean?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-payload-vp8-08.  Authors should review
the comments and/or questions below.  Please report any inaccuracies
and respond to any questions as soon as possible.

We understand that, upon approval of this document, there is a single
action which we must complete.

In the Video Media Types registry located at:

http://www.iana.org/assignments/media-types/video

a new media type will be registered as follows:

Type: VP8
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed
upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for VP8 Video) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Payloads
WG (payload) to consider the following document:
- 'RTP Payload Format for VP8 Video'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo describes an RTP payload format for the VP8 video codec.
  The payload format has wide applicability, as it supports
  applications from low bit-rate peer-to-peer usage, to high bit-rate
  video conferences.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1622/

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Standards track as indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the RTP payload format for the VP8 video codec.
The VP8 codec supports various applications ranging from low-bitrate
peer-to-peer to high-bitrate videoconferencing applications.

Working Group Summary

The WGLC process was run twice and bunch of comments were addressed in
the latest version. After the second WGLC, there were some comments
submitted by Cullen Jennings and one of the authors responded in the list.
At this time, we are proceeding with publication request. If there are
further comments, they can be submitted during the IETF LC.

Document Quality

The VP8 codec has been used in various applications (most notably by
Google). Earlier versions of codec were used by Skype. The media subtype
registration review was request on 11/28/2012.

Personnel

Ali Begen is the document shepherd. Robert Sparks is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd reviewed the latest version (-08) and there are no issues.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

Not at this point.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Nope.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There is one IPR submission from Vidyo (IPR 1622). The WG did not have
concerns about this IPR submission.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Several people reviewed this document, mostly who are interested in
implementing this payload. There were no objections from the rest of the
WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Nope.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are a few ID nits.

1) Unused reference: RFC 3984
2) Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)
3) Downref: Normative reference to an Informational RFC: RFC 6386

There are also a few minor errors. For example, the subtype has 3 (not 2)
optional parameters.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Media subtype registration review was requested:
http://www.ietf.org/mail-archive/web/media-types/current/msg00455.html

(13) Have all references within this document been identified as
either normative or informative?

No, which means all references will be considered as "normative".

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Nope.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There is a downref to RFC 6386, which is the main RFC that describes the
VP8 data format. That RFC is an informational one since it was an
independent submission (not thru a WG).

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No changes to existing documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The media subtype registration is compliant with the registration
template (RFC 6838).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language considerations.