Re: [payload] Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT)

["Wang, Ye-Kui" <[e-mail]>]

Hi Barry,

Thanks a lot for your review.

On the first point (on the HEVC overview): We tried to provide some easy-to-understand descriptions of the HEVC features that implementers of this document may be interested. This followed the document structure of earlier video codec RTP payload format such as RFC 3984/6184 and RFC 6190. 

As Stephan clarified in the reply to Stephen Farrell, which I copy here: The WG heard this comment before and discussed it.  It is my understanding of the WG consensus that the level of detail is about right.  For your information, the H.265 version 1 spec is an extremely dense document (much denser than the payload format) and, set out in 10 pt. Times Roman, spans 300 pages.  We cover the core codec only superficially, but dig in a bit deeper in those aspects where we added signaling support for capability exchange (for example, parallelization tools).

On the second point (on the media type parameters and IANA registration): This point has also been discussed by the WG, and explicitly discussed at a recent face-to-face IETF meeting, with the decision being to keep it as is.

BR, YK

-----Original Message-----
From: Barry Leiba [mailto:[e-mail]] 
Sent: Tuesday, September 01, 2015 10:10 PM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-payload-rtp-h265-14: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 1.1 is hugely long, and I wonder why it's necessary.  Can someone really skip the HEVC reference because you've included all this? 
Is it really worth including all this, when people who need to know it should be getting it from the proper HEVC documents?

2. In Section 7.1, the media-type registration template has a tremendously long "optional parameters" section.  I strongly suggest that you move all that text into another subsection, and refer to it in the template, like this:

NEW
   OPTIONAL parameters:
      profile-space, tier-flag, profile-id, profile-compatibility-
      indicator, interop-constraints, and level-id.  See
      Section <whatever> of RFC XXXX for details.
END

IANA will keep the template and make it available, and it's not intended to have such an extended technical exposition in it.  That belongs in the reference document only.