Re: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07

[John Fletcher <[e-mail]>]

Here are some comments on draft-ietf-payload-rtp-ancillary-07:


It needs to be made clear that the scope is limited to ancillary data carried over a Serial Digital Interface.
For example, in the introduction, delete:

"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."

and delete:

"This memo describes an RTP payload that supports ANC data packets regardless of whether they originate from an SD or HD interface"

and add:

"This memo describes an RTP payload that supports ANC data packets originating from or intended for a Serial Digital Interface such as SDI, HD-SDI, HD_SDI, 3G SDI, 6G SDI, 12G SDI and multiple link versions of these."


RTP header, timestamp: The term "sampling instant" needs to be clarified, particularly for playback.


Payload header, C bit: You may need more than one bit for interfaces with multiple data streams.

Cases to consider are:

SMPTE ST 259 interface;
In a SMPTE ST 292-1 HD-SDI interface, whether the ANC packets are carried in the Luma channel or the Color Difference channel;
In a SMPTE ST 425-1 3G-SDI Level B or SMPTE ST 2081-10 6G-SDI mode 1 interface, whether the ANC packets are carried in the Y/G-channel of data stream one or in the other channel and/or other data streams
In SMPTE ST 425-1 3G-SDI Level A, SMPTE ST 2081-10 6G-SDI mode 2 or SMPTE ST 2082-10 12G SDI interfaces, whether the ANC packets are carried in data stream one or in another data stream


Payload header, line number: You need to include the image format (e.g. in payload format) for the line number to make sense.


Payload format parameters: I think you need to specify the interface type and the image format


Payload format parameter, link number: I think you may also need data stream number unless use of C bit is expanded as above.


Payload format parameter, link number: The phrase "comes from" is used but the data could be "intended for"


Since IP/UDP/RTP are byte-orientated, you need to specify how 10-bit UDWs are mapped onto interface bytes.


Payload header, ANC_Count - "network byte order" is irrelevant as it is only one byte.

Payload header, Line_Number and Horizontal Offset: You need to say more that “network byte order” because these are not a multiple of 8 bits.


More normative language is needed.

There some uses of "may" in non-normative context.

A definition of network byte order is needed


Regards,
John Fletcher


From: payload [mailto:[e-mail]] On Behalf Of Thomas Edwards
Sent: 17 January 2017 20:00
To: [e-mail]
Subject: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07

Dear Payload WG,

I would like to report the following summary of changes between draft-ietf-payload-rtp-ancillary-06 and -07.  This includes comments from the IETF Last Call, as well as reviews from SECDIR, OPSDIR, and GENART.

1) Change in the details of payload bit format

Several potential implementers noted that -06 contained two reserved bits after Data_Count to 32-bit word align the User_Data_Words.  It was suggested that this unnecessarily breaks up the ANC packet bits as expressed in SDI, and moreover the reserved bits do not actually achieve 32-bit word alignment of User_Data_Words on the second and following ANC data packets carried in the payload.

After substantial input from potential implementers, the format was changed to keep the SDI ANC data packet contiguous, and to add reserved bits to ensure that the start of headers before each ANC data packet is 32-bit word aligned.

The payload format example was enlarged to clearly show the proper carriage of two ANC data packets of different lengths.
2) A Horizontal_Offset value of 0xFFE now indicates that the ANC data may be placed into any legal area of HANC, and similarly a Line_Number value of 0x7FE now indicates that the ANC data may be placed into any legal area of VANC.

3) The “C” bit is not to be ignored even if the ANC data packet is considered to be carried without any specific location within the field or frame.  ANC packets are always defined to be carried in the color difference or luma channel.

4) An optional Media Type parameter LinkNumber was added for the identification of a link number in dual and quad link SDI applications.

5) Made it clear that Multiple DID_SDID parameters do not imply any particular ordering of the different types of ANC packets in the stream.

6) Added note that the Checksum_Word is unlikely to provide a payload integrity check in case of a directed attack.

I will add that -07 has been presented to the Alliance for IP Media Solutions (AIMS) Technical Working Group, which had no substantive comments.  However, the AIMS TWG consensus was to ask for a delay in moving -07 to RFC publishing until the Video Services Forum / Joint Task Force on Networked Media interop event February 6-10 at the Fox Sports facility in Houston, TX.  The feeling was that the -07 version could be fully exercised by the participants there, and any unexpected shortcomings rapidly identified.

Based on this feedback from the AIMS TWG, I have forwarded this request to the IESG responsible AD, Ben Campbell.

-Thomas

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



----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------