Last Call Review of draft-ietf-avt-app-rtp-keepalive-
review-ietf-avt-app-rtp-keepalive-secdir-lc-emery-2009-06-16-00

Request Review of draft-ietf-avt-app-rtp-keepalive
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-06-03
Requested 2009-05-23
Draft last updated 2009-06-16
Completed reviews Secdir Last Call review of -?? by Shawn Emery
Assignment Reviewer Shawn Emery
State Completed
Review review-ietf-avt-app-rtp-keepalive-secdir-lc-emery-2009-06-16
Review completed: 2009-06-16

Review
review-ietf-avt-app-rtp-keepalive-secdir-lc-emery-2009-06-16

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.



This draft describes various ways for RTP applications to keep NAT 


mappings alive.  It goes on to detail individual keepalive methods and 


advantages/disadvantages of its approach.




Intended status of the draft is BCP.



I'm not for sure I understand the security considerations section, but I 


think what it's trying to say is that: old peers, which don't understand 


the new keepalive message, will appropriately drop the packet sent by 


its peer?  If so then please reword accordingly.






No additional security related issues beyond RTP itself discovered in 


this draft.




General comment(s):



I appreciate the use of a requirements section, this makes it easier to 


find out what is or is not in scope for the recommended solutions.




Editorial comment(s):

Expand the first occurrences of "SDP" and "RTCP".

s/needs support/needs to support/

s/mux"attribute/mux" attribute/

Shawn.
--