My two cents: I like the idea of splitting SIP into smaller working groups which have a defined deliverable and finite lifespan. Doing this does not reduce the work of the individual contributors, but provides a different benefit: it demonstrates interest in specific issues and problems (by the attendance and activity of the more-focused working group), and it allows working group chairs to be successful. In a standards organization, 'success' is defined as finishing something. Unfortunately with a never-end set of tasks in front of SIP (and SIPPPING, MMUSIC, AVT, and probably others), there is never a sense of completion. Nothing is 'done'.
I know that we have had difficulty getting chairs for various RAI working groups. By creating working groups that have a narrower charter, clear deliverable, and achievable milestones, we can adopt a more normal structure -- a structure where an individual contributor can reasonably spend 2-3 years chairing a working group rather than taking on the significant task of spinning up to understand all of SIP, SIPPING, MMUSIC, or AVT, and having to resign after 5 (or 9 years) because they are burned out and no longer interested in chairing. -d > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: Monday, June 16, 2008 4:23 PM > To: [email protected] > 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. > > 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. > > 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. > > 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. > > 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? > > I also suspect we need a couple of directorates that are not WGs to > act in an advisory capacity: > > 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 [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
