Re: WG Review: Call Control UUI for SIP (cuss)

Cullen Jennings <fluffy@cisco.com> Fri, 09 July 2010 03:35 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90A93A6B65; Thu, 8 Jul 2010 20:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.413
X-Spam-Level:
X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvyTNnb7EEIk; Thu, 8 Jul 2010 20:35:05 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C72943A688C; Thu, 8 Jul 2010 20:35:05 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAIc1NkyrR7Ht/2dsb2JhbACgNnGlHJpVhSUEg3mESQ
X-IronPort-AV: E=Sophos;i="4.53,562,1272844800"; d="scan'208";a="223881106"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Jul 2010 03:35:10 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o693Z2Wu019250; Fri, 9 Jul 2010 03:35:03 GMT
Subject: Re: WG Review: Call Control UUI for SIP (cuss)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <AANLkTinf6-mtUKbdtw0p2j0xJQPBr4S-XCiimSNoKNdC@mail.gmail.com>
Date: Thu, 08 Jul 2010 21:35:02 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com>
References: <4C28F980.3040702@ericsson.com> <AANLkTinf6-mtUKbdtw0p2j0xJQPBr4S-XCiimSNoKNdC@mail.gmail.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: DISPATCH list <dispatch@ietf.org>, IESG IESG <iesg@ietf.org>, IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2010 03:35:06 -0000

On Jul 3, 2010, at 7:33 AM, Alan Johnston wrote:

> Many of us have worked hard on this approach over many years, and you have been involved in this at every step of the way, in both SIPPING and DISPATCH.  For you to just try to block even the formation of a working group to address this at this eleventh hour is just not right.


For better or worse, the AD's voice do strongly impact others thinking on the many subjects at IETF. As an individual contributor, my review in IETF LC pretty much my current thoughts on it. However, if I had sent that same review when I was an AD this charter would have been very unlikely to get a fair shake at moving forward so I just would not have sent that email while I was AD. The ADs often can't express their own opinions because and instead have to just try and measure community consensus and go with that even if it does not match what they think is best. Really this is the first chance I've had to express an opinion on this where I was not one of the RAI AD. 

There discussion that has happened since my initial review has made me wish I had said a bit more about SIP-T in my first email. I'm not really proposing that someone should have to implement all of ISUP processing and SIP-T just to pass around the UUI field but from a thought experiment point of view, this does not sound like it is going to provide anything that we would not get if we did implement SIP-T to pass this data. It seems this will have all the limitations of SIP-T combined with the interoperability limitations of UUI in ISDN. I want to be clear, I'm not trying to stop us from doing some work that helps supports uses cases such as the one Laura sent to the list. I just don't see this charter as leading to any improvement in interoperability. If we agree that in theory we could more or less do this with SIP-T thought that is not a practical path from an implementation point of view, then I can see a path of some middle ground. If we don't agree on that then we probably need to think about what we need to add to the charter regardless of if I agree with or not that high lights the additional part of this problem that makes it so SIP-T can't solve it. 

The other things that has happened in this discussion is that I was assuming that the proponents of this felt that proxies needed to modify the data. From the email that came out it's became clear that not everyone believed that. If there was consensus on changing this such that UUI information is not meant for proxies, then I can start to see ways to rewrite the charter to have it reflect what I think people want to do. If the consensus is proxies need to look at this, I have a hard time seeing how it is not involved in call control.