Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
RFC 5124

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

(Cullen Jennings) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Sam Hartman) No Objection

Comment (2007-10-18 for -)
No email
send info
I think Jon's comment is getting at the same issue.
Long term we want people to be able to offer best-effort security--offer both secure and non-secure and select secure if it is available at both ends.
The important thing will be to let the user know whether we have security rather than to fail if we do not.
I think it is fine to ignore this issue for now provided that we plan on updating this spec wehn the appropriate mmusic work concludes.

(Russ Housley) No Objection

Comment (2007-10-15 for -)
No email
send info
  Please consider the comments offered by Ben Campbell in his
  Gen-ART Review.  The review was done on 27-Aug-2007, but the
  document has not been revised since.  The review is available
  at: http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-avt
  -profile-savpf-11-campbell.txt

(Chris Newman) No Objection

(Jon Peterson) No Objection

Comment (2007-10-18 for -)
No email
send info
Following on Magnus' DISCUSS, I also think it's premature to discuss  SDP capability negotiation scenarios in this document. Perhaps it would be better to say that you MUST not offer secure and insecure media simultaneously in the absence of some future protocol mechanism updating this specification. I just wanted to point out that more affected text lives in the second paragraph of 3.3.4, and of course in the paragraph above the one in 3.3.1 cited by Magnus. Furthermore, all of 3.3.1 seems hastily written and should be cleared of various grammar woes ("the answerer the answerer", etc).

Also, at the end of the first paragraph of the Sec Cons:

   The SAVP profile does not add, nor take away, 
   any security services compared to SAVP.  

Surely this should be "The SAVPF profile does not add..." etc

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2007-10-17)
No email
send info
Section 3.3.2:

"        Note: To change any of the profiles in use, the client needs 
        tear down the RTSP session (using the TEARDOWN method) and re-
        establish it using SETUP.  This may change as soon as media 
        updating (similar to a SIP UPDATE or re-INVITE) becomes 
        specified. "

This is not totally correct, as it is possible to teardown an individual media stream without tearing down the whole RTSP session I therefore suggest the following formulation:

        Note: To change any of the profiles in use, the client needs 
        tear down that media stream (and possibly the whole RTSP session)
       (using the TEARDOWN method) and re-establish it using SETUP.  This 
        may change as soon as media updating (similar to a SIP UPDATE or 
        re-INVITE) becomes specified.