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

[Thomas Edwards <[e-mail]>]

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.

Below are my responses to the AD, with my responses prefixed by “>”

*** Substantive Comments *** :

- General:
There's a lot of use of 2119 keywords in situations where you talk more
about definitions/
statements of fact than procedure. I mention some specific instances
below, but may not
have caught all of them.

> Sorry, I typically write SMPTE standards where we tend to use more normative language - I will 
> keep the 2119 keywords to procedures.

- Section 1:

A quick mention of the meaning of horizontal and vertical ancillary
spaces would be
helpful.

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

- section 2:
-- timestamp:
"For progressive scan video, the timestamp SHALL denote the
sampling instant of the frame to which the ancillary data in
the RTP packet belongs.”

That's a definition. I suggest "... timestamp denotes..." (occurs twice)

> Redone as definition

-- Marker Bit:

"The marker bit set to "1" SHALL indicate the last ANC RTP packet ..."

Consider "The marker bit set to "1" indicates..."

> Change made

- section 2.1:
Am I correct to assume the various length or count fields are unsigned
integers? Network
byte order?

> Added unsigned integers in network byte order to specification

-- ANC count:
"A single ANC RTP packet payload SHALL NOT carry more than 255 ANC data
packets."
  Isn't this a statement of fact, since the number is limited by the 8
bit ANC_Count field?
If so, consider s/SHALL NOT/cannot

> Change made

  On the other hand, the "may" in "additional RTP packets carrying ANC
data may be sent
with the same RTP timestamp but with different sequence numbers." seems
to be an
appropriate place for a 2119 "MAY"

> Change made

  "ANC_Count of 0 SHALL indicate that there are no ANC data packets"
  Please consider s/SHALL indicate/indicates

> Change made

  -- Horizontal Offset:
  All 3 instances of "SHALL" seem more like statements of fact.

> Change made

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

-- 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?

- 3.2, encoding of the subtype name:
It would be helpful to mention the "rate" parameter here as well.

> Added

-- mapping of "DID_SDID" parameters:
It would be helpful to mention the ability to carry multiple types
earlier in the document
(perhaps where types are first mentioned, or where DID_SDID was first
mentioned.)

> Added in Section 1 paragraph 4

- 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?

- References: It seems like the references to [RFC3264] and [RFC5888]
should be normative.

> Changed to normative

*** Editorial Comments ***:

- General: An early description of the meaning of ANC data packet types
would be helpful.

- section 1: A quick mention of the meaning of horizontal and vertical
ancillary spaces
would be helpful.

> 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

-3.1, optional parameters:
Is this link reasonably permanent? Also, consider moving this to the
references section
(perhaps in a separate "URLs" section) and citing it normally.

> The link is reasonably permanent, moved to the informative references

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

-- Change controller:
I suspect this should say “ The IETF PAYLOAD working group, or other
party as designated
by the IESG.”"

> Change made

- 3.2.1

What does "essence" mean in the context of "video essence stream"? Am I
correct to assume
it refers to the actual video content?

> The “EBU/SMPTE Task Force for Harmonized Standards for the Exchange of Programme Material
> as Bitstreams” defined “essence” as “Any data signal necessary to represent any single type of visual, aural,
> or other sensory experience”
>
> But I will just leave out the word “essence” as “associated video streams” should work fine.

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


On 8/25/16, 3:36 PM, "Ben Campbell" <[e-mail]> wrote:

>Hi,
>
>This is my AD evaluation of draft-ietf-payload-rtp-ancillary-05. I'd 
>like to at least resolve the substantive comments before going to IETF 
>last call.
>
>Thanks!
>
>Ben.
>----------------
>
>*** Substantive Comments *** :
>
>- General:
>There's a lot of use of 2119 keywords in situations where you talk more 
>about definitions/
>statements of fact than procedure. I mention some specific instances 
>below, but may not
>have caught all of them.
>
>- Section 1:
>
>A quick mention of the meaning of horizontal and vertical ancillary 
>spaces would be
>helpful.
>
>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?
>
>- section 2:
>-- timestamp:
>"For progressive scan video, the timestamp SHALL denote the
>sampling instant of the frame to which the ancillary data in
>the RTP packet belongs."
>
>That's a definition. I suggest "... timestamp denotes..." (occurs twice)
>
>-- Marker Bit:
>
>"The marker bit set to "1" SHALL indicate the last ANC RTP packet ..."
>
>Consider "The marker bit set to "1" indicates..."
>
>- section 2.1:
>Am I correct to assume the various length or count fields are unsigned 
>integers? Network
>byte order?
>
>-- ANC count:
>"A single ANC RTP packet payload SHALL NOT carry more than 255 ANC data 
>packets."
>  Isn't this a statement of fact, since the number is limited by the 8 
>bit ANC_Count field?
>If so, consider s/SHALL NOT/cannot
>
>  On the other hand, the "may" in "additional RTP packets carrying ANC 
>data may be sent
>with the same RTP timestamp but with different sequence numbers." seems 
>to be an
>appropriate place for a 2119 "MAY"
>
>  "ANC_Count of 0 SHALL indicate that there are no ANC data packets"
>  Please consider s/SHALL indicate/indicates
>
>  -- Horizontal Offset:
>  All 3 instances of "SHALL" seem more like statements of fact.
>
>- 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?
>
>-- intended usage: Is "Common" the right choice? Do you expect this to 
>be widely used, or
>just in some very specific applications?
>
>- 3.2, encoding of the subtype name:
>It would be helpful to mention the "rate" parameter here as well.
>
>-- mapping of "DID_SDID" parameters:
>It would be helpful to mention the ability to carry multiple types 
>earlier in the document
>(perhaps where types are first mentioned, or where DID_SDID was first 
>mentioned.)
>
>- 5: The security considerations do not include the recommended text 
>from
>draft-ietf-payload-rtp-howto-14, section A.13. Should it?
>
>- References: It seems like the references to [RFC3264] and [RFC5888] 
>should be normative.
>
>*** Editorial Comments ***:
>
>- General: An early description of the meaning of ANC data packet types 
>would be helpful.
>
>- section 1: A quick mention of the meaning of horizontal and vertical 
>ancillary spaces
>would be helpful.
>
>- section 1.1, last paragraph: By "data model", does this talk about the 
>packet format, or
>something else?
>
>-3.1, optional parameters:
>Is this link reasonably permanent? Also, consider moving this to the 
>references section
>(perhaps in a separate "URLs" section) and citing it normally.
>
>It would be helpful to mention that DID_SDIS can occur multiple times 
>(or be a list of
>values, depending on your perspective.)
>
>-- Change controller:
>I suspect this should say “ The IETF PAYLOAD working group, or other 
>party as designated
>by the IESG.”"
>
>- 3.2.1
>
>What does "essence" mean in the context of "video essence stream"? Am I 
>correct to assume
>it refers to the actual video content?
>