Telechat Review of draft-ietf-mmusic-sdp-capability-negotiation-

Request Review of draft-ietf-mmusic-sdp-capability-negotiation
Requested rev. no specific revision (document currently at 13)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2009-06-02
Requested 2009-05-23
Authors Flemming Andreasen
Draft last updated 2009-05-29
Completed reviews Secdir Last Call review of -?? by Stephen Kent
Secdir Telechat review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-mmusic-sdp-capability-negotiation-secdir-telechat-kent-2009-05-29
Review completed: 2009-05-29



review of

I have reviewed this I-D 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.

I performed this re-review by examining a diff between versions 9 and
10 of the I-D, and by reviewing my comments on version 9.

I thank the author for having made a number of changes based on my
review comments. He paid closer attention to where the word "only"
is placed in sentences. I note that some newly added text repeats the
previous placement errors re this word


. He also fixed the IPsec misspelling. There are still a few
typos in this version, but I expect the RC Editor will fix them.

The author added text to include a DTLS-SRTP example, in addition to
the MIKEY examples. (I'm not sure that its appropriate to retain the
MIKEY examples at all here, but I defer to the RAI AD's judgment on
this matter.)

The author revised the discussion of RFC 4474 to indicate that it is
still PKI-based, but that the required PKI is less extensive (and thus
potentially more viable) than a PKI that must encompass all end users.
He also corrected the discussion to note the residual MITM attack
potential if TLS or IPsec are used for hop-by-hop protection.

The author also revised the advice to implementors re DoS attacks,
making the advice a "must" vs. "MUST."

The reference to section 3.10 in the security considerations
discussion of DoS is still wrong; the reference should be to