Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 15 April 2014 01:59 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 DAB9A1A0259 for <cuss@ietfa.amsl.com>; Mon, 14 Apr 2014 18:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.165
X-Spam-Level:
X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 1y900VbOMT41 for <cuss@ietfa.amsl.com>; Mon, 14 Apr 2014 18:59:34 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4E41E1A067E for <cuss@ietf.org>; Mon, 14 Apr 2014 18:59:34 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id q1ED1n0070Fqzac531zXk0; Tue, 15 Apr 2014 01:59:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id q1zX1n00H3ZTu2S3U1zXCW; Tue, 15 Apr 2014 01:59:31 +0000
Message-ID: <534C9283.3010206@alum.mit.edu>
Date: Mon, 14 Apr 2014 21:59:31 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, Alan Johnston <alan.b.johnston@gmail.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>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.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=q20140121; t=1397527171; bh=NYOi1Ouogc0ZIk1j8l0VE93TYcsOBmSdGi/Aix/EwMg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G87kXelUS7shyjAx+9RFASS3pQrFy3llaEW6zLzNB0aEQ/P98JegZyDy2q6h9186G q048Jrbz5VtDYLWkxVDn88nuB6C++v0+XByU6hZ66tnI76cps1s8siwmXHOnWhJf9n rCZpH2bGlGxw66jzAAmAyQHJR7Tv8zkYB/vJ/fukHJrNL2DuU4rwU8kDFsuF1FBwZ+ F2lX8XCYvfXXqCODOFSpmMcC11yVD8zfBGai1Ae4+C1tfgcKoJ8TbNtKGrgZeLTSgK 7OqEwiv6HJ19dqb68uzRdLa3HL3uSCvbrkhJhc1L4VWBhaI3gk2Ipc0Fx0QftrAurH beqralGRkZDOw==
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/cHZKvqiM_y0zt74ZZXwvk0f4kIc
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 01:59:36 -0000

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] On Behalf Of Paul Kyzivat
>> Sent: 04 April 2014 20:31
>> To: Alan Johnston
>> Cc: 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>> 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>
>>>      https://www.ietf.org/mailman/__listinfo/cuss
>>>      <https://www.ietf.org/mailman/listinfo/cuss>
>>>
>>>
>>
>> _______________________________________________
>> cuss mailing list
>> cuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/cuss
>>