Last Call Review of draft-ietf-payload-rtp-ancillary-06

Request Review of draft-ietf-payload-rtp-ancillary
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-11-03
Requested 2016-10-22
Authors Thomas Edwards
Draft last updated 2016-11-03
Completed reviews Genart Last Call review of -06 by Christer Holmberg (diff)
Secdir Last Call review of -06 by Shawn Emery (diff)
Opsdir Last Call review of -06 by Nevil Brownlee (diff)
Genart Last Call review of -10 by Christer Holmberg (diff)
Assignment Reviewer Nevil Brownlee 
State Completed Snapshot
Review review-ietf-payload-rtp-ancillary-06-opsdir-lc-brownlee-2016-11-03
Reviewed rev. 06 (document currently at 14)
Review result Has Nits
Review completed: 2016-11-03


Hi all:

I have performed an Operations Directorate review of

  "This memo describes an RTP Payload format for SMPTE Ancillary data,
   as defined by SMPTE ST 291-1.  SMPTE Ancillary data is generally used
   along with professional video formats to carry a range of ancillary
   data types, including time code, Closed Captioning, and the Active
   Format Description (AFD)."

This draft is a protocol specification for a particular (but very
general) kind of payload carried in an RTP stream.  It is clearly
written and easy to follow, but it does assume that the reader
understands - more or less - how video is encoded in a video stream.

In section 2.1, the phrase 'start of active video (SAV)' is used to
define SAV.  A little more explanation of SAV would help readers
who are unfamiliar with video encoding.

The Data_Count field is clearly explained, but I'm left puzzled.
If bit 8 is an even-parity bit for bits 7-0, and bit 9 is the Logical
NOT of bit8, why do you need to have two parity bits?

Still in section 2.1, the second-to-last paragraph is an 'Operations'
comment about suitable values for "the amount of time between when an
ANC data packet becomes available to a sender and the emission of an
RTP payload containing that ANC data packet."  Is that a parameter
that needs to be set somewhere, or just a helpful implementation
comment?  I suspect it's the latter of those.

There's another 'Operations' comment in section 3.1, Media Type
Definition, under Interoperability.  It points out that - essentially
- all equipment a single Operator uses to carry video stream should
implement the same set of smpte291 features.

Section 3.2 is 'Mapping to SDP';  I presume that's the Session
Description Protocol, RFC 4566?  If so, it wrongly refers to RFC 4855,
which describes something other than SDP.  That needs to be corrected.

Last, a tiny typo in sectoion 3.3:
  'may with to receive' should be 'may wish to receive'

Overall this is a straightforward document, I believe it's ready
to publish, apart from changes in response to my comments above.

Cheers, Nevil

 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand