Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui
"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 15 April 2014 08:24 UTC
Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: cuss@ietfa.amsl.com
Delivered-To: cuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C71A0395 for <cuss@ietfa.amsl.com>; Tue, 15 Apr 2014 01:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU7-EImROuAW for <cuss@ietfa.amsl.com>; Tue, 15 Apr 2014 01:24:28 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B59481A06E0 for <cuss@ietf.org>; Tue, 15 Apr 2014 01:24:28 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s3F8OL4x028010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Apr 2014 03:24:22 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s3F8OKNI011862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 10:24:20 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 15 Apr 2014 10:24:20 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Alan Johnston <alan.b.johnston@gmail.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui
Thread-Index: AQHPT4pBb4V/ZbOWiECsn8iI8uuD3psBZOsAgAAlNICAAC4qgIAE6Y4wgAs6O4CAAAx/AIAAdUjA
Date: Tue, 15 Apr 2014 08:24:19 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <CAKhHsXFSXaY=Ch_YKfVN6AyYmF_UCVzy4wdoj-mBjLKXjHyGsQ@mail.gmail.com> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <CAKhHsXECj+HsBNYju8kE8yUJ9-ijdvs6KTPnnO6wW_4A_UqRXw@mail.gmail.com>
In-Reply-To: <CAKhHsXECj+HsBNYju8kE8yUJ9-ijdvs6KTPnnO6wW_4A_UqRXw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B187709FR712WXCHMBA11zeu_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/4OHSR2UZfMTDNwWPLGuQTb2hB_8
Cc: "cuss@ietf.org" <cuss@ietf.org>
Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui
X-BeenThere: cuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" <cuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cuss>, <mailto:cuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cuss/>
List-Post: <mailto:cuss@ietf.org>
List-Help: <mailto:cuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cuss>, <mailto:cuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 08:24:32 -0000
In the use cse Paul had been giving, I have an assumption that the ISDN package would be used (because call centers) are connected to the PSTN as well. This would be effectively a privately defined protocol running over the top, and signalled as such. If you want a public protocol (i.e. standardised) running over the top, the package definition, or any other UUI parameters, could be coupled with the RFC that defines it. Keith ________________________________ From: Alan Johnston [mailto:alan.b.johnston@gmail.com] Sent: 15 April 2014 03:44 To: Paul Kyzivat Cc: DRAGE, Keith (Keith); cuss@ietf.org Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui Paul, Keith and I have been discussing this in terms of new packages, which can define all new SIP semantics, but I notice in your response you are mainly talking about contents. Perhaps we could have different requirements for these: the specification required for new packages, but something lower for contents. I'm not completely sure where encodings would fit in this scheme. What do you think? - Alan - On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote: On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: I believe we would want the guidelines enforced. I also expect that we would want to do a further review of the guidelines if they are the sole basis for allowing packages in or not, before we allowed a relaxation of the approval regime. I think the effect of the registration rules will be that no new registrations are made, and the default will be used by everyone, as is currently the case. That means that everyone depends upon configuration to ensure that client and server agree on usage. If you are running a call center, and decide what information you need to communicate from your IVR to your ACD, are you going to publish an RFC to register the format for that? I think not. Even a FCFS registration is probably too much. Yet it would still be good to ensure that client and server are using the same formats. When I raised this issue early on, I got no traction for it, so I decided to let it go until people had deployment experience. Then they could figure out they need something different. But now it has come up again. Thanks, Paul Regards Keith -----Original Message----- From: cuss [mailto:cuss-bounces@ietf.org<mailto:cuss-bounces@ietf.org>] On Behalf Of Paul Kyzivat Sent: 04 April 2014 20:31 To: Alan Johnston Cc: cuss@ietf.org<mailto:cuss@ietf.org> Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui On 4/4/14 12:46 PM, Alan Johnston wrote: Paul, I know you've explained this before. But you haven't explained how the requirements in Section 5. Guidelines for UUI Packages can be enforced if there isn't any review. Can you elaborate on this? With no review these couldn't be enforced. They could still remain as guidelines. Thanks, Paul - Alan - On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu> <mailto:pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>> wrote: Interesting to see this come back. My original opinion was (and still is) that for these to be useful, it must be possible for using enterprises to assign new values for each distinct deployment of an application. IMO even FCFS might be too high a bar for this. E.g., if I create a particular VXML application that captures some data and communicates it to a call center agent application via UUI, then the format of that data is likely to be unique. Lowering the bar below FCFS would require a naming scheme that guarantees uniqueness without registration. Thanks, Paul On 4/3/14 6:17 PM, Vijay K. Gurbani wrote: All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the "Standards Action" guideline for defining UUI packages and registering new IANA elements for the parameter tables for purpose, encoding and content. The draft authors note that the original concern when the work was coming out of Dispatch was that the UUI not become a "wildcard" header to be used for a wide variety of purposes. Hence the direction toward requiring a standards track RFC. However, a lesser standard such as "Specification Required" might suffice and offer more flexibility for additional use cases, while not opening up the process totally as would be the case for "First Come First Serve." The IESG will like to revisit this decision to confirm that the WG decisions remains "Standards Action". To that end, Enrico and I will like to open up a 2-week period to ratify this decision to remain at "Standards Action" or to move to something other designation. The 2-week period ends on close of business (US Central Time) April 17, 2014. Please express an opinion; if you are for keeping status quo, please send a one-liner to the cuss WG mailing list. If you are of the opinion that we should relax the burden, please state so and a short reason on why we should do so. Thank you all. - vijay _________________________________________________ cuss mailing list cuss@ietf.org<mailto:cuss@ietf.org> <mailto:cuss@ietf.org<mailto:cuss@ietf.org>> https://www.ietf.org/mailman/__listinfo/cuss <https://www.ietf.org/mailman/listinfo/cuss> _______________________________________________ cuss mailing list cuss@ietf.org<mailto:cuss@ietf.org> https://www.ietf.org/mailman/listinfo/cuss
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alissa Cooper
- Re: [cuss] Ratification of "Standards Action" gui… DRAGE, Keith (Keith)
- [cuss] Ratification of "Standards Action" guideli… Vijay K. Gurbani
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alan Johnston
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alan Johnston
- Re: [cuss] Ratification of "Standards Action" gui… DRAGE, Keith (Keith)
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alan Johnston
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alissa Cooper