[payload] Shepherd's review for draft-ietf-payload-rtp-vc2hq-03

[Ali C. Begen <[e-mail]>]

James,

Here is my chair review for your vc2hq draft. Please submit a revision addressing the comments and then I will ship it to the AD.

-acbegen

1) IDnits: There are a few minor issues reported by the IDnits tool. Please address them. Also “Abbreviated Title” should reflect this draft’s purpose.

2) The use of capitalization is a bit mixed. The RFC editor will likely fix these, but words like “parse info”, “sequence”, etc. are sometimes capitalized but not always. Would be good to be consistent.

3) Section 4:
s/Time Stamp/Timestamp (in multiple figures)

4) Section 4.1
s/MUST holds/MUST hold

5) Section 4.2
s/sendt/sent

Says:
Picture header: If the receiver does not receive a transform parameters packet
         for a picture then it MAY assume that the parameters are
         unchanged since the last picture, or MAY discard the picture.

Well what if the parameters actually change in the last picture (say pic 4) but that picture (pic 4) is lost, and the following picture (pic 5) does not have the parameters. Would the receiver incorrectly assume the same parameters from pic3 or earlier for pic 5? If the parameters have changed, how big a problem would it be?

What if the Slice Prefix Bytes value or the slice size scalar value is larger than 16 bits as the smpte spec allows?

What if a slice does not fit in a single RTP packet? The draft says the packet must not contain any partial slices. Can’t there be slices bigger than a few thousand bytes?

6) Section 5

If we are really talking about Gbps traffic, I am guessing this will be mostly used in a closed environment in a production network. And maybe in that case the network is already provisioned to carry such a high traffic and congestion control may not be needed. I think the draft should a bit more about this. especially if the vc2 stream to be used on the Internet, then serious congestion control warnings need to apply. At this point the section is pretty weak and I am pretty sure this will be raised by the IESG.

7) Section 6.2

Could you provide a bit more details and one or two examples? See some of the recent drafts for examples.

8) References: RFC3711, RFC4585 and RFC5124 should be normative IMO.

-acbegen