Skip to main content

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