RTP Payload Format for VP9 Video
draft-ietf-payload-vp9-16

[Ballot comment]
Thanks for addressing my Discuss point, and comments!
I spotted a few maybe nits in the -14 while reviewing the diff.

Section 3

  A Picture Group is a recurring pattern of spatial and temporal
  dependencies which In this mode, each packet has an index to refer to

Looks like an editing remnant up to "In this mode".

Section 4.2

  I:  Picture ID (PID) present.  When set to one, the OPTIONAL PID MUST
      be present after the mandatory first octet and specified as below.
      Otherwise, PID MUST NOT be present.  If the V bit was set in the
      stream's most recent start of a keyframe (i.e. the SS field was
      present, and non-flexible scalability mode is in use), then this
      bit MUST be set on every packet.

I may (still?) be confused, but I think the "non-flexible scalability mode is
in use" belongs outside the parentheses, as it's an additional separate
precondition from "V bit is set" for "this bit MUST be set".  That is, IIUC,
non-flexible scalability mode requires SS and requires PIDs in every packet,
but it's permitted to send SS in flexible scalability mode, and in the latter
case it's permitted (but unexpected?) to omit PIDs from (some) packets.

Section 4.2.1

  In a scalable stream sent with a fixed pattern, the SS data SHOULD be
  included in the first packet of every key frame.  This is a packet
  with P bit equal to zero, SID or Lis not the bit equal to zero, and B
  bit equal to 1.  [...]

I think there's some editing churn here as well, at least a space in "L is"
but possibly more qualifiers about SID being zero vs L being the bit equal to
zero.

[Ballot comment]
There is a normative reference to a non-SDO document that was not specifically identified during the IETF Last Call.  BCP 97 doesn't give specific guidance about handling a document that was not produced by any SDO.

The IESG discussed this and chose to approve it without a second Last Call, since in this case the reference appears to be in good shape and stable.  The IESG will also take up an action item to amend BCP 97 to include guidance for this pattern to ease handling of future cases.

[Ballot comment]
There is a normative reference to a non-SDO document that was not specifically identified during the IETF Last Call.  BCP 97 doesn't give specific guidance about handling a document that was not produced by any SDO.

The IESG discussed this and chose to approve it, since in this case the reference appears to be in good shape and stable.  The IESG will also take up an action item to amend BCP 97 to include guidance for this pattern to ease handling of future cases.

[Ballot discuss]
The Chroma Subsampling values it the table 3 of this memo does not matche with the referenced section 7.2 of [VP9-BITSTREAM].

Profile 1 and Profile 3, have the same error on the entries of chrome subsampling column of table 3 of this memo. Both has the entry of 4:2:0 instead of the entry in section 7.2 of [VP9-BITSTREAM] which is 4:2:2

I would like to know if this is intentional and if yes why is that.  Otherwise it might be an editorial mistake. However, putting a discuss to clarify it as this will lead to anomaly and confusion.

[Ballot discuss]
Hopefully trivial to resolve, but in Table 3 where we claim to reproduce
the capabilities of coding profiles, defined in section 7.2 of
[VP9-BITSTREAM], I do not think we did so faithfully.  In particular, in
the last line, our table has:

  +---------+-----------+-----------------+--------------------------+
  |    3    |  10 or 12 |      Yes      | YUV 4:2:0,4:4:0 or 4:4:4 |
  +---------+-----------+-----------------+--------------------------+

but I'm seeing 4:2:2 (not 4:2:0) in [VP9-BITSTREAM].

[Ballot comment]
Section 3

  Layers are designed (and MUST be encoded) such that if any layer, and
  all higher layers, are removed from the bitstream along either of the
  two dimensions, the remaining bitstream is still correctly decodable.

Just to check my understanding: the "two dimensions" here are "temporal"
and "spatial"?  ("dimensions" can of course also refer to the x and y
coordinates of a image, but that doesn't seem to make sense here.)

  and helps it understand the temporal layer structure.  Since this is
  signaled in each packet it makes it possible to have very flexible
  temporal layer hierarchies and patterns which are changing
  dynamically.

I'm not sure what type of "patterns" are being referred to here.  (The
word "pattern" does not appear in the VP9 spec.)

  (Note: A "Picture Group", as used in this document, is not the same
  thing as a the term "Group of Pictures" as it is traditionally used
  in video coding, i.e. to mean an independently-decoadable run of
  pictures beginning with a keyframe.)

