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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 16 April 2014 16:45 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 A281A1A0272 for <cuss@ietfa.amsl.com>; Wed, 16 Apr 2014 09:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MJK0IwTbhcKD for <cuss@ietfa.amsl.com>; Wed, 16 Apr 2014 09:45:52 -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 CC8731A0273 for <cuss@ietf.org>; Wed, 16 Apr 2014 09:45:50 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id qcpp1n0091ei1Bg53glnNN; Wed, 16 Apr 2014 16:45:47 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id qglm1n00g3ZTu2S3kglnfE; Wed, 16 Apr 2014 16:45:47 +0000
Message-ID: <534EB3BA.6070504@alum.mit.edu>
Date: Wed, 16 Apr 2014 12:45:46 -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: 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> <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>
In-Reply-To: <CAKhHsXE2JsDmpwUmEOtAA9a5PN-qBu+UCYzoN01CLzjZ8qfmCA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397666747; bh=LSIHng2qORVjgebFOy7mZZd1DmDPzqiIchWTtXsor44=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=H6GfiZPafxi9lpb1f8eS1UGo2N6DPtbSQ38vaik/0C85s5AWI7sEJV5yDNDTGJcDN 7MAM7Q9IDuqFpFabodkPGpkYHHcAEGUWKFcUVZJpsY+uqP6iT6H0fvjtm3fofrUtyo /97oUSnBuZNdA20iuaJwlR7khjj8vWOp7NjfEU+axvbi11eVZOMaVHmDJMKjVibwiJ 7YxLH8RHEbLfjN7DrKZAYt9vOhcj0/YaTNS5qpdGYow7rKMbiWTLyP+ozDqZqHtQSx fMa5WCJoBLwCEME+Ta9zOVOBcAUagUlLT2XDAiRlq/16Ps9ygSnML0ck8XFD2M0s7D 7X/Izc+ncaOFA==
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/YBkE4O2nO5Dd19a1trVY_DmFhSU
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: Wed, 16 Apr 2014 16:45:54 -0000

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.

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