From vkg@bell-labs.com Thu Sep 6 06:42:23 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35D221F84F5 for ; Thu, 6 Sep 2012 06:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTe4-s6U+Kip for ; Thu, 6 Sep 2012 06:42:23 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2783821F844D for ; Thu, 6 Sep 2012 06:42:23 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q86DgLJ2006055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Sep 2012 08:42:21 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q86DgLSu009589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Sep 2012 08:42:21 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q86DgKNZ022406 for ; Thu, 6 Sep 2012 08:42:21 -0500 (CDT) Message-ID: <5048A856.2080101@bell-labs.com> Date: Thu, 06 Sep 2012 08:42:46 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: cuss@ietf.org References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> In-Reply-To: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [cuss] Fwd: Help the NomCom: Nominations and Feedback X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:42:24 -0000 -------- Original Message -------- Subject: Help the NomCom: Nominations and Feedback Date: Wed, 05 Sep 2012 17:21:29 -0700 From: NomCom Chair To: Working Group Chairs The IETF Nominations Committee (NomCom) is currently seeking nominations for individuals to serve on the IESG, IAB, and IAOC. Additionally, this is an announcement that the NomCom is seeking feedback on individuals who have accepted nominations for IETF leadership positions. It is very important to the NomCom process that we get input from a broad spectrum of the community. Therefore, in case members of your working group do not read the IETF announcement and discussion lists, the NomCom would appreciate your help in disseminating the following information. The NomCom website contains information about this year's NomCom including the positions we are seeking to fill, and the qualifications required for these positions: https://www.ietf.org/group/nomcom/2012/ The NomCom is accepting nominations until September 24. Nominations for any position can be made using the following web tool: https://www.ietf.org/group/nomcom/2012/nominate Feedback about individuals who the NomCom is considering can be providing using the following web tool: https://www.ietf.org/group/nomcom/2012/input The feedback tool provides a list of individuals who have agreed to be considered for each position. We will be updating this list in the coming weeks as more individuals accept nominations. Feedback provided to the NomCom is kept strictly confidential! Note that use of the NomCom web tools require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ As an alternative to using the web tools, you can send email to the NomCom at nomcom12@ietf.org to make a nomination or provide input to the committee. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Fri Sep 21 12:52:56 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEB021F849B for ; Fri, 21 Sep 2012 12:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.932 X-Spam-Level: X-Spam-Status: No, score=-107.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcg62k3WjIYx for ; Fri, 21 Sep 2012 12:52:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 172C321F8575 for ; Fri, 21 Sep 2012 12:52:54 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q8LJqrki020268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Sep 2012 14:52:53 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q8LJqrgp015091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 21 Sep 2012 14:52:53 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q8LJqqVH019660 for ; Fri, 21 Sep 2012 14:52:53 -0500 (CDT) Message-ID: <505CC5B8.7010409@bell-labs.com> Date: Fri, 21 Sep 2012 14:53:28 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Shepherd writeup for draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 19:52:56 -0000 All: I am the document shepherd for draft-ietf-cuss-sip-uui. I have completed the shepherd writeup, and it is included below. --- Begin shepherd writeup (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? draft-ietf-cuss-sip-uui is a Standards Track document (Proposed Standard). The title page of the draft reflects this RFC type. I believe that this is the proper type to categorize this draft because the drafts defines a new SIP header field, an associated SIP option tag, and establishes three new sub-registries under SIP parameter registry. Furthermore, it also provides guidelines for SIP user agents and intermediaries on how to handle the new parameter. (2) 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 a new SIP header field, User-to-User Information (UUI), to transport data between two SIP user agents opaquely. Also defined is an extension mechanism for new UUI packages. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was nothing contentious during the WG process worth noting. Certain aspects like getting the right semantics for the hex encoding of the UUI data, whether or not conversion between encodings will be allowed at gateways, etc., engendered email discussions but consensus was reached by all concerned parties equitably. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are reported implementations of earlier version of the draft from Avaya, Dialogic and Audiocodes. This is work that other SDOs (3GPP) are waiting for. Laura Liess and Shida Schubert deserve mention for WGLC related to this draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Vijay K. Gurbani Responsible AD: Gonzalo Camarillo (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I reviewed the document for completeness, and besides one nit in Section 1 and an unreferenced reference ([ETSI]), I could not find anything structurally wrong with the document to warrant a delay in publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, The document was reviewed by Laura Liess, who has a long history of participating in the WG. The document was also reviewed by Shida Schubert to ensure compliance to rfc4244bis (History-Info). With reviews by Laura and Shida, I believe that the document has been exposed to both a focused as well as a broad review. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document was reviewed by Shida Schubert to ensure compliance to rfc4244bis (History-Info). Additionally, the CUSS mailing list has subscribers from other related working groups (SIPCORE) and these subscribers have been contributing a sizeable effort of their time providing comments on the list. The document has been a beneficiary of such comments. (6) Describe any specific concerns or issues that the Document Shepherd has 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. I do not have any specific concerns or issues regarding this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, I sent an email to the authors regarding IPR disclosures on Sept-17-2012. I received an email response on the same day from all authors indicating that they are not aware of any IPR disclosures. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. As far as I am aware of, there has not been any IPR disclosure filed that references this document. (9) 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 behind the document is strong. The WG mailing list has subscribers from related working groups (SIPCORE) participating in it, and these subscribers have contributed thoughts and ideas to the draft. The WG as a whole understands and agrees with the document. (10) 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 publicly available.) No one has threatned an appeal or otherwise indicated extreme discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. - There are 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. - Unused Reference: 'ETSI' is defined on line 721, but no explicit reference was found in the text - Unused Reference: 'RFC3324' is defined on line 762, but no explicit reference was found in the text - Downref: Normative reference to an Informational RFC: RFC 3324 - Downref: Normative reference to an Informational RFC: RFC 3325 - Downref: Normative reference to an Informational RFC: RFC 6567 - Outdated reference: A later version (-09) exists of draft-ietf-sipcore-rfc4244bis-08 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has an IANA considerations section that is appropriately filled out. It does not require reviews related to MIBs. (13) Have all references within this document been identified as either normative or informative? Yes, however, there is a reference ([ETSI]) that appears in the list of Informative References but is not referenced in the text itself. (14) 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 plan for their completion? There is one normative reference that refers to an I-D ([I-D.ietf-sipcore-rfc4244bis]). Besides this, all normative references refer to RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There is one normative reference referring to an Internet-Draft: [I-D.ietf-sipcore-rfc4244bis] Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", draft-ietf-sipcore-rfc4244bis-08 (work in progress), April 2012. There are three other downward references that point to RFCs: - Downref: Normative reference to an Informational RFC: RFC 3324 - Downref: Normative reference to an Informational RFC: RFC 3325 - Downref: Normative reference to an Informational RFC: RFC 6567 Of these, the reference to RFC3224 is a dangling reference and the authors will be asked to remove this before publication. So, that leaves downward references to two RFCs: 3325 (P-Asserted-Identity) and 6567 (Problem statement for UUI). In my estimation, retaining these two downward references should not pose a problem since RFC3325 is well known within the (SIP) community and RFC6567 is the requirement document for the User-to-User header itself. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The publication of this document will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section is sound. More specifically: (a) The document updates the existing SIP parameter registry by adding a new row that reserves a new header name, User-to-User; (b) The document updates the existing SIP parameter registry by adding three parameters to the new User-to-User header --- encoding, content and purpose; (c) The document establishes three new sub-registries under http://www.iana.org/assignments/sip-parameters; these sub-registries are described adequately in the document, including providing default values where application; (d) The document reserves a new SIP option tag as per the guidelines of Section 27.1 of RFC3261. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The IANA registries defined in the document have a policy definition of "RFC Required". It was felt that having the IETF LC on any new usages of UUI would be beneficial to bring to the attention of the IESG any new work that derived from this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. I have reviewed Section 4.1 (contains ABNF syntax for User-to-User header field) and found all production rules to result in appropriate terminals. I have also reviewed the IANA consideration section to make sure that the information required for User-to-User extension packages is well specified. I did not find anything of concern in my review of these sections. --- End shepherd writeup Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Fri Sep 21 13:04:58 2012 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639DA21F867B for ; Fri, 21 Sep 2012 13:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XoBWGF7juTq for ; Fri, 21 Sep 2012 13:04:57 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5C21F8625 for ; Fri, 21 Sep 2012 13:04:54 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q8LK4oBJ009502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Sep 2012 15:04:51 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q8LK4oQt027371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Sep 2012 15:04:50 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q8LK4okR011803; Fri, 21 Sep 2012 15:04:50 -0500 (CDT) Message-ID: <505CC885.6030100@bell-labs.com> Date: Fri, 21 Sep 2012 15:05:25 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: draft-ietf-cuss-sip-uui@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: cuss@ietf.org Subject: [cuss] Nits on draft-ietf-cuss-sip-uui X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 20:04:58 -0000 Alan, James: I have requested publication for your draft. While going through the draft, I found a couple of nits that I want to document. Please attend to these along with the comments that you will get from the IESG review. - S1, first paragraph: s/a priori/a-priori/ - idnits reports the following, please fix these: - There are 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. - Unused Reference: 'ETSI' is defined on line 721, but no explicit reference was found in the text - Unused Reference: 'RFC3324' is defined on line 762, but no explicit reference was found in the text - Outdated reference: A later version (-09) exists of draft-ietf-sipcore-rfc4244bis-08 That's it! Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/