Please give a clear definition for how "Picture Group" is used by this
document and follow that with the note about differing from "Group of
Pictures".  That said, we only seem to use the term a handful of
times...

Section 4.1

    |                              : VP9 pyld hdr  |              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              |
    |                                                              |
    +                                                              |
    :                  Bytes 2..N of VP9 payload                  :
    |                                                              |
    |                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is the "2" in "2..N" because byte 1 is on the previous line?  since
there's not a horizontal boundary in this version of the figure, can we
just say "VP9 payload" here?

Section 4.2

  I:  Picture ID (PID) present.  When set to one, the OPTIONAL PID MUST
      be present after the mandatory first octet and specified as below.
      Otherwise, PID MUST NOT be present.  If the SS field was present
      in the stream's most recent start of a keyframe (i.e., non-
      flexible scalability mode is in use), then the PID MUST also be
      present in every packet.

(I assume that the "SS field was present" condition is not a route to
ignoring the I bit but rather a constraint on when the I bit is set.  I
would hope that this is sufficiently obvious to go without saying...)

  Picture ID (PID):  Picture ID represented in 7 or 15 bits, depending
      on the M bit.  This is a running index of the pictures.  The field
      MUST be present if the I bit is equal to one.  If M is set to
      zero, 7 bits carry the PID; else if M is set to one, 15 bits carry
      the PID in network byte order.  The sender may choose between a 7-
      or 15-bit index.  The PID SHOULD start on a random number, and
      MUST wrap after reaching the maximum ID (0x7f or 0x7fff depending
      on the index size chosen).  The receiver MUST NOT assume that the
      number of bits in PID stay the same through the session.

There's perhaps an edge case here where the PID goes from taking 15 bits
to taking 7 and then taking 15 again in the same session.  On the 7->15
transition, are the endpoints required to preserve the full 15-bit
state/phase from the previous incarnation?  That is, must the local
representation always have at least 15 bits and track wraparounds of the
7-bit counter if used on the wire?

      P_DIFF:  The reference index (in 7 bits) specified as the relative
        PID from the current picture.  For example, when P_DIFF=3 on a
        packet containing the picture with PID 112 means that the
        picture refers back to the picture with PID 109.  This

Just to check: is a P_DIFF of zero invalid or interpreted as "subtract
256"?

      G set to 0 or N_G set to 0 indicates that either there is only one
      temporal layer or no fixed inter-picture dependency information is
      present going forward in the bitstream.

These map up to each other, right -- G==0 iff only one temporal layer,
and N_G==0 iff no *fixed* inter-picture dependency?  The current wording
with "A or B indicates X or Y" is a bit ambiguous about what is implied
by what.

Section 5.1

  to the sender.  The message body (i.e., the "native RPSI bit string"
  in [RFC4585]) is simply the PictureID of the received frame.

Does it matter if the PictureID uses the 7-bit or 15-bit form?
(Also, we spelled "Picture ID" with a space in §4.2.)
https://datatracker.ietf.org/doc/html/rfc4585#section-6.3.3.2 seems to
confirm that a non-multiple-of-8 bit count is fine in this field.

  Note: because all frames of the same picture must have the same
  inter-picture reference structure, there is no need for a message to
  specify which frame is being selected.

This note is a little confusing to me, since the previons discussion is
only about having received an entire *frame*, but sending the Picture ID
would seem to acknowledge the entire *picture*, possibly having not
received some of the component frames.

Section 5.3

  referenced.  Therefore it's recommended for both the flexible and the
  non-flexible mode that, when upgrade frames are being encoded in

Where is "upgrade frame" defined?  (In §4.2 for the U bit we talk only
about the "switching up point".)

Section 8

Is there anything interesting to say about missing/incorrect
begin/end-of-frame markers (that might diverge in the RTP payload
descriptor from the actual encoded bitstream)?

NITS

Section 4.2

  V:  Scalability structure (SS) data present.  When set to one, the

Is there a mnemonic for how 'V' got its name?

  Z:  Not a reference frame for upper spatial layers.  If set to 1,
      indicates that frames with higher spatial layers SID+1 of the
      current and following pictures do not depend on the current

