RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data

Note: This ballot was opened for revision 10 and is now closed.

(Ben Campbell) Yes

(Deborah Brungard) No Objection

(Spencer Dawkins) No Objection

Comment (2017-08-15 for -10)
No email
send info
I wasn’t sure whether this text was giving three examples of SDIs, or two. Am I the only one who’s confused?

   ANC is generally associated with the carriage of metadata within the
   bit stream of a Serial Digital Interface (SDI) such as SMPTE ST 259
   [ST259], the standard definition (SD) Serial Digital Interface (with
   ANC data inserted as per SMPTE ST 125 [ST125]), or SMPTE ST 292-1
   [ST292], the 1.5 Gb/s Serial Digital Interface for high definition
   (HD) television applications.

Perhaps using the descriptions first in each case, and ending with the name and reference in parentheses, would be clearer?

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2017-08-08 for -10)
No email
send info
I'd like to begin by noting that I know basically nothing about SMPTE or ST 291 or Ancillary Data. I opened the document thinking that this was going to be either impenetrable, a huge waste of my time, or both...

I was very pleasantly surprised by how clear, accessible and interesting the document is -- it clearly describes the use case / problem, provides just enough background to make understanding the discussion (relatively) easy, and documents the solution / protocol in a clear and concise manner.

I'm not really qualified to evaluate if this is the best way to implement / if it has hidden landmines (see first sentence!), but I'd like to thank the author and WG for producing a document which was a pleasure to read.

I'd also like to draw your attention to Nevil's OpsDir review, which contains some good questions, and some nits: https://datatracker.ietf.org/doc/review-ietf-payload-rtp-ancillary-06-opsdir-lc-brownlee-2016-11-03/

(Mirja Kühlewind) No Objection

Comment (2017-08-15 for -10)
No email
send info
One comment at the end of section 2:
"One millisecond is a reasonable upper bound 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
While it makes sense to send out the packet as soon as possible, I'm not sure what this sentence gives you. I don't think you can guanrantee 1ms as there might be additional delays on the NIC and as such I don't think there are any actions that could follow based on this value. To avoid that anybody is taking this as a hard requirement, I would maybe rather just remove this note.

(Alexey Melnikov) No Objection

Comment (2017-08-13 for -10)
No email
send info
This is generally a well written document.

As the media type registration template in Section 3.1 is supposed to be self contained (it will be posted to IANA website as a web page), it should define (or point to) ABNF for different parameters and specify that some parameters (e.g. DID_SDID) can be repeated multiple times. I can find this information in Section 4, so please add references to section 4 in the template.

(Kathleen Moriarty) No Objection

Comment (2017-08-15 for -10)
No email
send info
Thank you for addressing the SecDir review comments.

(Eric Rescorla) No Objection

Alvaro Retana No Objection

(Adam Roach) (was Discuss) No Objection

Comment (2017-10-19 for -12)
No email
send info
Thank you for addressing my DISCUSS.