[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Toward the Evolution of SIP and Related Working Groups
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Dean Willis
> Sent: Monday, June 16, 2008 4:23 PM
> To: sip at 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.
>
> 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
>
_______________________________________________
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