Something about the way this is written makes me want to read "layers"
as indicating "and higher layers", not just the immediate SID+1.  Maybe
"frame with the next higher spatial layer SID+1"?

      Note that for a given picture, all frames follow the same inter-
      picture dependency structure.  However, the frame rate of each
      spatial layer can be different from each other and this can be
      controlled with the use of the D bit described above.  The

"controlled" may not be quite the right word here, as in order to have
higher-frame rate at a given (non-base) layer, the "off" frames have to
use a 'D' of zero, but the converse is not necessarily true.

  In a scalable stream sent with a fixed pattern, the SS data SHOULD be
  included in the first packet of every key frame.  This is a packet
  with P bit equal to zero, SID or D bit equal to zero, and B bit equal

(If SID is zero, D is also zero, so from an information-theoretic (but
not human usability) point of view, we could just say "D bit equal to
zero".)

Setion 4.4

  legitimately be removed from the stream.  Thus, a frame that follows
  a removable frame (in full decode order) MUST be encoded with
  "error_resilient_mode" set to true.

This is the only instance of the word "removable" in the document, so
I'd suggest using a phrasing that does not imply a defined term, like "a
frame that directly follows a frame that might be removed".

Section 5.3

  Identification of a layer refresh frame can be derived from the
  reference IDs of each frame by backtracking the dependency chain
  until reaching a point where only decodable frames are being
  referenced.  [...]

This description leaves me a bit unclear on what exactly the receiver
concludes is a layer refresh frame.  (What dependencies could there be
from the frame sent in response to LRR?)

  response to a LRR, those packets should contain layer indices and the
  reference fields so that the decoder or an MCU can make this
  derivation.

Maybe "field(s)" since only one P_DIFF is an allowed state?

Section 8

  RTP packets using the payload format defined in this specification
  are subject to the security considerations discussed in the RTP
  specification [RFC3550], and in any applicable RTP profile such as
  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/
  SAVPF [RFC5124].  SAVPF [RFC5124].  However, as "Securing the RTP

duplicate "SAVPF [RFC5124]"

[Ballot comment]
Thank you for this document. I'll happily note that there is lots in it that I don't understand (and needs lots of background knowledge), but it seems fine from an Ops side.

[Ballot comment]
Thank you to Rifaat Shekh-Yusef for the SECDIR review.

** Section 8. Thanks for mentioning the denial of service via computational complexity issue.  Since the VP9 spec doesn’t say it, but other codec documents typically do (RFC6386 and draft-ietf-cellar-ffv1), please also considering adding a comment about processing un-trusted input.  Roughly:

OLD
  This RTP payload format and its media decoder do not exhibit any
  significant non-uniformity in the receiver-side computational
  complexity for packet processing, and thus are unlikely to pose a
  denial-of-service threat due to the receipt of pathological data.
  Nor does the RTP payload format contain any active content.

NEW
Implementations of this RTP payload format need to take appropriate security considerations into account.  It is extremely important for the decoder to be robust against malicious payloads and ensure that they do not cause the decoder to overrun its allocated memory.  An overrun in allocated memory could lead to arbitrary code execution by an attacker.  The same applies to the encoder, even though problems in encoders are typically rarer. 

This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data.  Nor does the RTP payload format contain any active content.

** Nits

-- Section 3.  Editorial.  Per “Layers are designed (and MUST be encoded) …”, it seems odd to have normative language as a parenthetical.

-- Section 3.  Editorial.  s/a the term/the term/

-- Section 6.1.2. Typo. s/ capabilties/ capabilities/

[Ballot comment]
Thank you for the work on this document.

I have some non blocking questions and comments, which I hope will help improve the document.

Francesca

1. -----

  Timestamp:  The RTP timestamp indicates the time when the input frame
      was sampled, at a clock rate of 90 kHz.  If the input picture is
      encoded with multiple layer frames, all of the frames of the
      picture MUST have the same timestamp.

FP: I think it would be useful to add a reference to RFC 3550, regarding "RTP timestamp". Also, I find it curious that RFC 3550 is not mentioned up to the end of section 4.1 (I would think a reference to it would be present in the introduction)

2. -----

      Otherwise, PID MUST NOT be present.  If the SS field was present
      in the stream's most recent start of a keyframe (i.e., non-
      flexible scalability mode is in use), then the PID MUST also be
      present in every packet.

FP: Is there any reason why this is not formulated in terms of V bit being set? (I believe the rest of the text is consistently talking about bit being set)

