Subject: Re: [payload] Warren Kumari's No Objection on draft-ietf-payload-rtp-ancillary-10: (with COMMENT)

From: Thomas Edwards <[email-masked]>
Date: Sat, 23 Sep 2017 10:20:20 +0000

Warren,

Thanks for your comments on draft-ietf-payload-rtp-ancillary.

I want to be sure that I address the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-payload-rtp-ancillary-06-opsdir-lc-brownlee-2016-11-03/)  Somehow, I think I missed this in the -06 version, sorry!

1) “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.”

Start of active video (SAV) is a digital synchronizing sequence present in SDI interfaces that defines the start of active video on the line, where “active video” is the video intended to be conveyed to the viewer, as opposed to parts of the video raster which are “ancillary space”.  I can add a bit of definition to the document.

2) “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?”

That is how SMPTE defined the Data Count field of Ancillary data packets in SMPTE ST 291-1 (I’m sure they had a good reason, before my time though).  This payload attempts to allow the Ancillary data packet to be carried in the RTP payload just as it is on the SDI wire.

3) “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.”

That was a consensus opinion on an implementation.  It was felt that parameterizing this would not provide much value and could be confusing.

4) “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.”

The text is:

“Interoperability considerations: Data items in smpte291 can be very diverse. Receivers might only be capable of interpreting a subset of the possible data items. Some implementations might care about the location of the ANC data packets in the SDI raster, but other implementations might not care.”

I’m not sure what the comment is addressing.  Different devices may be interested in receiving different ANC data packet types. 

5) “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.”

Section 3.2 was moved to Section 4  “SDP Considerations” in the -10 version.  RFC 4855 is “Media Type Registration of RTP Payload Formats” and Section 3 of that document is “Mapping to SDP Parameters”.

6) “Last, a tiny typo in section 3.3:  'may with to receive' should be 'may wish to receive'”

This typo has been corrected between -6 and -10 versions.

-Thomas

-- 
Thomas Edwards
FOX Networks Engineering & Operations
VP Engineering & Development
[email-masked]
+1-310-369-6696
10201 W Pico Blvd
Los Angeles, CA 90035

On 8/8/17, 6:34 AM, "payload on behalf of Warren Kumari" <[email-masked] on behalf of [email-masked]> wrote:

    Warren Kumari has entered the following ballot position for
    draft-ietf-payload-rtp-ancillary-10: No Objection
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dietf-2Dpayload-2Drtp-2Dancillary-2D06-2Dopsdir-2Dlc-2Dbrownlee-2D2016-2D11-2D03_&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=-qtudoRalX1j1BbCiSm78Jbko_QKbcqMvUJdiqfxeSI&s=YWhyxt_G7s8m9lBm2YGy9R4ymb6Zvb2fQDjyi8R9JFI&e= 

    _______________________________________________
    payload mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=-qtudoRalX1j1BbCiSm78Jbko_QKbcqMvUJdiqfxeSI&s=7mMyMVD16Qkx8-NAFPCGr1I211stSGLARLivLkrbtDs&e=