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. Background ---------- This document describes a framework for call control and multi-party usage of SIP (while the abstract also talks about requirements, I did not see any strong requirements - at least there are no normative statements in the RFC 2119 sense in the document). Comments -------- Although brief, the Security Considerations section reads well (a more comprehensive trust/threat model analysis for the proposed framework would have been nice though). It could be useful to add a sentence or two on anonymity aspects in the context of the proposed framework. The body of the text mentions this aspect in passing once (2.6.4) but there is no mentioning in the Security Considerations section. In the sixth paragraph, an explicit method for replay attack prevention is recommended (lower-case "should"). I am not sure about the reason for this and could potentially see other ways to mitigate such attacks. Hence, one suggestion could be to replace the current "In the case of features initiated by a former participant, these should be protected against replay attacks by using a unique name or identifier per invocation" with: "In the case of features initiated by a former participant, these should be protected against replay attacks, e.g. by using a unique name or identifier per invocation." For clarity, I also suggest changing this section's last sentence to: "These credentials may for example need to be passed transitively or fetched in an event body." A question: The third paragraph in the Security Considerations section refers to Section 3.2 - might this be Section 2.3? General/editorial: - Abstract states "This framework also describes other goals that embody the spirit of SIP applications as used on the Internet" - it would have been useful if this sentence at least had identified a few of these goals. - Section 2.3: "peers can take advantage of end-to-end message integrity or encryption" - I would say this applies only when certain conditions are met and hence perhaps something like "peers may take advantage..." or similar would be better. - Section 2.6.7.2: Acronym "IVR" introduced without explanation. An early "Acronyms" section would be useful. - Section 3: The sentence "One means of accomplishing this is through the ability to define and obtain URIs for these actions as described in section ." seems to be missing the final section reference. -- Magnus