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