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

Alan Johnston <alan.b.johnston@gmail.com> Tue, 15 April 2014 02:44 UTC

Return-Path: <alan.b.johnston@gmail.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 BD8221A030C for <cuss@ietfa.amsl.com>; Mon, 14 Apr 2014 19:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 r2Nb71N-baYs for <cuss@ietfa.amsl.com>; Mon, 14 Apr 2014 19:44:19 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 738FF1A030B for <cuss@ietf.org>; Mon, 14 Apr 2014 19:44:19 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w61so9001972wes.1 for <cuss@ietf.org>; Mon, 14 Apr 2014 19:44:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V2p3+5mFNVOpUoi/zk3Abep5ZTGsKeydnXfB08D/KLk=; b=boca/gGcpSyNRpiCcRQjkr8XmpszgL0fIk1jkkbx8Mu09aUeAlfw+AtsC9TJfqzasM fJth29wBpRhC3flc5ICokJSN9LpzfwechZ3qOVAJa7QWbcIcalcxxHsWU7yRI8PmLFLP nHXcumSQiMzsp8JqKCV5HxYHceKLIXHCCRYgRPXJ/vkL3rt8xUB2ovJp+p8C+/GEvbqj q+CpZiNJKXG4/mlYC/BTC5/CrUzx+MhzF6xRFda1ER3lcUgndjMDTBMyamIPz2Dvr/z8 gR/bPlLytMDTcixWsSafVCpjJ2/4QNUHcpVYDjjSgRyjtWboo9sfSFclvq/r0XssQrsm mRpg==
MIME-Version: 1.0
X-Received: by 10.194.60.114 with SMTP id g18mr3924wjr.61.1397529854901; Mon, 14 Apr 2014 19:44:14 -0700 (PDT)
Received: by 10.217.152.10 with HTTP; Mon, 14 Apr 2014 19:44:14 -0700 (PDT)
In-Reply-To: <534C9283.3010206@alum.mit.edu>
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>
Date: Mon, 14 Apr 2014 21:44:14 -0500
Message-ID: <CAKhHsXECj+HsBNYju8kE8yUJ9-ijdvs6KTPnnO6wW_4A_UqRXw@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="047d7b66f33d9083d904f70bc666"
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/ncT13AYIcf5LctBXWWTVjLwAqTM
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 02:44:23 -0000

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> 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] 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
>>>
>>>
>