[Sip] Copy to list: Request for publication of draft-ietf-sip-acr-code-04
Dean Willis <dean.willis@softarmor.com> Sun, 04 March 2007 20:20 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxCF-0007b0-T3; Sun, 04 Mar 2007 15:20:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxCE-0007U8-3R for sip@ietf.org; Sun, 04 Mar 2007 15:20:42 -0500
Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNxCD-0002KX-JH for sip@ietf.org; Sun, 04 Mar 2007 15:20:42 -0500
Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l24JQWaX030203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <sip@ietf.org>; Sun, 4 Mar 2007 13:26:33 -0600
Mime-Version: 1.0 (Apple Message framework v752.3)
References: <67D963E5-F872-45C6-B33D-47B3A6B33CAA@softarmor.com>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <EC8DFC3E-4759-4B89-9511-D371AD377DCD@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Date: Sun, 04 Mar 2007 14:20:39 -0600
To: SIP IETF <sip@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Subject: [Sip] Copy to list: Request for publication of draft-ietf-sip-acr-code-04
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Here's a copy to the list of the publication request for draft-ietf- sip-acr-code ----------- The SIP working group would like to request publication of draft-ietf- sip-acr-code-04. This document is intended for publication as a Proposed Standard, and is chartered work-product of the SIP working group. A PROTO writeup follows: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Dean Willis, co-chair of the SIP working group. He has personally reviewed this document and believes this version is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from within the working group and was reviewed externally by members of ETSI TISPAN who established the requirements met by this document. It is a fairly straightforward SIP extension and should not require a great deal of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. One potentially questionable aspect of this document is that it makes a normative reference to the privacy functions defined in the informational RFC 3325. While informational, this RFC is the basis of the privacy mechanism in the current IMS specifications referenced by 3GPP and ETSI TISPAN. The reference is structured to say that "If you are using the privacy mechanisms defined in RFC 3325, then . . . " rather than recommending the RFC 3325 mechanism as a baseline. I believe this to be a reasonable down-reference. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus is that the approach specified in this document is both reasonable and obvious. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The shepherd processed the document through the current version of idnits (2.03.9). This check noted the down-reference to RFC 3325 discussed above, and one minor formatting error (a doubled space in the title of a reference) that isn't worth revising the document to address. There are no known formal review criteria applicable to this document. (Note: Keith thinks this probably should have mentioned RFC 4485, but I don't think this is a formal review) The document is also lacking an "Intended Status" line in the front matter. The intended status of this document is "Proposed Standard". (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. See discussion under 1.d above. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section appears to be reasonable. It defines one new SIP response code to be placed in the existing sip-parameters registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no document sections written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines an extension to the Session Initiation Protocol providing a new response code that may be used to reject an anonymous request so that the requesting party can understand that the request was rejected because it was made anonymously and could reasonably be expected to succeed if retried without anonymity. Working Group Summary The requirement addressed by this document was identified by ETSI TISPAN. The SIPPING working group discussed the requirement and determined that a SIP extension would be required to address that requirement. The technique specified by this document was originally introduced in an individual document submitted by Jonathan Rosenberg and discussed in the SIP working group. The SIP working group rapidly achieved consensus on the approach and recommended establishing a working group milestone for this work. There was no controversy within the SIP working group on the direction of this work. Document Quality This is a very simple extension to the SIP protocol. It is expected to be widely implemented in SIP systems interacting with the switched telephone networks of the world. Since it addresses requirements from ETSI TISPAN, participants from that organization were asked to review the specification and reported that it is suitable for their needs. Personnel The document shepherd is Dean Willis. The responsible area director is Cullen Jennings. No IANA expert, MIB doctor, or other specialized contributor is required. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip