Skip to main content

Last Call Review of draft-ietf-payload-vp8-17

Request Review of draft-ietf-payload-vp8
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-07-13
Requested 2015-07-02
Authors Patrik Westin , Henrik Lundin , Michael Glover , Justin Uberti , Frank Galligan
I-D last updated 2015-09-11
Completed reviews Genart Last Call review of -08 by Elwyn B. Davies (diff)
Genart Telechat review of -09 by Elwyn B. Davies (diff)
Genart Telechat review of -16 by Elwyn B. Davies (diff)
Genart Last Call review of -17 by Elwyn B. Davies
Secdir Last Call review of -08 by Brian Weis (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-payload-vp8 by General Area Review Team (Gen-ART) Assigned
Reviewed revision 17
Result Ready w/nits
Completed 2015-09-11
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-payload-vp8-17.txt
Reviewer: Elwyn Davies
Review Date: 2015/09/11
IETF 2nd LC End Date: 2015/07/13
IESG Telechat date: 2015/09/17

Summary: Ready with minor nits.  Thanks for addressing nearly all my 

comments from the 2nd LC review.  The remaining two points are noted 

below. THere is also a point made elsewhere about the Media Type 


Major issues:

Minor issues:

s4.2: The consequences of not starting PictureID and/or TL0PICIDX at 

random values (and/or the rationale for starting at random values) is 

not discussed.

Nits/editorial comments:

s4.2: I still consider it undesirable to have two pairs of bit fields 

with the same name (X and M).  Flagging that they are duplicates helps a 

bit but where the values are referred to elsewhere ambiguity remains 

about which of the fields is implied.


       These parameters are used to signal the capabilities of a receiver
       implementation.  If the implementation is willing to receive
       media, both parameters MUST be provided.  These parameters MUST
       NOT be used for any other purpose.

The latter two sentences would be better placed in s.6.