[payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

[Thomas Edwards <[e-mail]>]

IETF Payload WG WGLC (#2) for draft-ietf-payload-rtp-ancillary-08
4 April to 19 April 2017

Below are the comments and my responses to those comments.

Commenter: Kjetil Oftedal <[e-mail]> Sat, 01 April 2017 09:46 UTC

there might still be need for clarification here on the definition of field.
With 3G-level B DL(dual link)/HD DL the SDI transport format is basically a
interlaced format. But the video format is likely to be 50-60Hz progressive.
(Two concurrent interlaced fields is merged to one progressive frame)
Since this draft is uses link/SDI raster level line numbers, it should
be specified that it is the link level video format that defines whether or not this
is interlaced transport.

Reply:
appending the “F” (field) description with:

“Note that some multi-link SDI interfaces may use multiple interlaced signals to transmit progressive images, in which case ‘field’ would refer to the link field.”

Commenter: Roni Even <[e-mail]> Wed, 05 April 2017 08:07 UTC
I have a  comment about section 5.  The procedure is not relevant for RTSP or SAP since it is not for declarative SDP only for SIP offer/answer when there is an answerer

Reply:

Change 5.1 to:

5.1  Offer/Answer Model

   Receivers might wish to receive ANC data streams with specific DID_SDID
   parameters.  Thus when offering ANC data streams using the Session
   Description Protocol (SDP) in an Offer/Answer model [RFC3264], the
   offeror MAY provide a list of ANC streams available with specific
   DID_SDID parameters in the fmtp line.  The answerer MAY
   respond with all or a subset of the streams offered along with fmtp
   lines with all or a subset of the DID_SDID parameters offered.  Or
   the answerer MAY reject the offer.  There are no restrictions on
   updating DID_SDID parameters in a subsequent offer.

And add:

5.2.  Declarative SDP Considerations

   For declarative use of SDP, nothing specific is defined for this
   payload format.  The configuration given by the SDP MUST be used when
   sending and/or receiving media in the session.

Commenter: 
John Fletcher <[e-mail]> Thu, 20 April 2017 10:22 UTC
1) In section 2.1, definition of "C" bit, HD signals are mentioned but not UHD.  I think the definition really depends on whether the SDI interface uses separate data channels for luma and color-diff, so perhaps the specification could be re-worded along those lines.  At the very least, say "HD and UHD signals".

Reply:
Change to “For HD signals, this flag, when set to "1", indicates that the ANC data corresponds to the color-difference channel (C).”

2) Specifications about RTP timestamp clock rate appear in section 3.1 as part of the media format parameters but I think these should be in section 2 as part of the timestamp definition.  Section 3.1 should just say that the Rate parameter is required.

Reply:
This test was added to section 3.1 resolving a comment on draft-ietf-payload-rtp-ancillary-03 from Jonathan Lennox <[e-mail]> on 23 June 2016.  It is not unknown to put requirements on timestamp rates in the Media Type Definition when it is an issue that revolves around SDP description (such as association with other RTP streams).  As the document has already passed SECDIR/OPSDIR/GENART reviews, I think it is not wise to make this change in document structure.

3) Section 1, Introduction, uses normative word "should" in "It should be noted that".  I suggest changing to "Note that".

Reply:
Change to “Note that the ancillary data flag…”
[in general, I am not opposed to minor editorial changes to be precise about normative language]

4) In section 3.1, the normative word "may" is used in "implementers may care" and "may not care".  It's not appropriate to give implementers permission or to forbid them from caring.  I suggest changing to "might".

Reply:
Change to “Some implementations might care about the
   location of the ANC data packets in the SDI raster, but other
   implementations might not care.”

5) In section 3.1, "those that must interoperate with", I suggest deleting "must".

Reply:
Change to “Devices that stream real-time
   professional video, especially those that interoperate with
   legacy serial digital interfaces (SDI).”

6) In section 4, "the ancillary data stream may potentially contain", suggest changing to "might" to indicate possibility rather than permission.

Reply: 
Change to “If a DID_SDID parameter is not
   specified, then the ancillary data stream might potentially contain
   ancillary data packets of any type.”

7) In section 4.1, the normative word "may" is used in "implementers may wish to".  It's not appropriate to give implementers permission to wish.  I suggest deleting "to wish".

Reply:
To avoid any normativity, change to “To associate an ANC RTP stream with other media streams, implementers
   can use the Lip Synchronization…”

8) In section 5, again we have "may with", I think meant to be "may wish".  I suggest changing to "might wish" in this case.  Other uses of "may" in this section seem fine but should be capitalised.

Reply:
Incorporated into reply to comment from Roni Even <[e-mail]> Wed, 05 April 2017 08:07 UTC

9) In section 7, "It may still be a good idea", suggest changing "may" to "might".

Reply:
Change to “It might still be a good idea for these…”

10) In section 7, "receivers should take care to", I suggest deleting "take care to".

Reply:
Change to “To avoid potential buffer overflow attacks, receivers SHOULD validate that the ANC data packets in the RTP payload are of
   the appropriate length”

11) Some uses of "required" in the memo are not specifying normative requirements, suggest re-wording or changing to "needed".

Reply:
Change to “Ancillary space roughly corresponds to vertical and horizontal blanking periods of cathode ray tube type displays.”

Change to: “When a payload format is registered with SMPTE, it is identified by a registered data identification word.”

12) Several occurrences of "may", "must", "should", "required" and "optional" are not capitalised.

Reply:

Change to “A value of 0x7FE indicates that the ANC data is intended to be placed into any legal area of VANC, specifically.”

Change to “Note that the lines that are available to convey ANC data are as defined in the applicable sample structure specification
           (e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656
           [BT656]) and possibly further restricted per SMPTE RP 168
           [RP168].”

Change to “A value of 0xFFE indicates that the ANC data is intended to be placed into any legal area of HANC, specifically.”

Change to “The absence of the DID_SDID parameter signals that  determination of the DID and SDID of ANC packets in the payload can only
be achieved through direct inspection of ANC data packet fields.” 

Capitalize other occurrences where clearly normative.

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
[e-mail]
Phone: [phone]
10201 West Pico Blvd.
Los Angeles, CA 90035