[Sip] Publication request for draft-ietf-sip-gruu-14.txt
"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com> Mon, 25 June 2007 18:15 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 1I2t6O-0005py-Gv; Mon, 25 Jun 2007 14:15:52 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2t6N-0005pt-PN for sip-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 14:15:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t6N-0005pl-Fl for sip@ietf.org; Mon, 25 Jun 2007 14:15:51 -0400
Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2t6M-0002cX-Rh for sip@ietf.org; Mon, 25 Jun 2007 14:15:51 -0400
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5PIFos2011213 for <sip@ietf.org>; Mon, 25 Jun 2007 13:15:50 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 13:15:50 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 20:15:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Jun 2007 20:15:39 +0200
Message-ID: <5D1A7985295922448D5550C94DE2918001339A99@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Publication request for draft-ietf-sip-gruu-14.txt
Thread-Index: Ace3VNWE5kcaVnHsTqmowTNaRRS/uA==
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: sip@ietf.org
X-OriginalArrivalTime: 25 Jun 2007 18:15:46.0666 (UTC) FILETIME=[DA0B54A0:01C7B754]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b
Subject: [Sip] Publication request for draft-ietf-sip-gruu-14.txt
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
(As WG chair) I have just requested publication of: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt The next stage for submitting comments is therefore the IESG last call. The PROTO writeup submitted with the publication request is as follows. Please feel free to respond if you consider any of the information incorrect. Regards Keith ------------------------------------------------------------------------ --- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu- 14.txt: "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)" (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? Keith Drage The document has been reviewed and is ready for forwarding to 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? Document history: * draft-rosenberg-sipping-gruu-reqs-00 was submitted 29th July 2003 and expired 27th January 2004. * draft-rosenberg-sipping-gruu-reqs-01 was submitted 20th October 2003 and expired 19th April 2004. * draft-rosenberg-sip-gruu-00 was submitted 20th October 2003 and expired 19th April 2004. * draft-rosenberg-sip-gruu-01 was submitted 5th December 2003 and expired 4th June 2004. * draft-ietf-sip-gruu-00 was submitted 6th January 2004 and expired 6th July 2004. * draft-ietf-sip-gruu-01 was submitted 15th February 2004 and expired 15th August 2004. * draft-ietf-sip-gruu-02 was submitted 2nd July 2004 and expired 31st December 2004. * draft-ietf-sip-gruu-03 was submitted 21st February 2005 and expired 22nd August 2005. * draft-ietf-sip-gruu-04 was submitted 14th July 2005 and expired 15th January 2006. * draft-ietf-sip-gruu-05 was submitted 28th September 2005 and expired 1st April 2006. * draft-ietf-sip-gruu-06 was submitted 20th October 2005 and expired 23rd April 2006. * draft-ietf-sip-gruu-07 was submitted 6th March 2006 and expired 7th September 2006. * draft-ietf-sip-gruu-08 was submitted 14th June 2006 and expired 16th December 2006. * draft-ietf-sip-gruu-09 was submitted 19th June 2006 and expired 21st December 2006. * draft-ietf-sip-gruu-10 was submitted 31st July 2006 and expired 1st February 2007. * draft-ietf-sip-gruu-11 was submitted 23rd October 2006 and expired 26th April 2007. * draft-ietf-sip-gruu-12 was submitted 5th March 2007 and expires 6th September 2007. * draft-ietf-sip-gruu-13 was submitted 9th April 2007 and expires 11th October 2007. * draft-ietf-sip-gruu-14 was submitted 25th June 2007 and expires 27th December 2007. WGLC was initiated in the SIP WG on draft-ietf-sip-gruu-00 on 13th January 2004 with comments requested by 28th January 2004. A second WGLC was announced on draft-ietf-sip-gruu-03 on 5th July 2004 with comments requested by 17th July 2004. A third WGLC was announced on draft-ietf-sip-gruu-06 on 26th October 2005 with comments requested by 6th November 2005. A fourth WGLC was announced on draft-ietf-sip-gruu-10 on 5th August 2006 with comments requested by 21st August 2006. A fifth WGLC was announced on draft-ietf-sip- gruu-11 on 13th November 2006 with comments requested by 27th November 2006. Review was made and comments were received during the last call identified above from: Andrew Allen, Jeroen van Bemmel, Vijay Gurbani, Paul Kyzivat, Xavier Marjo, Eric Rescorla, Robert Sparks, Dale Worley, (with an indication that all had performed a full review of the draft. During the course of the work comments have also been made by at least the following: Jesus Javier Arauz, Francois Audet, Darshan Bildikar, Spencer Dawkins, John Elwell, Miguel Garcia, Michael Hammer, Juha Heinanen, Christer Holmberg, Cullen Jennings, Erkki Koivusalo, Jiri Kuthan, Scott Lawrence, Rohan Mahy, Peter Musgrave, Kasturi Narayanan, Aki Niemi, Klaus Nieminen, Sean Olsen, Michael Proctor, Adam Roach, Brian Stucker, Dean Willis (in addition to the above). See also the acknowledgements list in the document. See http://www.softarmor.com/sipwg/reviews/gruu/index.html for documentation of the final extensive review. There have been key issues in the discussion that have been resolved to the satisfaction of the SIP working group, but which are worth mentioning here: * A grid parameter existed as part of the earlier drafts up to draft- ietf-sip-gruu-10. The GRID parameter was removed from GRUU in response to comments received. Instead, loose routing is proposed to provide the ability of 'end-instance switching'. The gr URI parameter (formerly gruu URI parameter) now takes a value, replacing opaque as the server-side 'switch'. * Up to and including draft-ietf-sip-gruu-10, GRUU did not provide any anonymity functions at all. Indeed, the recommendations for construction of gruus were such that they would contain the users AOR. The point was raised that there were many places, such as Europe, where anonymous calls are the norm. This is because privacy laws require that caller ID be given out as an opt-in feature, and the default is privacy. Conclusion in -11 was that serial pseudonymity is provided. A user is given lots of anonymous GRUU, allowing it to use a different one for each call. Each remain valid the entire duration of the registration. (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? Whilst not specifically a security related document, the document has been reviewed by Eric Rescorla (the security adviser to the SIP working group), and there are no remaining unresolved issues. (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. The document defines a new SIP protocol extension for a particular purpose in a form that has been used for many other extensions. The document shepherd has no concerns with the document. There is one patent disclosure against this document from Microsoft Corporation. They have indicated they are prepared to license any rights on the basis of "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee". This has been brought to the attention of the working group and no concerns were expressed. (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 document has been well discussed and extensively reviewed by a significant number of members of the working group (see answer in 1(b)). (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.) None indicated. (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? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is believed that the document is conformant with those guidelines. While the document defines a new SIP option tag, these have been performed as a SIP working group item, and therefore this draft is in conformance with RFC 3427. The document passes ID-NITS (idnits 2.04.09) with the exception of the following: ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. (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]. The document has split its references into normative and informative references. All the normative references are appropriate normative references. All the normative references are published except: * reference [13] to draft-ietf-sip-outbound which is still in the final stages of development within the SIP working group. All the normative references are standards track documents except: * reference [4] to RFC 2119 which is a BCP. * reference [8] to RFC 3968 which is a BCP. * reference [9] to RFC 3969 which is a BCP. All the informative references are also published except: * reference [18] to draft-ietf-sipping-cc-transfer which is still in progress in the SIPPING WG. * reference [27] to draft-ietf-sipping-gruu-reg-event for which publication has been requested by the SIPPING WG. * reference [28] to draft-rosenberg-sip-ua-loose-route for which a charter milestone exists in the SIP WG, and for which this is a candidate. (1.i) Has the Document Shepherd verified that the document's IANA Considerations 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 the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? Section 11.1 of the document registers two new header field parameters. This registration is consistent with RFC 3968 which defines the registry and is also consistent with the current format of the registry. Section 11.2 of the document registers a new SIP URI parameter. This registration is consistent with RFC 3969 which defines the registry and is also consistent with the current format of the registry. Section 11.3 of the document registers a new option-tag; the new option-tag is defined elsewhere in the document. This registration is consistent with RFC 3261 which defines the registry and is also consistent with the current format of the 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? The ABNF within the document passes the checks in Bill Fenner's ABNF parsing web service. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. Working Group Summary The document complements work already performed in RFC 4474 for authenticated request identity, and forms an integral part of the chartered work in this area. There is consensus in the working group to publish this document. Document Quality The document has been well discussed by a significant number of members of the working group. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings. 'The IANA Expert(s) for the registries in this document are <TO BE ADDED BY THE AD>. _______________________________________________ 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
- [Sip] Publication request for draft-ietf-sip-gruu… DRAGE, Keith (Keith)