From gonzalo.camarillo@ericsson.com Mon Jan 7 03:52:45 2013 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 4E01F21F853C for ; Mon, 7 Jan 2013 03:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 WRJuiwZQCMVi for ; Mon, 7 Jan 2013 03:52:44 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85D21F86AC for ; Mon, 7 Jan 2013 03:52:43 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-ce-50eab70a1e11 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E4.E4.04318.A07BAE05; Mon, 7 Jan 2013 12:52:42 +0100 (CET) Received: from [131.160.36.111] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 7 Jan 2013 12:52:41 +0100 Message-ID: <50EAB709.8020902@ericsson.com> Date: Mon, 7 Jan 2013 13:52:41 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: James Rafferty References: <20121201234440.4158.91490.idtracker@ietfa.amsl.com> <50BC6491.9080604@ericsson.com> <54633A5E61DC84429CB9FE3D9143C721E6F513B0@MBX.dialogic.com> In-Reply-To: <54633A5E61DC84429CB9FE3D9143C721E6F513B0@MBX.dialogic.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+JvjS7X9lcBBmd3iVvcaH/BbPFzQyeT A5PHka0dTB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYvuAue8FKlYqj0w8xNzA+kuli5OSQEDCR +DV1HxuELSZx4d56IJuLQ0jgJKPEn55/UM5qRomNb++xglTxCmhLPFh8kx3EZhFQkdg/Zw8T iM0mYCGx5dZ9FhBbVCBE4vr3R4wQ9YISJ2c+AYpzcIgIGEg8n8YDEmYWUJZ48a8VbKSwgJ3E n8mnWSF2zWGUOPvnL1iCU8BD4mjbLWaI6yQlFk3rZIFo1pOYcrWFEcKWl9j+dg5YjRDQbcuf tbBMYBSahWT1LCQts5C0LGBkXsXInpuYmZNebr6JERisB7f8NtjBuOm+2CFGaQ4WJXHecNcL AUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYTUSL7XyZ3Cvne/pdnrfy1w4/XnXWeb8vcZ/f onkj7mDl3rYzvF29Wgq/J/Efyw68kVPd+equc1j0XPN3UUttWp9pJJdG7IzeFv535aqX7z+m vKmUj+t+oJc6YbVuz61DaxeevBE7Rd6eIy9d/YPMrctZ6ZzZ7HJ7+B/PjXdel2w7P0s4jM9b iaU4I9FQi7moOBEAiv31uiQCAAA= Cc: "cuss@ietf.org" Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt 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: Mon, 07 Jan 2013 11:52:45 -0000 Hi James, the IANA policy to be used is an important issue and, thus, needs to be discussed in the WG. For your comments, it seems the "Standards Action" policy in RFC 5226 is what you are after. In any case, regardless of the policy you finally choose, please engage the group so that we can move this draft forward. With respect to the other comment, I agree removing the word "only" would make the sentence clearer. Thanks, Gonzalo On 28/12/2012 5:15 PM, James Rafferty wrote: > Gonzalo, > > Please see my comments below: > > James > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Monday, December 03, 2012 3:37 AM > To: cuss@ietf.org > Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt > > Authors, > > thanks for addressing my comments. I still have a couple of quick questions. > > The new draft uses RFC Required as its IANA policy. I have not seen any discussions on the mailing list about this. Has the WG considered the Specification Required policy as well? Given that the draft gives guidelines on what is appropriate to register and what is not, having a policy that involves some type of technical review (e.g., by an expert) would seem a natural choice. What were the reasons considered when making this decision? > > JR - There was a brief exchange between Keith Drage and Alan Johnston on this topic around Sept. 19, 2011 on the CUSS list, but I didn't see any immediate further discussion. See the emails with Subject: Registration requirements for new parameter values in the User-to-User header field. There were several items to be clarified at that time around what kind of content needed to be specified for new UUI applications as a result of October list discussions and an interim meeting. The result was additional IANA verbiage being added within the -03 version of the document in Section 6.4 - 6.5 stating that a Standards Track RFC was required for registering new values for the content and encoding parameters of the UUI header. > > I had a comment on the first sentence of Section 4.1 that does not seem to have been addressed. What is the meaning of "only" in this sentence? > >> The User-to-User (UUI) header field can be present in INVITE requests >> and responses only and in BYE requests and responses. > > JR - The use of "only" here now looks superfluous, since the sentence goes on to discuss another context where the UUI header can be used; it probably would be clearer if "only" is deleted. > > Thanks, > > Gonzalo > > > On 02/12/2012 1:44 AM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF. >> >> Title : A Mechanism for Transporting User to User Call Control Information in SIP >> Author(s) : Alan Johnston >> James Rafferty >> Filename : draft-ietf-cuss-sip-uui-08.txt >> Pages : 18 >> Date : 2012-12-01 >> >> Abstract: >> There is a class of applications which benefit from using SIP to >> exchange User to User Information (UUI) data during session >> establishment. This information, known as call control UUI data, is >> a small piece of data inserted by an application initiating the >> session, and utilized by an application accepting the session. The >> rules which apply for a specific application are defined by a UUI >> package. This UUI data is opaque to SIP and its function is >> unrelated to any basic SIP function. This document defines a new SIP >> header field, User-to-User, to transport UUI data, along with an >> extension mechanism. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-08 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-08 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >> >> > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From James.Rafferty@dialogic.com Tue Jan 8 11:00:30 2013 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 4C7F621F8449 for ; Tue, 8 Jan 2013 11:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 amSVnUDZ7OK3 for ; Tue, 8 Jan 2013 11:00:29 -0800 (PST) Received: from outbound.dialogic.com (outbound.dialogic.com [173.210.122.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4E621F8446 for ; Tue, 8 Jan 2013 11:00:29 -0800 (PST) Received: from MBX.dialogic.com ([fe80::bd56:b76c:8d2c:437b]) by pysxht01.dialogic.com ([::1]) with mapi; Tue, 8 Jan 2013 14:00:28 -0500 From: James Rafferty To: Gonzalo Camarillo Date: Tue, 8 Jan 2013 14:00:27 -0500 Thread-Topic: IANA Policy for New Packages in UUI Mechanism Draft (was RE: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt) Thread-Index: Ac3t0I7CPIPA1b5fSeegtmMVycNBeA== Message-ID: <54633A5E61DC84429CB9FE3D9143C721E7024EEB@MBX.dialogic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cuss@ietf.org" Subject: [cuss] IANA Policy for New Packages in UUI Mechanism Draft (was RE: I-D Action: draft-ietf-cuss-sip-uui-08.txt) 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: Tue, 08 Jan 2013 19:00:30 -0000 In the AD review of the current UUI mechanism draft (draft-ietf-cuss-sip-uu= i-08.txt), one question which came up (as per below) was on the IANA policy= which should be specified within the draft for cases where users want to r= egister a new UUI package. Over the past year, there's been some limited = discussion on this on the list. =20 In RFC 5226 (IANA Considerations Section in RFCs), there are a variety of c= hoices which are possible for an IANA policy, including "Private use", " Expert Review", "Specification Required", "RFC Required", "Standards Actio= n" and several others. =20 The policy which is currently shown for the -08 version of the draft is des= cribed as: "New uui-packages MUST follow the "RFC Required" guideline as defined in [RFC5226] and shall= be registered as a result of a standards track RFC." In his comment below= , Gonzalo correctly points out that a more concise description in RFC 5226 = which corresponds to requiring a standards track RFC approved by the IESG i= s "Standards Action". =20 To date, the only package on target to be registered with IANA is the "ISDN= Package," which is targeted as a standards track RFC. If we continue alo= ng the current path, the next UUI mechanism draft will use the "Standards A= ction" terminology as the IANA Policy for adding a new package. =20 So the question Alan Johnston and I want to pose to the list is whether the= re are any objections to proceeding with the current direction of "Standard= s Action" as the policy for establishing new UUI packages in the IANA regis= try in the UUI mechanism draft. =20 If you have opinions on this matter, please send them to the list.=20 Thanks,=20 James =20 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Monday, January 07, 2013 6:53 AM To: James Rafferty Cc: cuss@ietf.org Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt Hi James, the IANA policy to be used is an important issue and, thus, needs to be dis= cussed in the WG. For your comments, it seems the "Standards Action" policy in RFC 5226 is what you are after. In any case, regardless of the po= licy you finally choose, please engage the group so that we can move this d= raft forward. With respect to the other comment, I agree removing the word "only" would make the sentence clearer. Thanks, Gonzalo On 28/12/2012 5:15 PM, James Rafferty wrote: > Gonzalo, >=20 > Please see my comments below: =20 >=20 > James > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf=20 > Of Gonzalo Camarillo > Sent: Monday, December 03, 2012 3:37 AM > To: cuss@ietf.org > Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt >=20 > Authors, >=20 > thanks for addressing my comments. I still have a couple of quick questio= ns. >=20 > The new draft uses RFC Required as its IANA policy. I have not seen any d= iscussions on the mailing list about this. Has the WG considered the Specif= ication Required policy as well? Given that the draft gives guidelines on w= hat is appropriate to register and what is not, having a policy that involv= es some type of technical review (e.g., by an expert) would seem a natural = choice. What were the reasons considered when making this decision? >=20 > JR - There was a brief exchange between Keith Drage and Alan Johnston on = this topic around Sept. 19, 2011 on the CUSS list, but I didn't see any imm= ediate further discussion. See the emails with Subject: Registration r= equirements for new parameter values in the User-to-User header field. Th= ere were several items to be clarified at that time around what kind of con= tent needed to be specified for new UUI applications as a result of October= list discussions and an interim meeting. The result was additional IANA = verbiage being added within the -03 version of the document in Section 6.4 = - 6.5 stating that a Standards Track RFC was required for registering new = values for the content and encoding parameters of the UUI header. =20 >=20 > I had a comment on the first sentence of Section 4.1 that does not seem t= o have been addressed. What is the meaning of "only" in this sentence? >=20 >> The User-to-User (UUI) header field can be present in INVITE requests >> and responses only and in BYE requests and responses. >=20 > JR - The use of "only" here now looks superfluous, since the sentence goe= s on to discuss another context where the UUI header can be used; it probab= ly would be clearer if "only" is deleted. =20 >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 02/12/2012 1:44 AM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Call Control UUI Service for SIP Worki= ng Group of the IETF. >> >> Title : A Mechanism for Transporting User to User Call Contro= l Information in SIP >> Author(s) : Alan Johnston >> James Rafferty >> Filename : draft-ietf-cuss-sip-uui-08.txt >> Pages : 18 >> Date : 2012-12-01 >> >> Abstract: >> There is a class of applications which benefit from using SIP to >> exchange User to User Information (UUI) data during session >> establishment. This information, known as call control UUI data, is >> a small piece of data inserted by an application initiating the >> session, and utilized by an application accepting the session. The >> rules which apply for a specific application are defined by a UUI >> package. This UUI data is opaque to SIP and its function is >> unrelated to any basic SIP function. This document defines a new SIP >> header field, User-to-User, to transport UUI data, along with an >> extension mechanism. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-08 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cuss-sip-uui-08 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >> >> >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss >=20 From pkyzivat@alum.mit.edu Tue Jan 8 11:43:33 2013 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 22B0A11E80A5 for ; Tue, 8 Jan 2013 11:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_LWSHORTT=1.24, SARE_RMML_Stock10=0.13] 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 Bb2II-od9PK0 for ; Tue, 8 Jan 2013 11:43:32 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0711E80A2 for ; Tue, 8 Jan 2013 11:43:31 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id lUoN1k00b0cZkys51XjXtB; Tue, 08 Jan 2013 19:43:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id lXjX1k00C3ZTu2S3WXjXmL; Tue, 08 Jan 2013 19:43:31 +0000 Message-ID: <50EC76E2.8010205@alum.mit.edu> Date: Tue, 08 Jan 2013 14:43:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: cuss@ietf.org References: <54633A5E61DC84429CB9FE3D9143C721E7024EEB@MBX.dialogic.com> In-Reply-To: <54633A5E61DC84429CB9FE3D9143C721E7024EEB@MBX.dialogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357674211; bh=IdHRdqQXd+2/p01jqfvRKIz64E4NLeBxBTLYN/WR8oE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JR38pzeKPOrhujdxgluJOCWMCDA+BZBYzVWynU/UvU01J3LLr1ij2qpaIs8e7BZhs lQxkxz9vHCIxFcCZ/wnHzAeIrYgsSPBAyb/sswG+sY43OgqKOiqq8eZ0yiuPj1JENC tGuT4WF8e3HxfviWL3PwaRBZ7d3aM6vOXX6SILj0sihTiHQXdjS1+rHF+xVbgSU4ax LWiXHIP5FZrMoRSI1xk5MKLalEUfsqBqWn25xy3+GphdlOKzQ05wW75p8jVU/qSv9H CeU5j3u7wPCuEvtSJKH7n1RaWEp0ihbeAFSjDrvxOzE/+HE0Jq3ZbkJTFmyP3NzWHp hInPVjeB+6NWQ== Subject: Re: [cuss] IANA Policy for New Packages in UUI Mechanism Draft (was RE: I-D Action: draft-ietf-cuss-sip-uui-08.txt) 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: Tue, 08 Jan 2013 19:43:33 -0000 Early on I registered a concern about the policy, but eventually I gave up on it. But let me try again. One of the major uses of UUI is for call centers. They are likely to connect a caller to an IVR in order to get info about the caller. Once they have learned enough about what the caller wants, they transfer the call to an agent. When doing so they want to convey info learned about the caller, so it can be used by a computer to provide the agent with info. Traditionally this was handled using "ITU-T DSS1 User-user information element [Q931], [Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763] data". That uses one octet as a "protocol discriminator" and 128 octets of data. How this is used is all proprietary and ad hoc. A receiver of this data must just "know" what format the data will take. CUSS addresses backwards compatibility with this via the package "isdn-uui" registered by draft-ietf-cuss-sip-uui-isdn. IMO the intent of the UUI "purpose" and "content" parameters was to improve on the legacy situation, by allowing a sender to identify more about the data. This way a receiver can determine if it knows how to interpret what it has received. But for that to work in practice, it must be feasible for those who define the data to define the formats. For call center stuff, the data to be transmitted, and the format for representing it is likely to be defined by either: - the vendor of a particular IVR system or call center application, - OR, an individual enterprise that is deploying an IVR/call center. Neither of these is very likely to find it practical to publish an RFC. - A sw vendor could probably manage to register via a FCFS policy. - An individual enterprise probably won't find it acceptable to register *anything*. My personal feeling is that there probably ought to be several mechanisms, such as there are for feature tags. I went along with the current approach because I wasn't getting buy-in for anything else, and I figure that we can *start* with a restrictive policy and then relax it later. In the short term I gather everyone intends to stick with legacy compatibility and use what is defined in draft-ietf-cuss-sip-uui-isdn. Thanks, Paul On 1/8/13 2:00 PM, James Rafferty wrote: > In the AD review of the current UUI mechanism draft (draft-ietf-cuss-sip-uui-08.txt), one question which came up (as per below) was on the IANA policy which should be specified within the draft for cases where users want to register a new UUI package. Over the past year, there's been some limited discussion on this on the list. > > In RFC 5226 (IANA Considerations Section in RFCs), there are a variety of choices which are possible for an IANA policy, including "Private use", " > Expert Review", "Specification Required", "RFC Required", "Standards Action" and several others. > > The policy which is currently shown for the -08 version of the draft is described as: "New uui-packages > MUST follow the "RFC Required" guideline as defined in [RFC5226] and shall be registered as a result of a standards track RFC." In his comment below, Gonzalo correctly points out that a more concise description in RFC 5226 which corresponds to requiring a standards track RFC approved by the IESG is "Standards Action". > > To date, the only package on target to be registered with IANA is the "ISDN Package," which is targeted as a standards track RFC. If we continue along the current path, the next UUI mechanism draft will use the "Standards Action" terminology as the IANA Policy for adding a new package. > > So the question Alan Johnston and I want to pose to the list is whether there are any objections to proceeding with the current direction of "Standards Action" as the policy for establishing new UUI packages in the IANA registry in the UUI mechanism draft. > > If you have opinions on this matter, please send them to the list. > > Thanks, > > James > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Monday, January 07, 2013 6:53 AM > To: James Rafferty > Cc: cuss@ietf.org > Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt > > Hi James, > > the IANA policy to be used is an important issue and, thus, needs to be discussed in the WG. For your comments, it seems the "Standards Action" > policy in RFC 5226 is what you are after. In any case, regardless of the policy you finally choose, please engage the group so that we can move this draft forward. > > With respect to the other comment, I agree removing the word "only" > would make the sentence clearer. > > Thanks, > > Gonzalo > > On 28/12/2012 5:15 PM, James Rafferty wrote: >> Gonzalo, >> >> Please see my comments below: >> >> James >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf >> Of Gonzalo Camarillo >> Sent: Monday, December 03, 2012 3:37 AM >> To: cuss@ietf.org >> Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt >> >> Authors, >> >> thanks for addressing my comments. I still have a couple of quick questions. >> >> The new draft uses RFC Required as its IANA policy. I have not seen any discussions on the mailing list about this. Has the WG considered the Specification Required policy as well? Given that the draft gives guidelines on what is appropriate to register and what is not, having a policy that involves some type of technical review (e.g., by an expert) would seem a natural choice. What were the reasons considered when making this decision? >> >> JR - There was a brief exchange between Keith Drage and Alan Johnston on this topic around Sept. 19, 2011 on the CUSS list, but I didn't see any immediate further discussion. See the emails with Subject: Registration requirements for new parameter values in the User-to-User header field. There were several items to be clarified at that time around what kind of content needed to be specified for new UUI applications as a result of October list discussions and an interim meeting. The result was additional IANA verbiage being added within the -03 version of the document in Section 6.4 - 6.5 stating that a Standards Track RFC was required for registering new values for the content and encoding parameters of the UUI header. >> >> I had a comment on the first sentence of Section 4.1 that does not seem to have been addressed. What is the meaning of "only" in this sentence? >> >>> The User-to-User (UUI) header field can be present in INVITE requests >>> and responses only and in BYE requests and responses. >> >> JR - The use of "only" here now looks superfluous, since the sentence goes on to discuss another context where the UUI header can be used; it probably would be clearer if "only" is deleted. >> >> Thanks, >> >> Gonzalo >> >> >> On 02/12/2012 1:44 AM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF. >>> >>> Title : A Mechanism for Transporting User to User Call Control Information in SIP >>> Author(s) : Alan Johnston >>> James Rafferty >>> Filename : draft-ietf-cuss-sip-uui-08.txt >>> Pages : 18 >>> Date : 2012-12-01 >>> >>> Abstract: >>> There is a class of applications which benefit from using SIP to >>> exchange User to User Information (UUI) data during session >>> establishment. This information, known as call control UUI data, is >>> a small piece of data inserted by an application initiating the >>> session, and utilized by an application accepting the session. The >>> rules which apply for a specific application are defined by a UUI >>> package. This UUI data is opaque to SIP and its function is >>> unrelated to any basic SIP function. This document defines a new SIP >>> header field, User-to-User, to transport UUI data, along with an >>> extension mechanism. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-08 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-08 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>> >>> >> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >> > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From vkg@bell-labs.com Wed Jan 9 13:04:23 2013 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 2A1B721F854D for ; Wed, 9 Jan 2013 13:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.949 X-Spam-Level: X-Spam-Status: No, score=-107.949 tagged_above=-999 required=5 tests=[AWL=-1.350, 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 QwF1V1KFT2UQ for ; Wed, 9 Jan 2013 13:04:22 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 352BC21F84F6 for ; Wed, 9 Jan 2013 13:04:22 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r09L4LFx023744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 9 Jan 2013 15:04:21 -0600 (CST) 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 r09L4KLn028730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 9 Jan 2013 15:04:21 -0600 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 r09L4KfN022303 for ; Wed, 9 Jan 2013 15:04:20 -0600 (CST) Message-ID: <50EDDBCC.2020006@bell-labs.com> Date: Wed, 09 Jan 2013 15:06:20 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.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.9 Subject: [cuss] F2F meeting in March IETF? 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: Wed, 09 Jan 2013 21:04:23 -0000 Folks: The cutoff date to request a meeting for the March 2013 IETF is next week on Monday. Enrico and I need to determine if a f2f meeting is desirable. The mechanism draft is currently seeking solicitations for clarification regarding the IANA policy, as described in [1]. That appears to be the only outstanding issue on its way to publication requested (it is currently in Publication Requested stage already). Enrico and I will like to urge the WG members to respond to [1]; Paul K. has posted his response. A larger audience is sought to close this issue. Regarding the status of the ISDN-service draft, Celine had opened up a discussion item starting at the thread in [2] in July 2012. That thread seemed to have culminated in November 9 2012. So I suspect the authors of this draft can release a new version that can be moved ahead. As such, it seems we can close the open issues on the mailing list, and furthermore, Enrico and I are hoping we can do this before the March IETF, perhaps through the use of an interim meeting if the need arises. As such, does the WG need a f2f meeting? Please let us know well before Monday. While we can always reserve-and-release-if-not-needed, I personally think that doing so is a disservice to the community as anyone who has been a chair can attest to the swap-my-wg email storm that ensures when the draft agenda is released by the secretariat. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00451.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00429.html 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 pkyzivat@alum.mit.edu Wed Jan 9 14:40:17 2013 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 24DF421F84F3 for ; Wed, 9 Jan 2013 14:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 FEpJqgp-b-8p for ; Wed, 9 Jan 2013 14:40:16 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3134D21F8497 for ; Wed, 9 Jan 2013 14:40:15 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id loD61k00D1swQuc55ygFJm; Wed, 09 Jan 2013 22:40:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id lygF1k00B3ZTu2S3bygFhE; Wed, 09 Jan 2013 22:40:15 +0000 Message-ID: <50EDF1CE.1020407@alum.mit.edu> Date: Wed, 09 Jan 2013 17:40:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: cuss@ietf.org References: <50EDDBCC.2020006@bell-labs.com> In-Reply-To: <50EDDBCC.2020006@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357771215; bh=9bT3umLUuYAeXKfvx6qn207vW7nKipJY8/k7nF5eLsQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Qudc6Ip1ikqpmwRuPcg+/gTuhuKB/VVTQOGN+rkkWqC7OQJqvdkOQD6WlE3Fs3/v+ GWqkv5zJobSDoW1GUaDXF+33p18T3oMWJAWlJONr8hxXCWahX3atTcf/XL1gBYOmAq UJuKSbIHPJRUV/k2OS+0eb/gOiAhXkAIw8QxZSLiLFfIpGCn0x99wVevTxU2i82ks4 hkhMjjdTCDHf29q8AfGiKmBOaugsm28rvXaUZVVBtcufpnyWwGUREOfdGvUfLMdkvL O9KMIPXSDIIdasR+hxCHpFwLQrr/Aq9rO/6U5gawxeqL6WdVCqE0B9HnWVmzwumHOt HYxS4KgGSJ5kg== Subject: Re: [cuss] F2F meeting in March IETF? 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: Wed, 09 Jan 2013 22:40:17 -0000 I don't think there is a need for a f2f meeting *unless* there is a decision to revisit the IANA policy and to debate the pros/cons. Even then we may not need one. Note that in spite of my comment about the policy, I am not asking for it to be changed at this time. Thanks, Paul On 1/9/13 4:06 PM, Vijay K. Gurbani wrote: > Folks: The cutoff date to request a meeting for the March 2013 IETF is > next week on Monday. > > Enrico and I need to determine if a f2f meeting is desirable. > > The mechanism draft is currently seeking solicitations for > clarification regarding the IANA policy, as described in [1]. That > appears to be the only outstanding issue on its way to publication > requested (it is currently in Publication Requested stage already). > > Enrico and I will like to urge the WG members to respond to [1]; Paul > K. has posted his response. A larger audience is sought to close > this issue. > > Regarding the status of the ISDN-service draft, Celine had opened up a > discussion item starting at the thread in [2] in July 2012. That > thread seemed to have culminated in November 9 2012. So I suspect the > authors of this draft can release a new version that can be moved ahead. > > As such, it seems we can close the open issues on the mailing list, and > furthermore, Enrico and I are hoping we can do this before the March > IETF, perhaps through the use of an interim meeting if the need arises. > > As such, does the WG need a f2f meeting? Please let us know well > before Monday. While we can always reserve-and-release-if-not-needed, > I personally think that doing so is a disservice to the community as > anyone who has been a chair can attest to the swap-my-wg email storm > that ensures when the draft agenda is released by the secretariat. > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00451.html > [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00429.html > > Thanks, > > - vijay From vkg@bell-labs.com Mon Jan 14 13:01:20 2013 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 4148D21F8B71 for ; Mon, 14 Jan 2013 13:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.324 X-Spam-Level: X-Spam-Status: No, score=-109.324 tagged_above=-999 required=5 tests=[AWL=1.275, 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 IFr8jrOxEuoz for ; Mon, 14 Jan 2013 13:01:19 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD7B21F8B60 for ; Mon, 14 Jan 2013 13:01:19 -0800 (PST) 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 r0EL1I7R016333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jan 2013 15:01:18 -0600 (CST) 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 r0EL1IHs009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Jan 2013 15:01:18 -0600 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 r0EL1I2D029576 for ; Mon, 14 Jan 2013 15:01:18 -0600 (CST) Message-ID: <50F47299.4050402@bell-labs.com> Date: Mon, 14 Jan 2013 15:03:21 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [cuss] No F2F meeting in March IETF 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: Mon, 14 Jan 2013 21:01:20 -0000 Folks: Based on the rather tepid response to the question on "to meet or not to meet" in Orlando IETF, it seems that a F2F meeting is not required. Accordingly, Enrico and I will not ask for one. That said, the work has to continue. Enrico and I will like to urge the list participants to respond to Mr. Rafferty's call for opinion on the appropriate IANA policy [1]. In the absence of any other proposal, the current "Standards Action" policy will be adopted. Mr. Kyzivat has noted that this may suffice for the ISDN use case but not for others. However, he is fine if we proceed with "Standards Action" (at least that is my interpretation). So, please chime in now or we will proceed with "Standards Action". If it helps to set a deadline to close the opinion call in [1], we can go with requesting that the WG express opinions by January 28, 2013 in favor of the current approach or provide new approaches And finally, I will like to urge the authors of the ISDN use case draft that a discussion was opened up in a thread [2] in July 2012. That thread seemed to have culminated in November 9 2012. So I suspect the authors of this draft can release a new version that can be moved ahead. [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00451.html [2] http://www.ietf.org/mail-archive/web/cuss/current/msg00429.html 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/