Ballot for draft-ietf-payload-rtp-h265
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
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.
I support Stephen's first discuss.
Thanks for taking my discuss points into account. The comments below were for an earlier version, I've not checked if related changes were made or not. (And there's no need to come back to me about that unless you want to.) - General: I was puzzled as to why there is so much text that is presumably non-normative explanatory text covering what is elsewehere in (I guess) ITU documents. It seems like there is a lot, but not enough, here for an implementer. - 4.1: " The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. " Huh? That's confusing. For me at least. - p75 - why would md5 ever be most-preferred these days? Better to not say that, even in an example. Even better would be to deprecate md5 even for this non-security purpose to simplify code-audit. Or, if there is some reason why e.g. sha256 isn't suited then explaining that would also help for code-audits.