Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

Adam Roach <adam@nostrum.com> Tue, 25 January 2011 15:26 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977B33A67E9 for <sipcore@core3.amsl.com>; Tue, 25 Jan 2011 07:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.65
X-Spam-Level:
X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QNasL5HmxvjS for <sipcore@core3.amsl.com>; Tue, 25 Jan 2011 07:26:53 -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 B92E23A67E7 for <sipcore@ietf.org>; Tue, 25 Jan 2011 07:26:52 -0800 (PST)
Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0PFTe1F071069 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 09:29:41 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4D3EEC64.2080302@nostrum.com>
Date: Tue, 25 Jan 2011 09:29:40 -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: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> <BDBFB6CE314EDF4CB80404CACAEFF5DE07C6C68C@XCH02DFW.rim.net>, <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se>
Content-Type: multipart/alternative; boundary="------------020701060104050205080704"
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2011 15:26:54 -0000

[as an individual]

On 1/22/11 03:32, Jan 22, Christer Holmberg wrote:
> I am sure there are things in the draft than can be clarified, including the 3GPP use-cases, but I think it would be useful to know (for me personally, and for 3GPP that wants to use the mechanism) whether the WG is willing to start this work. Nobody has objected to the work as such (you even say yourself that it might be useful :), and all questions and issues that have been raised will of course have to be solved (like we always do).

I don't think it's completely accurate to say that no objections have 
been registered. Cullen's message on November 9th was a pretty clear 
objection. Others -- like Dale -- have expressed confusion about how 
this mechanism is supposed to be used (and whether we're really talking 
about proxies, B2BUAs, or something else entirely that lives outside of 
the valid behavior defined by SIP). Many of the other responses have 
been somewhat pro-forma "3GPP wants this, so let's do it" messages 
without any other content. I'm not discounting them as meaningless, but 
they don't get us any closer to understanding what you're trying to do 
or addressing the concerns that have been expressed.

So, I think we need to back up and get everyone on the same page. The 
use cases you've added to the document are a good start, but I note that 
the section headings all start with the same word.

I would suggest -- and I'm doing this as an individual, not as a chair 
-- that you produce a "draft-holmberg-sipcore-proxy-feature-reqs" 
document that:

   1. contains a concise description of the problem being solved;
   2. contains one or more general (non-IMS, applicable to the Internet)
      use cases;
   3. contains a list of requirements on the solution; and
   4. [this is the most important part] contains no protocol mechanism
      discussion at all.


I think RFC5947 is a good example of how such a document can look.

/a