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

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

Hi James

Besides the editorial changes, you added significant amount of new text
(section 4.4 and and VC-2 versioning). I feel like a new WGLC is due here.
I will start a short WGLC so everybody has a chance to look at the changes.
Then, we can ship it to the AD if all is well.

-acbegen

On Mon, Jan 8, 2018 at 4:40 PM, James Barrett <[e-mail]>
wrote:

> Thank you,
>
> I have submitted a revised version based on this review.
>
> --
> James P. Weaver (né Barrett)
> Research Engineer
> BBC R&D North Lab,
> Floor 5 Dock House, MediaCity,
> M50 2LH
> Tel: [phone]
> e-mail: [e-mail]
>
>
>
> > On 29 Nov 2017, at 15:09, Ali C. Begen <[e-mail]>
> wrote:
> >
> > 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
>
>