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

From: Dean Willis <[email-masked]>
Date: Mon, 16 Jun 2008 18:23:18 -0500

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 17 Jun 2008 14:21:55 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Monday, June 16, 2008 6:23 PM
To: [email-masked]
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.

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.

11) Feb 2008 Identify requirements for test matrix to move SIP to Draft
Standard

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!

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]

[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]

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Jun 2008 18:37:14 -0400

I agree with Mary - this seems like its just moving work around.

To reiterate the mantra of SIPPING itself - what PROBLEM are you trying 
to solve Dean? Is it that there is not enough people to do the work? As 
Mary points out, your suggestion only makes it worse. Is it to get more 
meeting slots? Is it to better align IETF work with the needs of the 
actual marketplace?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 17 Jun 2008 21:28:14 -0500

SIP is actually an excellent success story. Not only is SIP the world
standard but there are countless SIP implementations as OS SW.

Maybe we could agree on the following to declare victory and preserve its
success:

1. Any SIP and related work in the IETF is focused on the (stupid = no
intelligence) Internet, as defined in AIB issued RFCs, keeping the e2e
principle in mind.

2. Service provider specific protocols (to support "network based services")
belong in ITU-T or other similar service provider focused organizations,

3. The main deliverable of a WG is free software to validate and support the
protocol document and its refinement. If no free software is contributed,
the WG activity should be suspended. Internet-Drafts not supported by freely
available software (that can be inspected and tried out) and measurements
cannot be proven right or wrong and should therefore be ignored.
There is plenty of IEEE and University work to prove this approach, which
was also the basis for the rise and success of the IETF.

Thanks (and feel free to flame),

Henry

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Jun 2008 00:33:40 -0500

On Jun 17, 2008, at 5:37 PM, Jonathan Rosenberg wrote:

> To reiterate the mantra of SIPPING itself - what PROBLEM are you  
> trying to solve Dean? Is it that there is not enough people to do  
> the work? As Mary points out, your suggestion only makes it worse.  
> Is it to get more meeting slots? Is it to better align IETF work  
> with the needs of the actual marketplace?

The problem that I'm trying to solve is making the task space  
manageable.

The first thing is to distribute the chair load. Everybody says "The  
problem isn't the chairs, it;s the lack of reviewers". Well, everybody  
but the chairs say that, actually. If you look at the current status  
from the beginning of this thread, you'll see that Keith and I are the  
long poles in the SIP tent.  Sometimes stuff waits a year for us to  
finish the proto writeup -- usually because when we get to doing the  
writeup, we find a bajillion errors the reviewers and authors missed.  
I typically see drafts revved at least twice during the writeup cycle,  
and that's a heck of a lot of work on the part of the chairs!

The second problem is "learning to say no". I think WGs should have  
very narrowly defined charters and that it should be very, very  
difficult to add substantial new work to a charter. That is, it should  
be nearly as difficult to add work to a WG as it is to form up a new  
WG, and that often, the correct answer actually is "form a new WG".  
Perhaps even more often, the correct answer is "no".

I think developing a SIP extension should be a Big Thing. If it's  
important enough to develop a SIP extension for, it is probably  
important enough to charter a working group to develop that extension.  
It's a Really Bad Idea to have a standing working group that sits  
around and develops SIP extensions. All that gets us is a whole lot of  
extensions. It doesn't get us any closer to a draft standard.

Working groups shouldn't last ten years. Only in rare circumstances  
should they last two years, and the average should be more like one  
year.

The key result of this sort of reorg is that a WG, and most especially  
the chairs of that WG, can be narrowly focused on a small and  
manageable set of deliverables. We should give them the luxury of  
doing one job and doing it well. Chairs should be able to do a real  
day-to-day job and run a working group on the side. I can tell you,  
SIP doesn't work that way now! Even the lousy job I do requires at  
least 50% of my working time, and that's going to break the bank  
eventually.

