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: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Dean Willis Sent: Tuesday, March 03, 2009 11:55 AM To: sipping LIST Subject: A call for simplicity: Was I-DAction:draft-ietf-sipping-cc-transfer-12.txt On Mar 3, 2009, at 11:15 AM, internet-drafts@xxxxxxxx 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. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
