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

From: James Barrett <[email-masked]>
Date: Mon, 8 Jan 2018 13:40:56 +0000

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: +44(0)30 3040-9521
e-mail: [email-masked]

> On 29 Nov 2017, at 15:09, Ali C. Begen <[email-masked]> 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

---

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 16 Jan 2018 14:24:00 +0300

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 <[email-masked]>
wrote:

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