Subject: [Sipping] I-D Action:draft-ietf-sipping-cc-transfer-12.txt

From: [email-masked]
Date: Tue, 3 Mar 2009 09:15:01 -0800 (PST)

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.

	Title           : Session Initiation Protocol Call Control - Transfer
	Author(s)       : R. Sparks, A. Johnston
	Filename        : draft-ietf-sipping-cc-transfer-12.txt
	Pages           : 56
	Date            : 2009-03-03

This document describes providing Call Transfer capabilities in the
Session Initiation Protocol (SIP).  SIP extensions such as REFER and
Replaces are used to provide a number of transfer services including
blind transfer, consultative transfer, and attended transfer.  This
work is part of the SIP multiparty call control framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dean Willis <[email-masked]>
Date: Tue, 3 Mar 2009 11:55:18 -0600

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

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 3 Mar 2009 12:30:22 -0600

Yeah, this has been a while, BUT there were delays in getting some of
the updates done and confusion (on both sides as I recall) as to who had
the editor's token for a while.  

But, these updates as I understand are based on IESG feedback, so the
doc is out of the WG and has been for over a year - it's no longer being
targetted for meeting (or ML for that matter) discussion.  You can look
at the stats here as far as how long it did sit in the WG (and how long
it's been out of the WG):
http://www.arkko.com/tools/lifecycle/draft-ietf-sipping-cc-transfer-timi
ng.html

And, I think we actually have worse examples and some currently
chartered items are also only getting updated just before meetings, so
yes there is a problem in SIPPING with getting work done efficiently,
but I personally believe the primary issue is limited resources and the
fact that folks just would prefer to work on shiny new things than
rewrite sentences, fix commas, clarify and beef up security sections,
etc. in their documents. 

And, I do think your mega discussion is more appropriate for RAI
restructuring than on SIPPING. I think we have improved the expediency
of processing WG documents over the past few years and one of the
problems in the past was just too many active, chartered WG items at one
time, which I think is one of the main points for the RAI restructuring.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Tuesday, March 03, 2009 11:55 AM
To: sipping LIST
Subject: [Sipping] A call for simplicity: Was
I-DAction:draft-ietf-sipping-cc-transfer-12.txt

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

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

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Tue, 3 Mar 2009 13:37:18 -0600

> time, which I think is one of the main points for the RAI  

Fair enough. I'm not suggesting any particular flaw in SIPPING or SIP  
working groups; rather that the entire SIP specification effort has  
gone awry. This isn't a procedural problem or a question of which  
working group to put given work into.

It's a much deeper question that really goes to "What should RAI be  
working on, given that the thing we've been working on for the last  
ten years is now apparently working us over instead?"

--
Dean