--
Dean

---

From: [email-masked]
Date: Wed, 18 Jun 2008 18:26:14 -0400

From: Henry Sinnreich <[email-masked]>

   3. The main deliverable of a WG is free software to validate and support the
   protocol document and its refinement.

A good concept, but I would amend this to "... two interoperable and
idependenly-implemented free softwares [grammar?] ...", as it was in
the Good Old Days.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Jun 2008 14:02:34 -0400

> Henry Sinnreich

Since when is the main deliverable of the IETF free software?

The main deliverable of the IETF is documentation, for the purpose of achieving interoperability, to make the Internet better.  That's it. (i.e., RFC 3935)  Open source implementation is one means to an end goal, not the end goal itself.

And as it is, I think some of the extensions in SIP have *only* been implemented in open source software and never seen the light of day in real world use even of that open source software. (or in any degree one would consider "broad use")  In that sense, maybe we should only continue work in things that have seen commercial implementation! ;)

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 20 Jun 2008 21:50:00 +0300

Hadriel Kaplan writes:

 > The main deliverable of the IETF is documentation, for the purpose of
 > achieving interoperability, to make the Internet better.  

please let me know how all those 3gpp/ims related drafts/rfcs that
sip[ping] wgs have produced help to make Internet better?

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Jun 2008 15:27:13 -0400

If by "3GPP/IMS related drafts/rfcs" you mean the P-headers in 3455, it's the IETF that wanted them to be submitted I thought.  It's only informational.  What drafts were you thinking of?

They use the Internet, or their private networks connect to the Internet, and thus we should want them to tell us what they feel is missing from SIP.  We can use the info to decide if it's generally useful for everyone, or not, or even as an example of what not to do and try to persuade them down a different path.  They potentially represent a significant population of UA's that we should want to be reachable over the Internet in some form, to/from pure IETF-compliant UA's.

-hadriel

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Friday, June 20, 2008 2:50 PM
> To: Hadriel Kaplan
> Cc: Henry Sinnreich; Dean Willis; [email-masked]
> Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups
>
> Hadriel Kaplan writes:
>

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 20 Jun 2008 15:22:10 -0500

> achieving interoperability, to make the Internet better.

Docs without Code
Documentation without available code has led us to use Jabber IM in the
SIMPLE WG meetings. Is this a success story for SIMPLE/SIP?

Serial Writers 
Other harmful effects of writing specs on the editor "platform" is the
deluge of SIP related RFCs and I-Ds since there is no threshold to stop
serial writers. 
* Does anyone expect developers to read and understand the 100's of
documents?
* How can the concepts and definitions in a document without code be proven
in the first place? By discussion and voting?

In Conflict With The Internet Principles
Last but not least, supporting commercial products or business plans is not
the same as supporting the Internet. There may be actually a fundamental
conflict here, for example closed stacks vs. the e2e principle, supporting
Internet transparency, etc.  It is the reason why all work related to the
service provider market, which is important work BTW, should be moved to the
ITU-T IMO.

These topics deserves however a larger discussion, outside of this list.

Enjoy the weekend,

Henry

On 6/20/08 1:02 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> achieving interoperability, to make the Internet better.  That's it. (i.e.,
> RFC 3935)  Open source implementation is one means to an end goal, not the end
> goal itself.
> 
> And as it is, I think some of the extensions in SIP have *only* been
> implemented in open source software and never seen the light of day in real
> world use even of that open source software. (or in any degree one would
> consider "broad use")  In that sense, maybe we should only continue work in
> things that have seen commercial implementation! ;)
> 
> -hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Jun 2008 14:46:27 -0700

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: Monday, June 16, 2008 4:23 PM
> To: [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Jun 2008 10:56:21 +0300

> In a standards organization, 'success' is defined as
> finishing something. 
Maybe the success criteria should not just to produce documents but to 
produce something that actually sees deployment.