Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
RFC 5764

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

(Pasi Eronen) Yes

(Cullen Jennings) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

Lars Eggert No Objection

(Russ Housley) No Objection

(Chris Newman) (was Discuss, No Objection) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

Comment (2008-11-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 4.2, immediately before Figure 1:

A brief statement that the master key and master salt are provided to the SRTCP key
derivation function seems to be missing here.  These invocations are implied by Figure
1, but are conspicuously absent from the text.

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

(Magnus Westerlund) (was Discuss) No Objection

Comment (2008-11-06)
No email
send info
Section 3:

"This improves the cryptographic
   performance of DTLS, but may cause problems when RTCP and RTP are
   subject to different network treatment (e.g., for bandwidth
   reservation or scheduling reasons.)"
The above sentence seems so backwards. If you multiplex them together then they can't be subject to different treatment. And the reasons seems to be wrong ones for arguing against multiplexing. The three main reasons why RTP and RTCP isn't multiplex as stated in the MUX draft are: Simplicity, effiency and 3rd party monitoring. Especially the last is hard to combine with encryption services, especially such that perform setup point to point.