RTP Payload Format for High Efficiency Video Coding (HEVC)
draft-ietf-payload-rtp-h265-15
Yes
(Ben Campbell)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 14 and is now closed.
Ben Campbell Former IESG member
Yes
Yes
(for -14)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -14)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
()
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -14)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2015-09-01 for -14)
Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection
(for -14)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -14)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -14)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -14)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-09-01 for -14)
Unknown
I support Stephen's first discuss.
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2015-11-09)
Unknown
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.
Terry Manderson Former IESG member
No Objection
No Objection
()
Unknown