Re: [Sip] Toward the Evolution of SIP and Related Working Groups
"Mary Barnes" <mary.barnes@nortel.com> Tue, 17 June 2008 19:23 UTC
Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983733A6A53; Tue, 17 Jun 2008 12:23:54 -0700 (PDT)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4153A6A53 for <sip@core3.amsl.com>; Tue, 17 Jun 2008 12:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.506
X-Spam-Level:
X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 UTJXoHXeDoMl for <sip@core3.amsl.com>; Tue, 17 Jun 2008 12:23:48 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 88EA93A6A04 for <sip@ietf.org>; Tue, 17 Jun 2008 12:23:48 -0700 (PDT)
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5HJOUo17787; Tue, 17 Jun 2008 19:24:30 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 17 Jun 2008 14:21:55 -0500
Message-ID: <F66D7286825402429571678A16C2F5EE03F96640@zrc2hxm1.corp.nortel.com>
In-Reply-To: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Toward the Evolution of SIP and Related Working Groups
Thread-Index: AcjQCAuia74LIcnHT7ahxL9B/hx+ZAAoydQQ
References: <6E550023-CD1D-4941-94EA-37B034A9C30D@softarmor.com>
From: Mary Barnes <mary.barnes@nortel.com>
To: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
I have a few comments below [MB]. And one more mega comment/proposal here. Mobile IP is an area that has a similar history as SIP in terms of the demand and explosion of work. They considered our SIP/SIPPING model (at that time we had few other spinoffs, as I recall) when they split their WGs. They have a group for IPv6 work(mext), one for IPv4(mipv4) and one for performance, signaling and optimizations(mipshop). So, from you list of numbers, I could also see a 3 WG split for SIP/SIPPING (discounting all the current spinoffs) using your #s (and assuming SIP WG is done): A) #2+#3: SIP core protocol and extensions to fold into next protocol version B) #4: Policies and security related aspects of SIP Protocol and then put the burden of screening new work such as SPIT, identity, etc. in this group until it's decided that the workload demands a separate WG. C) #5: Basically, SIPPING slightly reduced from current charter - filtering (including OPS related items), howtos, discussing p-headers, etc. - the primary difference here is that this group would not screen basic SIP extension proposals or any of the policy/security, etc. related work. Right now we don't do the security, but some of the other stuff has been debatable. In my mind, the primary thing this would accomplish would be separating out the policy and security work to ensure there's the right focus and attention. I also think this makes scheduling only slightly easier in that it might be easier to ensure security folks could attend. However, I don't think this really helps that much with overall workload - it's just moving some things around. For example, if A above does all the SIP extension screening, that workload may make A be just as crazy as SIP is now OR if in the end the security stuff is causing the craziness, then group B becomes the crazy one, until it sheds more work to new WGs and of course C stays fairly sane, which is what I think it is now ;) In general, I agree that SIP should follow the model that SIPPING did a couple years ago and NOT accept new work items until currently chartered items are done (or at least down to a manageable handful (5-6)) rather than the current 17 (use the tools page rather than WG charter to see the delta), so putting the WG on a path to closure is an excellent idea. Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, June 16, 2008 6:23 PM To: sip@ietf.org Subject: [Sip] Toward the Evolution of SIP and Related Working Groups The SIP working group spun off from the MMUSIC working group when we realized that the SIP work was reasonably separable from the other work going on in MMUSIC. The SIP working group first met officially at IETF 46 in November 1999, although we did have an earlier interim meeting. This means that the fall 1999 meeting will be our 10th anniversary. In addition to having a big party, I'd also like to plan for this being the last meeting of the SIP working group as it is now defined. Ten years is long enough. It's time we restructured. There will probably still be people who want to change, revise, extend, or otherwise manipulate the family of SIP specifications after 2009. So what should we do? How should we organize to get those needs met? Rest assured, we'll be having further discussions on this topic in the coming months. But I'd like to start the discussion now. By November 2009, I fully expect SIP to have completed the majority of currently chartered items. Between now and then, we'll probably also take on and complete a bit of new work (although I plan to be very resistant to new work). I also expect that there are a few items on our charter now that we're not going to finish. It may well be that some of those items need a different organizational structure to progress than what we have. Or maybe they don't need doing. Further, I've come to believe that most working groups should be shorter-lived and tightly constrained by their charters to produce a single concise set of deliverables. There's still a need for a longer- lived thing that maintains architectural oversight. I've come to believe that this is the "area", not the working group. Let's start the recap by looking at the current charter of the SIP WG. I've eliminated the WGLC milestones to shorten the list, as each has a following IESG milestone. Note that there's a Feb 2008 milestone for "Revise Charter". You can consider this topic the first installment on that milestone, even though it is a bit late. 1) Jul 2007 Location Conveyance with SIP to IESG (PS) 2) Aug 2007 Connection reuse mechanism to IESG (PS) 3) Sep 2007 Session Policies to IESG as PS 4) Sep 2007 Example security flows to IESG (Informational) 5) Oct 2007 New resource priority namespaces for DISA to IESG (PS) 6) Nov 2007 Requirements for media keying to IESG (Informational) 7 )Dec 2007 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to IESG (PS) 8) Dec 2007 Roadmap for SIP to IESG (Informational) 9) Dec 2007 Using SAML for SIP to IESG (PS) 10) Dec 2007 Extension for use in etags in conditional notification to IESG (PS) 11) Feb 2008 Identify requirements for test matrix to move SIP to Draft Standard 12) Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) 13) Feb 2008 Revise charter 14) Feb 2008 Establishment of secure media sessions using DTLS-SRTP to IESG (PS) 15) Apr 2008 MIME body handling in SIP to IESG (PS) 16) Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG (PS) 17) Jul 2008 Mechanisms for UA initiated privacy to IESG (BCP) 18) Aug 2008 Guidelines for double route recording to IESG (BCP) 19) Sep 2008 X.509 Certificates for TLS use in SIP to IESG (PS) 20) Sep 2008 X.509 extended key usage for SIP to IESG (PS) 21) Nov 2008 Termination of early dialog prior to final response to IESG (PS) Looking at this, we have a couple of discrete tasks that I think might make the basis for different narrowly-scoped working groups. We've also got a lot of stuff that we're late on delivering! 1) SIP WG (to finish by end of 2009) gets the bulk of these items. 2) SIP Draft Standard WG: Takes the milestone of "Identify requirements for test matrix to move SIP to Draft Standard" and all of the follow-on work needed to move SIP from Proposed to Draft on the standards track. There's certainly enough work here for a dedicated working group, with the last milestone being something like "Deliver SIP as a Draft Standards Document to IESG". We may wish to consider whether we really want to go this route or whether we should instead be thinking of a "SIP 3.0" effort. My personal though is that there's just too much cruft in the RFC 3261 family to make Draft, but I could be proven wrong. I'd rather see us put SIP 2.0 into maintenance mode at the end of 2009 and move the bulk of our resources into developing a SIP 3.0 family designed from the ground up to be Draft-Standard achievable. [MB] I like this suggestion. [/MB] 3) RAI Essential Corrections WG: Does this justify its own working group? Remember, it would be not just RFC 3261, but the entire family of related RFCs that would need lock-step maintenance and corrections. Another approach might be to roll the corrections into the Draft Standard version of SIP 2.0. [MB] I think this should be roleed into 2) above. [/MB] 4) RAI Policies WG: We have these ongoing, not-quite-committed work items like session policies, use of SAML, etc. that we've never been able to get fully wrapped up. I suspect they need their own WG. Or we need to decide that these things just aren't worth doing and stop feeling guilty about not finishing. As it is, I don't have a good feeling about SIP finishing them. [MB] I like this idea and would it also not cover any outstanding ongoing security items or are you anticipating that to addressed entirely by the currently chartered work items? [/MB] 5) SIP Operations: I'd like to see SIPPING replaced with a "how to" group possibly under the OPS banner. They could deal with all the "how do we do X with SIP" from other SDOs. When confronted by a need to extend SIP to meet a given need, they could then BOF up a new WG to deal with the required extension. [MB] Are you proposing this to replace SIPPING WG? If so, I don't see it falling under the banner of OPS. I do see that there may potentially be the need to initially discuss OPS related items, but as in the past, I see those being completed in the appropriate OPS WGs (e.g., performance). I have mixed views on how effective it would be to have a BoF and new WG for new extensions. I don't think the model we currently have is that ineffective in terms of first discussing requirements before agreeing a solution. I see a SIP Maintenace group perhaps to handle these items, although in many cases, I think it would be far more effective to roll these things into your item 2 - i.e., don't you see SIP 3.0 as pulling in a lot of the headers that have been defined since RFC 3261 has been published. [/MB] We already have working groups looking at conferencing, peering, telephony feature interop, provisioning, peer-to-peer, NAT traversal, Other things that might need WGs: SPIT? Identity and Reputation? [MB] I would agree these two topics might warrant separate WGs, although some of that work overlaps with your WG 4, I believe, the division of work may not be so clear. [/MB] I also suspect we need a couple of directorates that are not WGs to act in an advisory capacity: [MB] I think we already have these and more covered by our current RAI area review team. These are specialized reviews and assignment of reviewers is based on area of expertise and we've got security and event package gurus already on the team. [/MB] 1) RAI Security Directorate: Focuses on security review and architectural issues in RAI documents. 2) RAI Event Package Directorate: Reviews and approves new SIP event packages _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Toward the Evolution of SIP and Related Wor… Dean Willis
- Re: [Sip] Toward the Evolution of SIP and Related… Mary Barnes
- Re: [Sip] Toward the Evolution of SIP and Related… Jonathan Rosenberg
- Re: [Sip] Toward the Evolution of SIP and Related… Henry Sinnreich
- Re: [Sip] Toward the Evolution of SIP and Related… Dean Willis
- Re: [Sip] Toward the Evolution of SIP and Related… Dale.Worley
- Re: [Sip] Toward the Evolution of SIP and Related… Hadriel Kaplan
- Re: [Sip] Toward the Evolution of SIP and Related… Juha Heinanen
- Re: [Sip] Toward the Evolution of SIP and Related… Hadriel Kaplan
- Re: [Sip] Toward the Evolution of SIP and Related… Henry Sinnreich
- Re: [Sip] Toward the Evolution of SIP and Related… Dan Wing
- Re: [Sip] Toward the Evolution of SIP and Related… Hannes Tschofenig