3. -----

      described by "Reference indices" below.  This MUST only be set to
      1 if the I bit is also set to one; if the I bit is set to zero,
      then this MUST also be set to zero and ignored by receivers.  The

FP: Why is that the it MUST only be set to 1 if I is also set to 1? I was looking for the motivation, but could not find it. Some more text would have been helpful to me.

4. -----


  Z:  Not a reference frame for upper spatial layers.  If set to 1,
      indicates that frames with higher spatial layers SID+1 of the
      current and following pictures do not depend on the current

FP: I am not sure if the text it meant to say higher spatial layers than SID+1 (inclusive?)

5. -----

    The field MUST be present if the I bit is equal to one.  If set,
      the PID field MUST contain 15 bits; otherwise, it MUST contain 7

FP: "If set" - I understand by the context this should be "If M is set" (how it's written now it could be interpreted by "if the PID field is set", which does not make sense, but better be clear)

6. -----

      or 15-bit index.  The PID SHOULD start on a random number, and
      MUST wrap after reaching the maximum ID (0x7f or 0x7fff depending
      on the index size chosen).  The receiver MUST NOT assume that the

FP: So is the intention that the PID is increased by one for each picture? Does the order matter? The way the text is written "reaching the maximum ID" would suggest so, but I could not find any text about that, if I have missed it please let me know.

7. -----

      SID-1 frame of the same picture, otherwise MUST set to zero.

FP: s/MUST set/MUST be set

8. -----

        depends on.  TL0PICIDX MUST be incremented when TID is equal to
        0.  The index SHOULD start on a random number, and MUST restart

FP: Does it matter by how much? If so, it should be stated.

9. -----

      temporal layer ID (TID), switch up point (U), and the R reference
      indices (P_DIFFs) are specified.

FP: I couldn't find the R bit defined anywhere. I assume its meaning is "if set, P_DIFF is present" but this should be clearly stated in the text.

10. -----

FP: Please expand MCU, LRR on first use

11. -----

Section 7. IANA

FP: I checked the mailarchive for the subtype registration and could not find it. I leave it to Murray to let me know if we are more lenient about subtype requests, but I would have appreciated the registration being posted to the media-types mailing list.

[Ballot comment]
Thank you for the work put into this document.

I have only one minor comment about section 4.1: please expand "VP9 pyld hdr" somewhere in the text.

-éric

[Ballot discuss]
Section 12.1, paragraph 13, discuss:
>    [VP9-BITSTREAM]
>              Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream &
>              Decoding Process Specification", Version 0.6, 31 March
>              2016,
>                              docs/vp9/vp9-bitstream-specification-
>              v0.6-20160331-draft.pdf>.

This is a DOWNREF that wasn't called out in the IETF last call, so the IESG
needs to approve this. (There is no action for the editors here, I'm adding this
so we don't forget this on the telechat.)

[Ballot comment]
It's very unfortunate that VP9 isn't published as an RFC as VP8 was -
I'm somewhat concerned about the stability of this reference, esp. given its
importance. Then again, it's apparently been accessible since 2016.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 14, nit:
-    in video coding, i.e. to mean an independently-decoadable run of
-                                                      -
+    in video coding, i.e. to mean an independently-decodable run of

Section 5.3, paragraph 5, nit:
-    ingnored on reception.  See Section 4.2 for details on the TID and
-    -
+    ignored on reception.  See Section 4.2 for details on the TID and

Section 6.1.2, paragraph 5, nit:
-      its declared receiver capabilties.
+      its declared receiver capabilities.
+                                    +

Section 3, paragraph 12, nit:
>  document, is not the same thing as a the term "Group of Pictures" as it is t
>                                    ^^^^^
Maybe you need to remove one determiner so that only "a" or "the" is left.

Section 4.2, paragraph 6, nit:
> s present for the layer indices. Otherwise if the F bit is set to 0 (indicat
>                                  ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 4.2, paragraph 15, nit:
> d in this specification is different than a VP9 Superframe. All frames of the
>                                      ^^^^
Did you mean 'different "from"? 'Different than' is often considered colloquial
style.

Section 4.5.1, paragraph 3, nit:
> ble frames are being referenced. Therefore it's recommended for both the fle
>                                  ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 6.1.1, paragraph 5, nit:
> TP in general. This responsibility lays on anyone using RTP in an application
>                                    ^^^^^^^
Did you mean "lies on"?

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/rtp-parameters

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

The IANA Functions Operator has completed its review of draft-ietf-payload-vp9-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the video registry on the Media Types registry page located at:

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

a single new registration will be made as follows:

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

Second, in the RTP Payload Format Media Types registry on the Real-Time Transport Protocol (RTP) Parameters registry page located at:

https://www.iana.org/assignments/rtp-parameters/

a single new registration will be made as follows:

Media Type: video
Subtype: VP9
Clock Rate:
Channels:
Reference: [ RFC-to-be ]

IANA Question --> Should there be a value for clock rate for this registration?

The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-05-21):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-payload-vp9@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for VP9 Video) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document: - 'RTP Payload
Format for VP9 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
last-call@ietf.org mailing lists by 2021-05-21. 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 specification describes an RTP payload format for the VP9 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.  It includes provisions for temporal and spatial
  scalability.




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


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

  https://datatracker.ietf.org/ipr/4496/
  https://datatracker.ietf.org/ipr/4497/
  https://datatracker.ietf.org/ipr/4491/
  https://datatracker.ietf.org/ipr/2593/

Draft Request for Publication
April 1, 2021

Document:  RTP Payload Format for VP9 Video
Link: https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba
WG: AVTCORE

(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?

Publication as a Proposed Standard is requested. The VP9 Payload draft was a PAYLOAD WG work item, is now widely deployed.

(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 describes an RTP payload specification applicable to the
  transmission of video streams encoded using the VP9 video codec
  [VP9-BITSTREAM].  The format described in this document can be used
  both in peer-to-peer and video conferencing applications.

  The VP9 video codec was developed by Google, and is the successor to
  its earlier VP8 [RFC6386] codec.  Above the compression improvements
  and other general enhancements above VP8, VP9 is also designed in a
  way that allows spatially-scalable video encoding.

Working Group Summary:

Recent discussion of the VP9 payload format has centered on support for framemarking as well as some SDP questions. 
Since framemarking does not support some popular spatial scalability modes (e.g. K-SVC), support for framemarking has
not caught on, and framemarking support was recently removed from the webrtc.org distribution. As a result, a section
on framemarking has been removed from the VP9 RTP payload specification.

Document Quality:

The VP9 RTP payload format is widely deployed, as part of the webrtc.org distribution. This includes implementations in browsers as well as mobile, tablet and desktop applications.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Bernard Aboba is the Document Shepard. Responsible AD is Murray Kutcheraway.

(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 Document Shepard has reviewed the document as part of WGLC, and made comments that were subsequently addressed by the authors.

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

No concerns.

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

No additional reviews appear to be needed. The document has already been reviewed by a member of the SDP Directorate (Christer Holmberg).

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

No concerns.

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

IPR disclosures have been filed:

2020-11-23 4497 Nokia Technologies Oy's Statement about IPR related to draft-ietf-payload-vp9
(Updates ID#: 4496)
2020-11-23 4496 Nokia Technologies Oy's Statement about IPR related to draft-ietf-payload-vp9
2020-11-20 4491 Nokia Technologies Oy's Statement about IPR related to draft-ietf-payload-vp9
2015-05-04 2593 Vidyo, Inc.'s Statement about IPR related to draft-uberti-payload-vp9

A summary of the disclosures was sent to the WG mailing list on 2 March 2021:
https://mailarchive.ietf.org/arch/msg/avt/j4I6D0rvpdv51Vb4w2OAF7cpdPY/

The disclosures were also brought up at the IETF 110 AVTCORE WG meeting.

No objections to proceeding with the publication of the VP9 document were raised either on the mailing list or at the IETF 110 meeting.

(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?

The WG has multiple participants who have been involved in the development and deployment of the VP9 RTP payload format. This includes participants who developed the webrtc.org implementation as well as participants who have developed applications supporting VP9.  Given this experience, WG understanding of the VP9 payload format is good and consensus is solid.

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

There have been no heated discussions or indication of extreme (or even mild) discontent. No threats of an appeal.

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

idnits 2.16.05


tmp/draft-ietf-payload-vp9-12.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

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

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VP9-BITSTREAM'


    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

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

The document includes a Media Type Definition (Section 6.1).

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

References are separated into normative and informative categories.

(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?

The document includes a normative reference to the VP9 Bitstream specification that is not an IETF document:

  [VP9-BITSTREAM]
              Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream &
              Decoding Process Specification", Version 0.6, 31 March
              2016,
              .

(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 reference to the LRR draft:

  [I-D.ietf-avtext-lrr]
              Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
              Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
              Message", Work in Progress, Internet-Draft, draft-ietf-
              avtext-lrr-07, 2 July 2017, .


(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 the status of existing RFCs.

(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 8126).

I have reviewed the Media Type Definition (Section 6.1). It appears consistent with the rest of the document.

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

The Media Type Definition (Section 6.1) will require review.

(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, YANG modules, etc.

No formal languages.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.

Draft Request for Publication
April 1, 2021

Document:  RTP Payload Format for VP9 Video
Link: https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba
WG: AVTCORE

(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?

Publication as a Proposed Standard is requested. The VP9 Payload draft was a PAYLOAD WG work item, is now widely deployed.

(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 describes an RTP payload specification applicable to the
  transmission of video streams encoded using the VP9 video codec
  [VP9-BITSTREAM].  The format described in this document can be used
  both in peer-to-peer and video conferencing applications.

  The VP9 video codec was developed by Google, and is the successor to
  its earlier VP8 [RFC6386] codec.  Above the compression improvements
  and other general enhancements above VP8, VP9 is also designed in a
  way that allows spatially-scalable video encoding.

Working Group Summary:

Recent discussion of the VP9 payload format has centered on support for framemarking as well as some SDP questions. 
Since framemarking does not support some popular spatial scalability modes (e.g. K-SVC), support for framemarking has
not caught on, and framemarking support was recently removed from the webrtc.org distribution. As a result, a section
on framemarking has been removed from the VP9 RTP payload specification.

Document Quality:

The VP9 RTP payload format is widely deployed, as part of the webrtc.org distribution. This includes implementations in browsers as well as mobile, tablet and desktop applications.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Bernard Aboba is the Document Shepard. Responsible AD is Murray Kutcheraway.

(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 Document Shepard has reviewed the document as part of WGLC, and made comments that were subsequently addressed by the authors.

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

No concerns.

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

No additional reviews appear to be needed. The document has already been reviewed by a member of the SDP Directorate (Christer Holmberg).

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

No concerns.

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

IPR disclosures have been filed:

2020-11-23 4497 Nokia Technologies Oy's Statement about IPR related to draft-ietf-payload-vp9
(Updates ID#: 4496)
2020-11-23 4496 Nokia Technologies Oy's Statement about IPR related to draft-ietf-payload-vp9
2020-11-20 4491 Nokia Technologies Oy's Statement about IPR related to draft-ietf-payload-vp9
2015-05-04 2593 Vidyo, Inc.'s Statement about IPR related to draft-uberti-payload-vp9

A summary of the disclosures was sent to the WG mailing list on 2 March 2021:
https://mailarchive.ietf.org/arch/msg/avt/j4I6D0rvpdv51Vb4w2OAF7cpdPY/

The disclosures were also brought up at the IETF 110 AVTCORE WG meeting.

No objections to proceeding with the publication of the VP9 document were raised either on the mailing list or at the IETF 110 meeting.

(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?

The WG has multiple participants who have been involved in the development and deployment of the VP9 RTP payload format. This includes participants who developed the webrtc.org implementation as well as participants who have developed applications supporting VP9.  Given this experience, WG understanding of the VP9 payload format is good and consensus is solid.

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

There have been no heated discussions or indication of extreme (or even mild) discontent. No threats of an appeal.

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

idnits 2.16.05


tmp/draft-ietf-payload-vp9-12.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

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

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VP9-BITSTREAM'


    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

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

The document includes a Media Type Definition (Section 6.1).

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

References are separated into normative and informative categories.

(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?

The document includes a normative reference to the VP9 Bitstream specification that is not an IETF document:

  [VP9-BITSTREAM]
              Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream &
              Decoding Process Specification", Version 0.6, 31 March
              2016,
              .

(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 reference to the LRR draft:

  [I-D.ietf-avtext-lrr]
              Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
              Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
              Message", Work in Progress, Internet-Draft, draft-ietf-
              avtext-lrr-07, 2 July 2017, .


(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 the status of existing RFCs.

(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 8126).

I have reviewed the Media Type Definition (Section 6.1). It appears consistent with the rest of the document.

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

The Media Type Definition (Section 6.1) will require review.

(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, YANG modules, etc.

No formal languages.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.