[Sipping] A call for simplicity: Was I-D Action:draft-ietf-sipping-cc-transfer-12.txt

Dean Willis <dean.willis@softarmor.com> Tue, 03 March 2009 17:54 UTC

Return-Path: <dean.willis@softarmor.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C1E3A6C5D for <sipping@core3.amsl.com>; Tue, 3 Mar 2009 09:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.431
X-Spam-Level:
X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599]
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 R5imydA8foF1 for <sipping@core3.amsl.com>; Tue, 3 Mar 2009 09:54:57 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B0F4B3A6C30 for <sipping@ietf.org>; Tue, 3 Mar 2009 09:54:57 -0800 (PST)
Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n23HtN3v009547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <sipping@ietf.org>; Tue, 3 Mar 2009 11:55:24 -0600
Message-Id: <0B0B13B2-5E65-47CD-8B49-C6527E74E2F0@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: sipping LIST <sipping@ietf.org>
In-Reply-To: <20090303171501.B44383A6919@core3.amsl.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 03 Mar 2009 11:55:18 -0600
References: <20090303171501.B44383A6919@core3.amsl.com>
X-Mailer: Apple Mail (2.930.3)
Subject: [Sipping] A call for simplicity: Was I-D Action:draft-ietf-sipping-cc-transfer-12.txt
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 17:54:58 -0000

On Mar 3, 2009, at 11:15 AM, internet-drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Session Initiation Proposal  
> Investigation Working Group of the IETF.

At the risk of sounding like Henry, I think we have good cause to  
worry when we consider that we are on the 12th rev of our call  
transfer draft, and that the SIPPING working group version was  
preceded by 5 versions in the SIP working group. Even earlier, we had  
the original one individual version published in March, 2000.

What kind of monster have we created that it takes nine years and 18  
versions of a draft to specify call transfer, and we're still not  
done? The kudzu has eaten the crop, and it may be time to just spray  
Roundup on the whole field and replant. Learning to eat kudzu is not a  
viable option.

Seriously, we need to step back, take a deep breath, and think very  
seriously about simplifying the whole SIP framework instead of  
elaborating it further. I don't know that I completely agree with  
JDR's modest proposal about accepting the SIP-as-SBC-mediated- 
telephony-over-IP model as our entire scope, but we have to do  
something.

How about freezing SIP 2.0 in maintenance mode, taking on no further  
work (except for bug fixes), and starting a SIP 3.0 exercise that uses  
things we learned from SIP 2.0, including but not limited to:

1) Isolating the application, transaction, rendezvous/naming, and  
transport layers.

2) Supporting, or better, fundamentally integrating strong end-to-end  
identity.

3) Recognizing and formalizing the roles of active intermediaries that  
exceed the limitations of SIP 2.0 proxies.

4) Limiting optionality.

5) Including strong compliance specifications that can be tested  
against and certified independently.

I'd also like to put in some text about reusing/sharing connections  
and muxing signaling and media onto an address/port pair, but I'm sure  
that would cause somebody around here to self-destruct. Perhaps this  
could be accomplished by:

6) Assume that NAT, NAPT, and address family (IPv4/IPv6) translators  
are ubiquitous, and based on this assumption optimize the protocol  
design so as to minimize the protocol adaptation mechanics required to  
traverse those translators. In other words, stop referring to  
addresses and ports inside the payload.


Note: From a metrics perspective, it is interesting that the draft has  
been revised just over twice for every three meetings, which may go  
towards disproving the "drafts are revised for each meeting" theory,  
or perhaps restating it as "Drafts are revised, on average, no more  
than once for each meeting cycle."


--
Dean Willis, frustrated SIP gardener.