Re: [Gen-art] Gen-ART Last Call review of draft-ietf-payload-rtp-h265-13

[Brian E Carpenter <[e-mail]>]

Thanks for your reply, that all looks easy to fix.

> Maybe the line break caused the nits report.

Yes, I have submitted a bug report on the nits tool. It's not your
error of course, but if you could avoid that line break it will
remove the warning.

Regards
   Brian

On 20/08/2015 15:59, Wang, Ye-Kui wrote:
> Hi Brain,
> 
> Thanks for your review of the draft. Please see my responses inline below, each reply initiated with "[YK]".
> 
> Co-authors, please express yourself if you have a different opinion for any of the items.
> 
> Ben and Roni, as the AD/document shepherd, please let us authors know if we should revise the document.
> 
> BR, YK (just came back from vacation)
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Sunday, August 09, 2015 11:37 PM
> To: [e-mail]; General Area Review Team
> Subject: Gen-ART Last Call review of draft-ietf-payload-rtp-h265-13
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
> 
> For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-payload-rtp-h265-13.txt
> Reviewer: Brian Carpenter
> Review Date: 2015-08-10
> IETF LC End Date: 2015-08-14
> IESG Telechat date:
> 
> Summary: Almost ready
> --------
> 
> Comment:
> --------
> This is a well written document with good explanatory text as well as the specification material. However, a non-expert cannot effectively review the hundreds of technical details in this document.
> 
> Note that there are four (F)RAND IPR disclosures that the shepherd indicates are known to the WG.
> 
> Minor issues:
> -------------
> 
> I recommend including the string "H.265" in the document's title, to assist searching.
> 
> [YK]: Agreed. Thanks!
> 
> Section 3.1.1 duplicates many definitions from H.265, which is helpful for the reader. But should the draft be specific that it depends on H.265-2013?
> What happens if ITU-T updates the definitions in a future version?
> 
> [YK]: Currently we do refer to H.265-2013 specifically by the citation [HEVC], and in section 3.1 we have the sentence "Section 3.1.1 lists relevant definitions copied from [HEVC] for convenience." If we'd be more specific, we can change that sentence to "Section 3.1.1 lists relevant definitions copied from [HEVC] (the April 2013 version of the H.265 specification) for convenience."
> 
> (Section 7.1 Media Type Registration , page 71, and a similar note on the previous page):
> 
>    "Informative note: depack-buf-cap indicates the maximum
>     possible size of the de-packetization buffer of the
>     receiver only.  When network jitter can occur, an
>     appropriately sized jitter buffer has to be available as
>     well."
> 
> Firstly, IMHO there is no network without jitter in the IETF world.
> More seriously, "appropriately sized"  is an information-free phrase (and an invitation to buffer bloat). It would be cleaner to say
> 
>    "Informative note: depack-buf-cap indicates the maximum
>     possible size of the de-packetization buffer of the
>     receiver only, without allowing for network jitter."
> 
> [YK]: Agreed. Thanks!
> 
> Nits:
> -----
> 
> There are numerous uses of the phrase "has to" which in plain English is exactly the same as "must". Have these all been checked to be sure that none of them need to be "MUST"? There is one use of "have to" where the same question applies.
> 
> [YK]: I just searched and checked all instances of "has to" and "have to". Most of them are in informative notes, wherein definitely we cannot use "MUST". For the few instances not in informative notes, they are all good as they are to me. Everyone please let me know if you think there is a need for a change.
> 
> 
> Just to prove that I did look into the text a bit, this sentence is broken (Section 7.1 Media Type Registration , page 61):
> 
> "The highest level (specified by max-recv-level-id) MUST be such that the receiver is fully capable of supporting."
> 
> I think this means
> "The highest level (specified by max-recv-level-id) MUST be the highest that the receiver is fully capable of supporting."
> 
> [YK]: Yes, it indeed means that, and your suggestion does seem to be better English than what we had. Thus agreed.
> 
> 
> A couple of ID-nits need attention (probably deletion):
> 
>   == Unused Reference: 'RFC6190' is defined on line 3841, but no explicit
>      reference was found in the text
> 
> [YK]: Agree to remove this reference.
> 
>   == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on
>      line 3878, but no explicit reference was found in the text
> 
> [YK]: This one is actually used, in Section 4.3. Maybe the line break caused the nits report.
>