Re: [Sip] Toward the Evolution of SIP and Related Working Groups

["Dan Wing" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Dean Willis
> Sent: Monday, June 16, 2008 4:23 PM
> To: [e-mail]
> 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip