RTP Payload Format for Scalable Video Coding
Note: This ballot was opened for revision 27 and is now closed.
(Gonzalo Camarillo) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) (was Discuss) No Objection
(Lars Eggert) No Objection
(Russ Housley) No Objection
Alexey Melnikov (was Discuss) No Objection
Comment (2010-12-20 for -)
In the MIME registration section: "Encoding Considerations" says that the media type is framed and binary. I think you need to pick one (just "framed").
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
Comment (2010-12-15 for -)
I concur with Alexey's DISCUSS regarding compliance with RFC 4288. Section 4.5.1 states: When SST is in use, Section 5.4 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the following modifications. And Section 4.6 states: Section 5.6 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the following modifications. Does this specification modify 3984[bis], or does it only extend 3984[bis]?
(Robert Sparks) No Objection
Comment (2010-12-14 for -)
It would help to more clearly call out the consequences rewriting RTCP has on the way SRTP can be used. Currently the document only mentions this (and not as directly as it could) in an "Informative Note". Pointing to the last paragraph in the Security Considerations section of 3894bis would help.
(Sean Turner) (was Discuss) No Objection
#1) The RFC editor will make you remove the reference in the abstract. #2) Abstract: r/in_Annex/in Annex #3) Expand HDTV and Mbps. #4) Section 4.4, last para: Wouldn't it be easier to say SST is the default?