Skip to main content

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

Yes

(Cullen Jennings)

No Objection

Lars Eggert
(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Lisa Dusseault)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

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

Lars Eggert
No Objection
Cullen Jennings Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection (2007-10-18) Unknown
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
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2007-10-17) Unknown
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.
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2007-10-15) Unknown
  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
Sam Hartman Former IESG member
No Objection
No Objection (2007-10-18) Unknown
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.
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection (2007-10-16) Unknown