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

[Dean Willis <dean.willis at softarmor.com>]

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip