Title: review of draft-ietf-mmusic-connectivity-precon-06 I 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. The document "draft-ietf-mmusic-connectivity-precon-06" defines "a new connectivity precondition for the Session Description Protocol (SDP) precondition framework." Connectivity preconditions are used to delay session establishment (or modification) until media stream connectivity has been verified. The use of preconditions represents an interesting twist on the original SDP model, where the assumption was that an SDP session would be established before media streams were established! The use of preconditions is motivated in large part by the need for media streams to traverse firewalls and NATs. The Security Considerations section here starts by citing the Security Considerations section from the base preconditions RFC (3312). It also adds two paragraphs to discuss new considerations relevant to the precondition types defined in this document. This is an appropriate way to address new security issues that arise for extensions to previously-defined functions. RFC 3312 has a two-paragraph Security Considerations section, which identifies concerns, but make no recommendations about security mechanisms to employ! This document has a paragraph that RECOMMENDS use of integrity for the SDP traffic, e.g., via RFC 3261, to counter attacks against this portion of the system. This is a concrete recommendation that is appropriate for this aspect of the security concerns cited, and is applicable to the 3312 security concerns as well. The new security concerns that arise here result from reliance on other protocols to detect successful media stream establishment. This motivates concerns about two classes of DoS attacks: transient attacks that cause session establishment to fail (when the media streams could have been created) and transient attacks that make it appear that media streams have been established, when in fact they have not. TCP and ICE are the protocols cited specifically as one of interest. The text RECOMMDNDS making use of suitable authentication and integrity mechanisms for the relevant protocols to counter both forms of attacks. The text also says that "the mechanisms SHOULD consider how to prevent denial of service attacks." I find this text to be too vague to be useful. It ought to cite specific mechanisms in RFCs, at least as examples, preferably as recommendations. The lack of specific, cited mechanisms makes this section almost vacuous. I suggest that the authors revise the text here to cite appropriate mechanisms.