RTP Payload Format for High Efficiency Video Coding (HEVC)
RFC 7798

Note: This ballot was opened for revision 14 and is now closed.

(Ben Campbell) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-11-09)
No email
send info
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.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-09-01 for -14)
No email
send info
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.

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-09-01 for -14)
No email
send info
I support Stephen's first discuss.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection