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

Alissa Cooper <alissa@cooperw.in> Fri, 18 April 2014 21:09 UTC

Return-Path: <alissa@cooperw.in>
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 437A51A0495 for <cuss@ietfa.amsl.com>; Fri, 18 Apr 2014 14:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 QMB7AxZsmpJ9 for <cuss@ietfa.amsl.com>; Fri, 18 Apr 2014 14:09:26 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id D66121A043E for <cuss@ietf.org>; Fri, 18 Apr 2014 14:09:25 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7BA30217AD for <cuss@ietf.org>; Fri, 18 Apr 2014 17:09:21 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 18 Apr 2014 17:09:21 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=Es/2kvqqJVLIn5MvZ1VaAYAsGPc=; b=lXKESDIJ5ffNlFc+h8PSqblSmHzt c6TpVhUDZfQSaAo8eRSqCoWnb2a6zuOZBEo0zSBqDeT+ihUdmL++J+GPtGfPalYu 0zzeWcbedoLQTmtEQmhr8EO/c+kTmiSftuNuGgPTITmp3RH0KMC4vhKt2Nj11Ia8 8LwOkcLyT2Nb0DU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=Es/2kvqqJVLIn5MvZ1VaAY AsGPc=; b=Fj8XPDYo1A/7EDeghXOR1Jr6D86OUgMOgWMuOR8dhsP78ieQPQR7Rg yAHEWwCgvjR5t1riQKzgWY7gfEtnBAh7RrNpdyVJ8pXX74rexYicJFXV2tASWhL7 EN570mrfFq4T9R4vauBrzQyLbvb57WnD4AYufdV9O0O10MYBBKZM0=
X-Sasl-enc: 1LY8kR2zEOiSNg2r97tbBCroytLexOFGVdqcWFwmSzPo 1397855359
Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 86A40C0000C; Fri, 18 Apr 2014 17:09:18 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Fri, 18 Apr 2014 14:09:12 -0700
From: Alissa Cooper <alissa@cooperw.in>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Alan Johnston <alan.b.johnston@gmail.com>
Message-ID: <CF76E26E.34E6F%alissa@cooperw.in>
Thread-Topic: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui
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> <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534D8474.70403@alum.mit.edu> <03fd01cf58f2$03946320$0abd2960$@humancomm.com> <534E9FBC.3000508@alum.mit.edu> <CAKhHsXE2JsDmpwUmEOtAA9a5PN-qBu+UCYzoN01CLzjZ8qfmCA@mail.gmail.com> <534EB3BA.6070504@alum.mit.edu>
In-Reply-To: <534EB3BA.6070504@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/6m6zfpYSJ4eYJW2OXI4CwsAKK3c
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: Fri, 18 Apr 2014 21:09:30 -0000

On 4/16/14, 9:45 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 4/16/14 12:11 PM, Alan Johnston wrote:
>> Paul,
>>
>> So we are in agreement, then.  Keep this draft at Standards Action for
>> new packages so we can keep control over how this mechanism is used.
>>
>> Your proposal sounds very interesting for opening things up, and if
>> published as a standards track document would allow for exactly what you
>> want.
>
>Perhaps, to resolve the IESG concern over the use of Standards Action,
>we could add some text indicating that this is conservative choice made
>while we if and how to open it up.

This sounds like a reasonable resolution to me.
Alissa

>
>	Thanks,
>	Paul
>
>> - Alan -
>>
>>
>> On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>     On 4/15/14 5:30 PM, James Rafferty wrote:
>>
>>         Hi,
>>
>>         As Alan noted, we seem to be having two discussions here.  What
>>         I thought
>>         we'd be talking about is what level of IANA action is needed.
>>           Recent drafts
>>         set that bar at "Standards Action."  I'm personally open to the
>>less
>>         rigorous definition of "Specification Required," which would
>>allow
>>         organizations outside of the IETF to define packages, but would
>>         still imply
>>         that the guidelines in Section 5 would continue to be enforced.
>>           However,
>>         there hasn't been any discussion about such a middle ground.
>>
>>         Paul, would lowering the bar to "Specification Required" help
>>         offer some of
>>         the flexibility you want?  This would allow other packages to be
>>         defined --
>>         inside or outside the IETF -- but would still imply adherence
>>to the
>>         guidelines in section 5.  This would also bring a "designated
>>         expert" into
>>         play, in order to provide review of the proposed specification.
>>
>>
>>     I don't think reducing to "Specification Required" would address my
>>     concerns in any way. I don't even think reducing to FCFS would do
>>that.
>>
>>     Frankly, *for now* I am satisfied to leave the requirement at
>>     Standards Action, with the understanding that this is just temporary
>>     to get the basic mechanism (with the ISDN package) published. That
>>     allows us to keep control and so prevent something stupid being
>>done.
>>
>>     Then I think there should be further discussion about how purpose,
>>     content, and encoding *should* be used, and what sorts of
>>     registration policies would facilitate that.
>>
>>     My thinking is that it should be something like feature tags, with
>>     the namespace partitioned, so there can be some values with
>>     standardized values, and another part of the namespace that can be
>>     used by individual enterprises without need of registration while
>>     still preventing collision.
>>
>>         On some of the other points:
>>
>>         -- Encodings -- I would not expect too many of those to be
>>         defined; my
>>         former company  supported the current binary definition and an
>>         earlier ASCII
>>         encoding
>>
>>
>>     Yes. Me too. But it would be useful to have a discussion of what
>>     might be other meaningful values.
>>
>>     I personally would have liked to also see a "text" (or "ascii" or
>>     whatever) encoding. I think many uses would find this sufficient,
>>     and it would be much more readable for diagnosing call flows, for
>>     examples, etc.
>>
>>     Beyond that I don't know. It depends on how the line is drawn
>>     between content and encoding.
>>
>>         -- Purpose -- This is the rationale behind having a separate
>>package
>>
>>
>>     Once we get beyond ISDN, I see Purpose as being the primary
>>     mechanism for ensuring that sender and receiver are compatible.
>>
>>         -- Content -- allows for further elaboration on what kinds of
>>         semantic
>>         information are supported; see section 5.1 on extensibility
>>
>>
>>     I think it is likely that there would be only one content per
>>     purpose, and so it will be redundant. OTOH, the purpose could be
>>     treated as a sort of interface, with the content naming individual
>>     messages within the interface.
>>
>>              Thanks,
>>              Paul
>>
>>         James
>>
>>
>>         -----Original Message-----
>>         From: cuss [mailto:cuss-bounces@ietf.org
>>         <mailto:cuss-bounces@ietf.org>] On Behalf Of Paul Kyzivat
>>         Sent: Tuesday, April 15, 2014 3:12 PM
>>         To: DRAGE, Keith (Keith); 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/15/14 4:24 AM, DRAGE, Keith (Keith) wrote:
>>
>>             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.
>>
>>
>>         It doesn't matter if the call center is connected to the PSTN.
>>         What matters
>>         is the source and destination of the UUI. There is a pretty good
>>         chance that
>>         those will be connected with sip - probably within the same
>>         enterprise.
>>
>>         Everybody using the ISDN package is a *problem*, because it has
>>         no way to
>>         distinguish different usages that don't interoperate.
>>
>>         The point I'm making is that most of the usages *won't* be
>>         public. (Are
>>         there *any* that *are*?)
>>
>>         I write a VXML application for my business. It collects some
>>         information,
>>         and then forwards the call to an ACD, passing the collected
>>         information via
>>         UUI. The format and purpose of that data is specific to my
>>         particular VXML
>>         app and the application the call center operators use. Who is
>>         going to write
>>         an RFC to define that? (Nobody!) If that accidentally ends up at
>>         the "wrong"
>>         app, how will it be detected that it is wrong? (Hopefully by the
>>         purpose and
>>         content attributes of the UUI.)
>>
>>         How do you imagine purpose and content being used, such that
>>         somebody would
>>         be in a position to write an RFC to define them?
>>
>>                  Thanks,
>>                  Paul
>>
>>             Keith
>>
>>
>>         
>>------------------------------__------------------------------__---------
>>---
>>
>>                   *From:* Alan Johnston
>>             [mailto:alan.b.johnston@gmail.__com
>>             <mailto:alan.b.johnston@gmail.com>]
>>                   *Sent:* 15 April 2014 03:44
>>                   *To:* Paul Kyzivat
>>                   *Cc:* DRAGE, Keith (Keith); cuss@ietf.org
>>             <mailto: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>
>>                   <mailto: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>
>>                               <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>
>>             <mailto: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>>
>>                                   <mailto: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>>
>>                                   <mailto: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>
>>
>>               <https://www.ietf.org/mailman/____listinfo/cuss
>>             <https://www.ietf.org/mailman/__listinfo/cuss>>
>>
>>               <https://www.ietf.org/mailman/____listinfo/cuss
>>             <https://www.ietf.org/mailman/__listinfo/cuss>
>>
>>               <https://www.ietf.org/mailman/__listinfo/cuss
>>             <https://www.ietf.org/mailman/listinfo/cuss>>>
>>
>>
>>
>>
>>               ___________________________________________________
>>                               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>
>>
>>               <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
>>         <https://www.ietf.org/mailman/listinfo/cuss>
>>
>>
>>
>>
>
>_______________________________________________
>cuss mailing list
>cuss@ietf.org
>https://www.ietf.org/mailman/listinfo/cuss