Re: Last Call: <draft-ietf-sipcore-199-05.txt> (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard

Adam Roach <adam@nostrum.com> Mon, 07 February 2011 21:01 UTC

Return-Path: <adam@nostrum.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 443AF3A6E70; Mon, 7 Feb 2011 13:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, 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 SxNJcuZ3MyZG; Mon, 7 Feb 2011 13:01:51 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D46BB3A6E55; Mon, 7 Feb 2011 13:01:50 -0800 (PST)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p17L1rkS045381 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 15:01:54 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4D505DC1.40002@nostrum.com>
Date: Mon, 07 Feb 2011 15:01:53 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: Last Call: <draft-ietf-sipcore-199-05.txt> (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard
References: <20110207170250.4107.67897.idtracker@localhost> <3A723B49-1CCB-4E55-8122-FBF58F30D6AF@cisco.com>
In-Reply-To: <3A723B49-1CCB-4E55-8122-FBF58F30D6AF@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: IESG IESG <iesg@ietf.org>, "ietf@ietf.org IETF" <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: Mon, 07 Feb 2011 21:01:52 -0000

On 2/7/11 12:44 PM, Cullen Jennings wrote:
> I was somewhat surprised to see this back in LC. I am still not aware of any use case where this actually helps. I searched the IETF and WG lists for email with the subject draft-ietf-sipcore-199 and I do not see a single email that suggests there is support for this draft or the changes in it since the previous LC.
>
> This draft has no use that I understand how it helps - it is at best a very limited optimization. The SIP standards is already too complicated with too many extensions. I believe this draft makes SIP worse.Thought the draft mandates that systems need to work even when the 199 are lost, I do not think that is how the proponents of the work intent to use. I could be very wrong but I presume that people intent to use to control middle boxes that control media gates. It's broken for that but given that is not discussed in the draft, it's hard to discuss how it is broken and what would be needed to fix it.
>
> I do not support publishing this draft as standards track without actual WG discussion on what the problem is this draft solves and if there is WG consensus that problem is worth solving.

Cullen:

Speaking as a chair of SIPCORE, I would like to clarify a minor point. 
Although it may not have been your intention, your message can be read 
as implying that the SIPCORE chairs and/or the RAI area directors have 
decided to move this document forward without community input.

For the benefit of those on this mailing list who were not involved in 
the earlier stages of this document's progress: the initial community 
input on whether to pursue the problem solved by this draft was taken at 
the face-to-face SIPPING meeting during IETF 69. In particular, the 
minutes for that meeting reflect: "Hum... in support of working on this 
problem."

In April of 2008, the requirements document was handed over from SIPPING 
to the SIP working group for working on actual protocol mechanism. (The 
SIP change process at the time limited core protocol changes to the SIP 
working group, requiring a change in venue).

Within the SIP working group, there were at least 316 message in 38 
different threads on the protocol document over the one year period 
spanning April 2008 to April 2009. This period included a two-week long 
Working Group Last Call period in November of 2008.

In April of 2009, the RAI area underwent a reorganization, which 
resulted in the conclusion of the SIP working group. As part of the 
chartering of the SIPCORE working group, this document (and its 
associated milestone) was transferred to the SIPCORE WG.

In January of 2010, the document entered IETF last call for the first 
time. During IETF balloting, certain issues were identified by the IESG, 
and balloted as a "DISCUSS" position. Over the course of 2010, the 
document's author worked with the RAI ADs to address these issues to the 
satisfaction of the currently seated IESG. As a result of these 
conversations, a technical issue involving interaction with another SIP 
extension mechanism was identified, and brought back to the SIPCORE 
working group. A resolution to the issue was identified in early 
December 2010, and a revised version of the document was produced to 
reflect this resolution.

At every step of this process, the IETF, RAI, and SIP community has 
opportunity for involvement. The volume of discussion demonstrates a 
non-trivial interest in this mechanism.

/a