Last Call Review of draft-ietf-payload-rtp-h265-13
review-ietf-payload-rtp-h265-13-genart-lc-carpenter-2015-08-11-00

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