Subject: Re: [payload] AD Evaluation of draft-ietf-payload-rtp-ancillary-05

From: "Ben Campbell" <[email-masked]>
Date: Tue, 04 Oct 2016 16:51:59 -0500

Hi, please see my comments (inline). I removed sections that don't seem 
to need further discussion.

Thanks!

Ben.

On 14 Sep 2016, at 14:45, Thomas Edwards wrote:

> I would like to thank the AD for the thorough evaluation!
>
> I have developed a draft-ietf-payload-rtp-ancillary-06 in response to 
> the AD evaluation, and can submit it if desired.

Please submit it when you are ready. draft versions are cheap, and it's 
easier to use the standard diff tools against a submitted draft.

[...]

>> Added in first paragraph
>
> The 6th paragraph says ancillary data flag (ADF) word is not carried 
> in
> this payload.  But
> section 2.1, under "horizontal offset" says "A value of 0 means that 
> the
> Ancillary Data
> Flag (ADF) of the ANC data packet begins immediately following SAV."
> These seem to
> conflict--are they talking about something different?
>
>> The ADF word marks the beginning of an ancillary data packet in SDI.  
>> Since the ADF may depend on the
>> particular SDI interface (SD-SDI versus HD-SDI versus 3G-SDI), we 
>> feel it is best to leave it out of the RTP
>> payload and leave it up to the device that would embed ANC packets 
>> into the SDI to determine the
>> appropriate ADF.  (Of course some applications may do away with SDI 
>> altogether and only use RTP
>> and no SDI, in which case the ADF is superfluous).

That seems to support the arugment to not carry ADF in the payload, but 
what about the second part of my comment that talks about the ADF 
payload of the ANC data? Is that _not_ part of the payload?

[...]

>
> - 3.1, Required Parameters:
> "When an ANC RTP stream is to be associated with an RTP video stream,
> the RTP timestamp
> rates SHOULD be the same to ensure that ANC data packets can be
> associated with the
> appropriate frame or field."
>
> Why not MUST? Do you anticipate that there might be situations where
> it's reasonable for
> the rates not to match?
>
>> It is possible that sometimes one might have ANC RTP streams that are 
>> logically associated via SDP
>> with video flows that have a different timestamp rate.  We do not 
>> want to encourage this, but
>> felt it was worth leaving an option to allow it.
>

Are there negative consequences if that happens? Do you end up with 
incorrectly associated ANC packets? If so, it would be helpful to 
mention it.

> -- intended usage: Is "Common" the right choice? Do you expect this to
> be widely used, or
> just in some very specific applications?
>
>> We copied RFC 4175 “Common”.  I think it is reasonable to say 
>> that this would be widely used within
>> professional video production, but perhaps rarely outside that area.  
>> Do you feel that there should be
>> different intended usage language?

No, that's probably okay.

[...]

>
> - 5: The security considerations do not include the recommended text
> from
> draft-ietf-payload-rtp-howto-14, section A.13. Should it?
>
>> Sure, and recommended text added.  I assume the references in the 
>> recommended text (such as
>> RFC 7201) should be informative?

7201 and 7202 can be informative. The rest of them should generally be 
normative.

[...]

> *** Editorial Comments ***:

[...]

>
>> Added in Section 1
>
> - section 1.1, last paragraph: By "data model", does this talk about 
> the
> packet format, or
> something else?
>
>> The data model for the RTP payload

It would be helpful to say that.

[...]

>
> It would be helpful to mention that DID_SDIS can occur multiple times
> (or be a list of
> values, depending on your perspective.)
>
>> Not sure what you mean, Section 3.2 states “Multiple DID_SDID 
>> parameters may be specified (separated
>> by semicolons) to signal the presence of multiple types of ANC data 
>> in the stream.”

I missed that. No change needed.

[...]

---

From: Thomas Edwards <[email-masked]>
Date: Thu, 6 Oct 2016 03:00:15 +0000

Ben,

OK, my responses are inline below as well.

>payload of the ANC data? Is that _not_ part of the payload?

Perhaps to be more clear, I can change the Horizontal Offset section
to state: “A value of 0 means that within the original SDI signal, the
Ancillary Data Flag (ADF) of the ANC data packet begins immediately
following SAV."

Hopefully this should make it more clear that the ADF lives in SDI
(where it serves as a “preamble” for the ANC data packet), and
not in the RTP payload.

>incorrectly associated ANC packets? If so, it would be helpful to 

I think that the ANC and related streams can likely run OK with
different timestamp rates - we actually expect audio RTP
streams based on RFC 3190 to have different timestamp rates than
video.  One just have to be aware of the timing relationship
between the streams.

But I can add to the draft that mechanisms such as IETF RFC 7273 “RTP
Clock Source Signalling” can be used to ensure that the receiver of ANC
RTP streams and associated RTP streams can be linked to a common
clock (such as PTP). 

Thanks for your feedback!

-Thomas

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035