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:[email protected]] > Sent: Sunday, August 09, 2015 11:37 PM > To: [email protected]; 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. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
