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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Aug 2015 18:36:58 +1200

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.

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?

(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."

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.

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."

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

  == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on
     line 3878, but no explicit reference was found in the text

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Thu, 20 Aug 2015 03:59:43 +0000

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-masked]] 
Sent: Sunday, August 09, 2015 11:37 PM
To: [email-masked]; 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>.

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

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

[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.

[YK]: Agree to remove this reference.

[YK]: This one is actually used, in Section 4.3. Maybe the line break caused the nits report.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Aug 2015 16:25:17 +1200

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