Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
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 -)
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 -)
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 -)
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
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.