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

["Ben Campbell" <[e-mail]>]

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.

[...]