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 document replaces RFC 3427, refining the SIP change process. Although I have some familiarity with SIP, my knowledge of this area is minimal. I have not participated in any of the RAI WGs or in the SIP change process. My comments should therefore mainly be taken as those of an IETF "common man" and a security expert. I have very few security concerns related to this document. As with RFC 3427, this document continues to require all new SIP headers and event packages (the only extensions that can be registered without going through an IETF WG) to be reviewed by a Designated Expert using guidelines that include strict security requirements. My only security concern with this process is that a Designated Expert might not have much or any security expertise. A truly dedicated reviewer without such expertise would seek specialized review for security issues but many reviewers are overworked or not able to obtain security help. This problem could be solved by requiring all SIP extensions to become RFCs, therefore ensuring that they get broad review, including secdir reviews. RFC 3427 required this. This draft proposes to remove the requirement for RFC publication for SIP headers, allowing IANA registration of SIP headers that receive Designated Expert review but are not published as RFCs. I suggest that this change not be made since it will reduce the security review of these extensions. Another reason to not allow IANA registration of SIP headers without RFC publication is that there may not be a permanent and clear definition of these headers. If a header is only documented on a vendor web site, that documentation can disappear at any time. Other changes that were made to the SIP header registration process include a large reduction in the number of guidelines for expert reviewers. The requirements dropped include these: applicability to SIP, lack of overlap with current or planned SIP extensions, clear documents, and an applicability statement when the extension is not suitable for use on the Internet. Removing those guidelines seems unwise to me. I have divided the rest of my comments into substantive and non-substantive comments. First, the substantive ones. * Does the term "consensus" in the first sentence of the third paragraph of section 3 refer to WG consensus or IETF consensus? I believe that it refers to WG consensus but this should be clarified. * The last sentence of the fifth paragraph in section 3 says that the DISPATCH working group may "approve proposals for extensions if the requirements are judged to be appropriate to SIP, but are not sufficiently general for standards track activity." I think that these proposals would then proceed as individual submissions. If that's right, I suggest that this be mentioned in this sentence. * The first paragraph of section 4.1 says that "Normal event packages can be created and registered by the publication of any Working Group RFC (Informational, Standards Track, Experimental), provided that the RFC is a chartered working group item." However, the next paragraph describes how individual submissions for event packages may be published. This seems to be a contradiction. Maybe the sentence that I just quoted is not intended to exhaustively describe all the ways that event packages can be created. If that's the case, the sentence should be clarified. * Paragraph four of section 4.1 says that the procedure for registering event packages developed outside the scope of an IETF working group is "RFC Required". However, the process described in the following paragraphs would better be described as "RFC Required with Designated Expert Review". * As the first paragraph in the Security Considerations section says, feature interactions can have significant security implications. However, the text should go one step beyond to require that all RFCs that modify or extend SIP must consider the security implications of feature interactions. * The fifth paragraph of section 7 says that "For event template packages, registrations must follow the RFC5226 processes for Standards Action." Actually, the earlier part of this document included an additional requirement that such specifications must be developed by an IETF Working Group. Probably that should be documented here. * The fifth paragraph of section 7 also states that IETF Review is the process used for ordinary event packages. That is not consistent with section 4.1, which states that the process for these is RFC Required (with Designated Expert review). I think that section 4.1 is correct and the text in section 7 should be updated. Here are my non-substantive comments. * In the first paragraph of section 2, "SIP has to preserve" should be "SIP has been to preserve". * In the first paragraph of section 2.1, the word "exists" should be removed from the end of the first sentence. * In the second paragraph of section 2.1, the phrase "updates or obsoletes" is not clear. I suggest using the phrase "documents that update or obsolete". Further, I suggest adding the phrase "or their successors" at the end of that sentence. * In the third paragraph of section 2.1, "will the use" should be "will use". In the following sentence, delete the phrase "and the rest of this document". That is a copy and paste error left over from RFC 3427, I think. In the last sentence of this paragraph, I suggest changing "any protocol in the IETF" to "SIP (and any protocol in the IETF)". The emphasis should be on SIP in this document. * In the fourth paragraph of section 2.1, change the first sentence to say "IETF working group" instead of just "working group". I think that's the intent but someone could read it to include working groups of other organizations also. * In the second paragraph of section 4, there's an extra comma after "While". Also, I think the word "general" is missing after the phrase "deal with a point solution and are not". * In the sixth paragraph of section 4, the phrase "Informational IETF specifications" would be clearer if it was replaced by "Informational RFCs". * The first paragraph of section 4.1 includes a reference to "[6]" but references in this spec are of the form "[RFCXXXX]". I believe this reference is supposed to be [RFC3265]. * In the numbered list at the end of section 4.1, several references use the wrong format. The references to [6] should be [RFC3265] and the reference to [3] should be [RFC3261], I think. * The text "(See Section 4)" appears in the list at the end of section 4.1 but the meaning of this text is not clear. Please clarify. * More numeric references appear in section 6. These can easily be transformed to the more explicit style used in this document since the RFC numbers are adjacent to the references.