RTP Payload Format for Video Codec 1 (VC-1)
RFC 4425

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

(Allison Mankin; former steering group member) Yes

Yes ()
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ()
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection ()
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ()
No email
send info

(Brian Carpenter; former steering group member) No Objection

No Objection ()
No email
send info

(David Kessens; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2006-01-31)
No email
send info
  The Security Considerations say:
  >
  > RTP packets using the payload format defined in this specification 
  > are subject to the security considerations discussed in the RTP 
  > specification [4], and in any appropriate RTP profile.  This implies 
  > that confidentiality of the media streams is achieved by encryption; 
  > for example, through the application of SRTP [11].   
  >
  This is good.  I would like to see this expanded to cover integrity
  as well as confidentiality.

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()
No email
send info

(Ted Hardie; former steering group member) No Objection

No Objection (2006-01-31)
No email
send info
omment: 

The document says:
    
   Note that the appropriate mechanism to ensure confidentiality and 
   integrity of RTP packets and their payloads is very dependent on the 
   application and on the transport and signaling protocols employed. 
   Thus, although SRTP is given as an example above, other possible 
   choices exist. 
    

This would be more useful with a pointer to at least one other example
and/or a discussion of the application issues which vary the means by
which confidentiality and integrity are assured.