Subject: [Sip] Thoughts on the Principle of Dividing and Conquering

From: Dean Willis <[email-masked]>
Date: Thu, 23 Feb 2006 18:30:44 -0600

I've been working on SIP and SIPPING and P2P-SIP agendas this week,  
and that started me thinking.

We spun up SIPPING to take some of the load off of SIP, and in doing  
so tried to more narrowly-define the charters of both SIP and SIPPING  
relative to the previous SIP charter.

When we started talking about P2P-SIP, we thought about bringing in  
the topic as part of SIPPING, but fairly quickly rejected that idea  
because it was clearly partitionable.

This started me thinking -- could we further apply this principle of  
partitioning?

Both SIP and SIPPING have grown into multi-year monsters, each with  
large charters and the need for multiple long-sessions at each IETF.  
They're tricky to chair, require lots of secretarial work, and are  
chronically late on deliverables (in large part because the chairs  
are acting like ADs instead of chairs). SPPING, once viewed as the  
kidney of SIP, now needs its own dialysis.

Perhaps if we were to split these two working groups into three or  
four working groups that have much more clearly defined missions and  
scopes, we could cut them down to one meeting slot each. And if we  
were to have separate management (chairs and secretaries) for each  
working group, we could better manage the groups to timely delivery.

So I'd like to toss out some ideas on how we might subdivide, and see  
how you folks feel about this. I think the key to any success here  
would be in scope management.

What if we had the following groups:

1) SIPEM  -- SIP Extended Maintenance

2) SIPNEW -- New major functionality for SIP

3) SIPREQ -- Analysis of requirements raised by new applications or  
SDO liaison

4) SIPUSE -- Using SIP to meet specific application requirements

Here's how we might divide the work:

SIPEM
-----

Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of  
backward-compatible extensions driven by applications with near-term  
deployment scenarios.

Initial Milestone Tasks of SIPEM:

1)  Developing a SIP Guidebook, roughly the equivalent of the TCP  
Roadmap, that defines what's "in" SIP and how the pieces fit together.

2)  GRUU

3)  Outbound

4)  Target-Dialog

5)  Certificate Usage

6)  Location Transport

7)  Loop Error Correction

8)  Connected Party Identity

9)  Hop Limit Diagnostics

10) TLS Usage

11) Answering Modes

12) Connection Reuse

13) Rejection of Anonymous Requests

14) Consent Mechanism

SIPNEW
------

Scope: Enhancement and evolution of SIP including architectural-level  
requirements and (as per RFC 3427) extensions without requirements  
for backward compatibility.

Initial milestone tasks of SIPNEW

1)  Developing a "future roadmap" for the evolution of SIP

2)  Solving the RFC 3261 Routing Problem

3)  Use of SAML with SIP

4)  Response Identity

5)  Response Authentication

6)  End to Middle Requests

SIPREQ
------

Scope: Analysis of requirements raised by new applications of SIP in  
IETF or in external SDOs (as per RFC 3427). Development of  
requirements for changes to SIP or for usage guides in response to  
applications requirements. Another way of wording this would be  
"problem definition".

Initial milestones and tasks of SIPREQ:

1)  Session Policy Requirements

SIPUSE
------

Scope: Guidance on how to use existing SIP specifications and  
mechanisms including examples, call flows, test cases, error  
avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages.

Initial milestones and tasks for SIPUSE:

1)  Service Examples

2)  Security Examples

3)  Race Condition Examples

4)  Session media policy mechanism

5)  Session policy package mechanism

6)  Service quality reporting mechanism

7)  URI List mechanism

8)  Subscriptions to Ad-Hoc Resource Lists mechanism

9)  Multiple REFER mechanism

10) Ad-Hoc Conferencing using URI lists mechanism

11) Call Control Transfer mechanism

12) Configuration Delivery mechanism

13) Emergency Calling using SIP (SOS) mechanism

Note that I'm not entirely happy with the division of SIPPING into  
SIPUSE and SIPREQ. While it seems like we spend a lot of time in  
SIPPING debating requirements, there are currently a lot of  
deliverables in this category.

--
Dean

_______________________________________________
Sip mailing list  https://www1.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: "James M. Polk" <[email-masked]>
Date: Thu, 23 Feb 2006 18:47:21 -0600

I don't mean to rain on this idea, but...

What happens when these 4 grow too big for their britches, split them again?

Shouldn't XCON and SIMPLE be considered when breaking SIP and SIPPING up, 
as these WGs were effectively split off of SIP earlier on?

At 06:30 PM 2/23/2006 -0600, Dean Willis wrote:
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for new developments of core SIP

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 23 Feb 2006 20:37:23 -0600

For as long as the "core" group of folks have to participate in all
these topics, splitting solves nothing. If anything, it causes
coordination issues.

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, February 23, 2006 7:47 PM
> To: Dean Willis; [email-masked] List; Sipping List
> Cc: Cullen Jennings; Jon Peterson; Allison Mankin
> Subject: Re: [Sipping] Thoughts on the Principle of Dividing and
> Conquering
> 
>

---

From: <[email-masked]>
Date: Fri, 24 Feb 2006 12:37:01 +0200

Dean,

(It seems we are creating the SIP Engineering Task Force (SPTF)... We already know that the S in SIP certainly does not stand for "Simple", but perhaps we should consider replacing "Session" with "Standards": "SIP is a mechnism that allows people to initiate and manage Working Groups and oher Standardization efforts mainly in the IETF, but also in other organizations such as but not limited to OMA, 3GPP, 3GPP2, ETSI, ATIS and MSF" :-) 

Seriously speaking, I support your idea in general. Here are some more specific points:
- The most important improvent from my point of view would be the separation of "major new work" from "small extensions and maintenance". Currently, getting small, sometimes niche, extensions through the process seems to be taking too long, and that is creating some frustration. ("Implementing this takes two days, but getting this standardized in the IETF will take 2 years".) Of course, it is still important to review that the new things won't break the existing ones etc.
- Having more time in the meetings is always good, although it seems we already have at the IETF something related to SIP at every slot... 
- With a lot of people having worked with SIP in the IETF for many years (forewver?), there should be many quite capable WG chairs available.
- With the RAI area established, we have the higher level structure already in place for this type of move.

Markus

> From: ext Dean Willis [mailto:[email-masked]]
> Sent: 24 February, 2006 02:31
> To: [email-masked] List; Sipping List
> Subject: [Sip] Thoughts on the Principle of Dividing and Conquering
> 
>

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 24 Feb 2006 11:59:52 +0100

I support this idea. It will certainly reduce the load on chairs, but 
does it really reduce the load on the rest of us? I guess not :) So I 
only support this division because it allows focus and helps the 
community to better understand the progress of SIP.

BTW, how about a 5th one: SIP-P, SIP for P-headers ;)

Hisham

On Feb 24, 2006, at 1:30 AM, Dean Willis wrote:

> chronically late on deliverables (in large part because the chairs are 
> acting like ADs instead of chairs). SPPING, once viewed as the kidney 
> of SIP, now needs its own dialysis.
>
> requirements and (as per RFC 3427) extensions without requirements for 
> backward compatibility.
>
>

---

From: Avshalom Houri <[email-masked]>
Date: Fri, 24 Feb 2006 14:52:55 +0200

I do think that a step in this direction is very necessary.
We will have to finalize the details as:

* How this relates to SPEERMINT and to P2P-SIP?

* A lot of very SIP related work is done MIDCOM, MMUSIC, IPTEL, ENUM, 
XCON, BEHAVE and
probably more groups. How the SIP related work will fit into the new 
framework?

* The SIP work in the IETF has become so big and very connected with other 
standard organizations
that we really need to think about all the issues and there may be a need 
to a deeper change as
creating a sub organization in the IETF for SIP that will meet in other 
dates (maybe collocated with other
organization meetings from time to time as 3GPP and OMA. This way we may 
have much more time to deal
with the necessary issues.

Maybe we should have a BOF at the Dallas IETF for this? Although I am not 
sure we will have
a big enough room or it will be easy to chair such a meeting. :)

--Avshalom

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Feb 2006 09:19:00 -0500

I don't see how any reorg like this will speed work, because I don't 
think the organization has much bearing on the speed of the work. That 
is mostly determined by when people write drafts, and whether they get 
sufficient attention units from others. Unfortunately, the creation of 
drafts seems to a large extent to be linked to the IETF meeting 
schedule. If we could find another way to motivate the submission of 
drafts that was as compelling as the meeting cutoff dates, but less 
bursty, then I think that could help a lot.

Personally I find the division of work among WGs to be an irrelevant 
detail. It is simply a way to break up the work among meeting sessions. 
Whether there are four WGs with two sessions each, or one WG with eight 
sessions makes little difference to me.

Breaking up into too many WGs could have a few negative consequences:
- could result in inefficient use of meeting time. Meeting sessions
   are of a few fixed lengths. There is always going to be a bit of
   fragmentation waste when fitting agendas to meeting slots. The more
   WGs you split the work across the worse this becomes.
- it will become harder to decide which WG to post questions to and
   submit new work to. We already have trouble with people cross posting
   or posting to the wrong list.

I do understand that the load on the WG chairs is a problem. If more WGs 
helps that, then maybe it is worthwhile in spite of the above drawbacks. 
But perhaps there are other approaches to addressing that. E.g.:
- more chairs per WG
- division of responsibility for topics and drafts among chairs
- division of responsibility for particular WG sessions at a
   meeting among the chairs

I do think that new WGs would help if the charters can be structured 
such that they draw different communities of participants. I don't see 
the proposed division achieving that. I think I will still see the same 
people in the meetings regardless of what WG name is on the door of the 
session.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Fri, 24 Feb 2006 16:42:10 +0200

Agree with Paul. A reorg will likely not increase the throughput, since
the increased overhead will cause more context-switch for the same set
of people, and like Paul mentions, just create general confusion of "I
need X; wonder which of the ~7 sippishy WGs is now the correct place to
go ask for that?"

If chair bandwidth is the problem, may I suggest hiring more chairs to
existing WGs, or replacing the existing ones, who've been doing an
excellent job for so many years now, that they really start to deserve a
break.

Of course, both ways will suffer from the same problem of "promoting"
more good engineers to managers. IMHO, we need more engineers, not more
managers.

Cheers,
Aki

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 24 Feb 2006 08:45:42 -0600

Dean Willis wrote:
> I've been working on SIP and SIPPING and P2P-SIP agendas this week,  and 
> that started me thinking.
[...]

Others have commented about the pros and cons of this approach, so
I won't go into that.  Instead, I have a different proposal.  How
about doing something like what the RTG area and the SEC area have done,
namely, establishing a directorate and in this directorate, put in
the core people who would be responsible for vetting I-Ds on various
aspects of SIP.  We are doing this to a great degree anyway, right
now.  Every I-D gets scrutiny by a core group of people who provide
helpful comments.  Why not make this arrangement more formal and
have someone from the directorate work with a I-D authors to get it
to completion in a short time?

Informally, we can divide the directorate into folks responsible
for SIPEM, SIPNEW, SIPREQ, and SIPUSE.  Each sub-area in the
directorate will ensure that the I-Ds assigned to the core group
of people there get finished on time.

And, just for fun, if we do end up breaking into baby SIPs, how

> 1) SIPEM  -- SIP Extended Maintenance

SPEM?

> 2) SIPNEW -- New major functionality for SIP

SINEW?

> 3) SIPREQ -- Analysis of requirements raised by new applications or SDO 
> liaison

SHREK (yea, it's a stretch).

> 4) SIPUSE -- Using SIP to meet specific application requirements

SPOUSE?

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
Sip mailing list  https://www1.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: Michael Thomas <[email-masked]>
Date: Fri, 24 Feb 2006 07:32:50 -0800

Paul Kyzivat wrote:
> think the organization has much bearing on the speed of the work []

My suspicion is that Paul is right. My visualization of SIP these
days seems much more akin to a voracious black hole sucking in all
available matter rather than a smart cocktail tippled through a
dainty straw.

Maybe the base problem is that the energy barrier to new work is
generally too low? And that fairly open-ended charters inevitably
lead to far too many good ideas? Perhaps instead of dividing
along the lines that Dean was suggesting, we should
require them to actually *charter* a fixed-function working
group that actually has a set of goals and ::drum roll:: a
criteria to shut itself down. Including new WG chairs.

Dean also pointed at "evolution". What does that mean? Is speciation
a good or bad thing? What Dean proposes seems more top-down: kind of
like -- dare I say -- eugenics. The one thing I would observe is
that speciation is a fact whether the IETF likes it or not --
if people find utility in a base good mutation, they will live
with the accreted bad mutations that happened gratuitiously. So
the real question in my mind is not whether we can stop speciation,
so much as whether we can manage the gene pool and try to keep
out the deleterious mutations. And for that, it seems that placing
each new problem more in a box might help since it becomes easier
to say no when somebody proposes to sprout a limb from a forehead,
and suchlike. On the other hand, a "problem" wg structure would
seemingly just donate its dna at the beginning (ie its Y chromosome).
Where would the check in development happen? In "new"? Which
essentially becomes one giant species non-specific womb? Hmm.

Anyway, enough of this :)

		Mike

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 24 Feb 2006 10:46:41 -0500

On Fri, 2006-02-24 at 11:59 +0100, Hisham Khartabil wrote:
> does it really reduce the load on the rest of us? I guess not :)

This approach (whether we call it more WGs or a directorate or whatever)
brings in more people to do WG Chair work.  If WG Chairs are the current
bottleneck, it will help.

Will it reduce the load on the rest of us?  If we all attend all the
various SIP WGs, it will not.  But I think that SIP is approaching the
point where individuals do not attempt to track everything that is going
on in SIP.  I know that I don't; there are even areas that are crucial
to my employer that I don't track because my employer has someone else
who tracks that.  If we can sensibly partition SIP into areas of
interest, I think that you will find that many people will be interested
in only a few areas.  Right now, all those people have to attend all the
sessions; if the sessions are partitioned by area of interest, they no
longer have to.

Dale

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Feb 2006 11:59:07 -0600

> What happens when these 4 grow too big for their britches, split  

Quite possibly. Although the intent here is to narrow the scope of  
each so that it is easier for the participants and chairs to  
understand how to make scope decisions.

> Shouldn't XCON and SIMPLE be considered when breaking SIP and  
> SIPPING up, as these WGs were effectively split off of SIP earlier on?

They are. They're discrete chunks we've forked of in the past. We  
will fork off more in the future, as we are proposing to do with P2P- 
SIP (which will have a BOF at Dallas).

Forking appears to be a fundamental design aspect of SIP.

Seriously, we don't have all protocols that use TCP developed in the  
TCP Maintenance working group. Why should we do that to SIP?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Feb 2006 12:01:21 -0600

> these topics, splitting solves nothing. If anything, it causes

Actually, nobody said this would make it easier for the attendees,  
although I am hoping that it will help with scope management. The  
real intent is to make it easier for chairs and ADs. Chairing 12  
hours of SIP meetings chopped up into 10-20 minute slots is a real  
PITA, and I'm not talking flatbread here.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Feb 2006 12:08:33 -0600

> criteria to shut itself down. Including new WG chairs.

That was one of the ideas going into this.

The idea was for SIPM to extend to our current definition of "what is  
SIP" and take over maintenance of that concept. I personally favor a  
version number increment for any core changes past that threshold.

Significant new usages of SIP should fork out new working groups,  
which we have done with SIMPLE and XCON and ECRIT and now P2P-SIP.  
These should have very limited charters and come equipped with  
"lights at the end of the tunnel" -- that is -- the end should be in  
sight, and we should know when we get there.

Feel free to suggest alternative divisions of the work that moves us  
more directly to this goal.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 24 Feb 2006 11:20:15 -0500

Without speaking to the specific division of labor (I think just about 
any division would do), something clearly has to be done to increase 
overall throughput. According to my rough count, in 2005 we managed to 
publish 5 SIPPING and 5 SIP RFC (and 1 SIMPLE RFC). 2004 saw a few more, 
but the total was also not more than 20. However, we added 26 SIP, 52 
SIPPING and 15 SIMPLE -00 drafts, both draft-personal and draft-ietf. 
Some of these, I'm sure, were added initially as draft-personal and 
become draft-ietf, but I don't think that changes the picture all that 
much. Not counting the backlog, we thus accumulated between 4.5 (at 20 
RFCs/year) and 9 years of work (at 10 RFCs) last year.

Currently, we seem to operate like the American Airlines check-in at 
JFK: regular customers wait 3 hours if they stand in line, but 
passengers with a flight about to depart (or an SDO about to get really 
mad) get into another queue and just barely make the flight, if they 
skip the line on the security checkpoint (IESG review). Unless we plan 
to prioritize work by the patience of the authors, this is not a good 
way to run an airline or the IETF.

Henning

Dean Willis wrote:
> We spun up SIPPING to take some of the load off of SIP, and in doing so 
> tried to more narrowly-define the charters of both SIP and SIPPING 
> When we started talking about P2P-SIP, we thought about bringing in the 
> topic as part of SIPPING, but fairly quickly rejected that idea because 
> it was clearly partitionable.
> 
> acting like ADs instead of chairs). SPPING, once viewed as the kidney of 
> SIP, now needs its own dialysis.
> 
> Perhaps if we were to split these two working groups into three or four 
> working groups that have much more clearly defined missions and scopes, 
> we could cut them down to one meeting slot each. And if we were to have 
> separate management (chairs and secretaries) for each working group, we 
> could better manage the groups to timely delivery.
> 
> how you folks feel about this. I think the key to any success here would 
> be in scope management.
> 
> IETF or in external SDOs (as per RFC 3427). Development of requirements 
> for changes to SIP or for usage guides in response to applications 
> requirements. Another way of wording this would be "problem definition".
> 
> Scope: Guidance on how to use existing SIP specifications and mechanisms 
> including examples, call flows, test cases, error avoidance, and so on. 
> Review (as per RFC 3427) of SIP Event Packages.
> 
> 
> SIPUSE and SIPREQ. While it seems like we spend a lot of time in SIPPING 
> debating requirements, there are currently a lot of deliverables in this 
> category.
> 
> 
> -- 
> Dean
>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Feb 2006 15:18:49 -0500

> What happens when these 4 grow too big for their britches, split them 

Sure then form our own standards body ..

SETF SIP Engineering Task Force :-)

Have a real SIP Architecture Board...wouldn't that be novel!!

Mandatory meetings 3 times a year in the Bahamas.

> 
> Shouldn't XCON and SIMPLE be considered when breaking SIP and SIPPING 
> up, as these WGs were effectively split off of SIP earlier on?
> 

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 26 Feb 2006 16:06:01 -0800

Hi,

I don't think further splitting is going to solve our problems due to 
the complexity of lateral communication required among groups with this 
much in common.

I do think that a working group that describes use cases for the RAI 
area in general could produce some very useful output that has been out 
of scope of individual working groups.  The SIP NAT scenarios document 
would be a good candidate to move into such a WG.

I think mostly we have a problem saying no.  We have too much work to 
do and the only effective way for this community to get better 
throughput is to focus religiously on a much smaller handful of work 
items (ex: 4 or 5) at a time.  I am as guilty as the next person for 
adding new milestones (actually, more guilty as a chair), but it is 
hard to say no to new work when old work that is "almost done" takes so 
long to finish.

Perhaps we can have a discussion of this in the RAI area open meeting 
at Dallas.  It would be nice to hear the new ADs jump in here with 
their thoughts.  Also, Allison has been wrangling this monster longer 
than anyone except Dean, so I am curious what she has to say.

thanks,
-rohan

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Feb 2006 20:14:48 -0600

Hey

While I was the first to comment on Dean's proposal not involving enough 
groups, and the potential for deviding again, I can see the flip side of 
this problem being if SIP does exactly what you suggest here: limited work 
to 4 or 5 items.

The consequences of that action (or inaction) would be to have *more* SDOs 
defining extensions to SIP than is already going on.  Many people have 
valid new ideas that are shut/stalled out because it takes so long to get 
any document done under the best of circumstances.

Venture into this scenario:

Rohan writes a new ID that has zero resistance

Does it become a WG item in the first meeting?

yeah - in SIPPING

         that's 6 months of time with zero resistance

In the next meeting it may be moved to SIP for "protocol" work to be done

         3 more months, with zero resistance

How long does it take the WG to review the ID?

No one can tell me reaslistically this happens overnight because everyone 
has queued the right amount of time to this effort.

         so it sits 3 more months

Is this sip-00 version ready for WGLC?

maybe, maybe not

Maybe there is one thing that needs to be adjusted

         3 more months until the next meeting

At the next meeting, *maybe* this ID is ready for WGLC

         2 more weeks

if this is PS track

         2 more weeks for IETF LC

it gets to IESG, does it pass the first time?

         If not, that's 2 more weeks

If so, it's 5 months with the RFC-Editor

This adds up to roughly 20 months to get one idea through with 
unrealistically minimal resistance to the idea.

I think this WG has more time on its hands to do more work than 4-5 items.

If it takes 4 WGs to have faster milestones on the smaller IDs, I think 
that alone is a great idea.

I look forward to a live discussion on this, if it is brought up.

What I'm thinking is happening is more and more SDOs are getting tired of 
the IETF taking so long to get docs out.  At some point they will consider 
the SIP WG irrelevant and do their own thing.

Do we want that?

If giving some of the tasks to other WG chairs to relieve you two (Dean and 
Rohan) to get more work done, even if the same number of core folks sit in 
each meeting, then I think it is better to get more work done with a series 
of WGs having more milestones to meet because there are more chairs 
cracking the whip on authors to get IDs revved and/or reviewed.

<off rant>

At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote:
>Hi,
>
>I don't think further splitting is going to solve our problems due to the 
>complexity of lateral communication required among groups with this much 
>in common.
>
>I do think that a working group that describes use cases for the RAI area 
>in general could produce some very useful output that has been out of 
>scope of individual working groups.  The SIP NAT scenarios document would 
>be a good candidate to move into such a WG.
>
>I think mostly we have a problem saying no.  We have too much work to do 
>and the only effective way for this community to get better throughput is 
>to focus religiously on a much smaller handful of work items (ex: 4 or 5) 
>at a time.  I am as guilty as the next person for adding new milestones 
>(actually, more guilty as a chair), but it is hard to say no to new work 
>when old work that is "almost done" takes so long to finish.
>
>Perhaps we can have a discussion of this in the RAI area open meeting at 
>Dallas.  It would be nice to hear the new ADs jump in here with their 
>thoughts.  Also, Allison has been wrangling this monster longer than 
>anyone except Dean, so I am curious what she has to say.
>
>thanks,
>-rohan
>
>
>>Both SIP and SIPPING have grown into multi-year monsters, each with large 
>>charters and the need for multiple long-sessions at each IETF. They're 
>>tricky to chair, require lots of secretarial work, and are chronically 
>>late on deliverables (in large part because the chairs are acting like 
>>ADs instead of chairs). SPPING, once viewed as the kidney of SIP, now 
>>needs its own dialysis.
>>
>>So I'd like to toss out some ideas on how we might subdivide, and see how 
>>you folks feel about this. I think the key to any success here would be 
>>in scope management.
>>
>>Scope: Analysis of requirements raised by new applications of SIP in IETF 
>>or in external SDOs (as per RFC 3427). Development of requirements for 
>>changes to SIP or for usage guides in response to applications 
>>Note that I'm not entirely happy with the division of SIPPING into SIPUSE 
>>and SIPREQ. While it seems like we spend a lot of time in SIPPING

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Sun, 26 Feb 2006 21:02:55 -0600

Hello,

I do not see where further splitting work into new WGs..etc. solves any
problem.

I believe that "strong" chairing, and a true "democratic" process, where
not only the voices of the few are heard, will result in faster results.

Cheers,

Martin

> Sent: Sunday, February 26, 2006 9:15 PM
> To: Rohan Mahy; Dean Willis
> Cc: Cullen Jennings; [email-masked] List; Sipping List; Jon Peterson;
> Allison Mankin
> Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of
> Dividingand Conquering
> 
> 
> Hey
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Feb 2006 00:09:16 -0600

> I do not see where further splitting work into new WGs..etc. solves  

More chairs, who are better empowered to keep their scopes narrow.  
More forceful chairing and supervision. Less groupthink.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 26 Feb 2006 22:18:01 -0800

I have written replies to this thread several times - then deleted them :-)
It's a hard topic and certainly one that Jon, Allison and I were discussing
before this thread. We have talked about it in relation to this thread. We
will no doubt be talking about it for some time to come. Below are some
questions I have been asking myself. They are really a random stream of
conscious. I don't really want answers to them all but if they trigger some
thoughts on concrete ideas we can that will help. That is great. I am
clearly still in the stage of listening to ideas.

Are the chairs the bottleneck that limits the rate? Are the ADs? How can we
transfer responsibility from the ADs to chairs?

Is the bottleneck to do with the rate that authors update drafts? Is if the
bottleneck to do with the rate that comments are provided on the mailing
lists? Can having a directorate get this done faster?

Can we expand the amount of total work being done or can we only move it
around? Do we need more people writing the same number of documents? Can we
get new people? How much can we move work around from one topic to another?
Will people work on a document they don't care about? why?

I hear lots about what documents should be going faster but what documents
should be slowed down? Are there whole WGs or topics that we should slow
down to zero? There is a large amount of consensus on what document are
critical to get done soon. That's surprising. Why? Can we take advantage of
that somehow?

What's stopping you from getting your drafts done? Is it just time to work
on them? Do you need people to review them? Are they held up on other work?
What's stopping you from reviewing the drafts you think are important and
sending comments? What's stopping you from forcing the the drafts you want
finished to get done?

If you logically split some WG in two (trying to logical group related thing
in each halt), then scheduled them concurrently, would you get twice as much
work done or nothing done because everyone who was not there objected to any
decision made? 

The ADs for the RAI WGs right now are Jon and Allison but I've certainly
been doing a lot of thinking about this. Let me make a few observations:

I would want any change to have some reasonably good chance to make more
than a trivial impact.

Mostly people work on what they want work on -  they vote with their feet.
This is a feature not a bug and much better than the alternative. People
will work on stuff they don't care about but only to a limited degree.

Once things get past WGLC, perhaps Chairs and ADs could be faster but this
would not really accelerate things in a huge way. Still worth working on but
less clear it can make a huge impact.

Having Chairs carefully hound people to work on all the documents that few
people care about might only speed up that work at the expense of stuff that
is critical. I suspect that for the critical stuff, more hounding is good
but there may be a limit.

If we think that the sipping chairs are the bottleneck, well hypothetically,
we could add another 5 people to the chair list. It's an interesting thought
experiment to compare this to adding more groups. I can see several problems
with this. Many of the same problems happen by having more working groups.

Working groups could have an impact far greater than just more chairs. They
allow us to partition time to certain classes of problems - effectively one
class per working group - this might help or might not.  It might result in
a tool to speed up some classes of problems while slowing down others. I
think it is reasonably clear that XCON and SIMPLE forking from SIPPING was a
good thing. Selecting the right level of decomposition is always a balancing
act. 

If you look at the other IETF directorates, they focus on a particular
problem (such as XML, or MIB doctor) and thus can have a handful or two of
people. What would we want a directorate here to do? Are we thinking of it
as people that could take on an particular draft and help it accelerate it
getting done? Would a directorate help this? I believe it might. Jon and I
have been talking about this. Could we achieve the same thing some other
ways? Would a directorate turn into a group that occasionally went for a
nice dinner but did not do much else? I sort of like the directorate idea
but I have just not figured out how to get one or more directorates focused
enough to help. 

I have toyed with the idea of asking everyone to periodically focus some
fraction of their energy on one key draft for a short period of time and try
and get it done. By scheduling these out in time a bit, we might be able to
deal with the complain of people not being able to schedule time for when
drafts they care about need work. Would this work or be useless? Would it
turn out being more or less the same thing as WGLC? Should we try and track
the expected schedule for WGLCs across RAI?

We have some problems where the solution must intrinsically be entangled
across several RAI WGs. Would spending meeting time in a cross RAI meeting
help with these? 

The energy barrier of new work is low. The energy barrier of finishing even
simple work is very high.

Some of the biggest things I can think of are already underway. The protos
makes it so that chairs can do much of what only ADs could do previously.
This is good. The formation of RAI allows the ADs to focus more.

Anyways, don't read too much into anything I said here other than I'm glad
to hear about ideas. In the end, the bulk of the work is done by volunteers
that read drafts, provide ideas and comments, and write the drafts - it the
people that count. 

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 27 Feb 2006 11:41:57 -0800

> More forceful chairing and supervision. Less groupthink.

Yep - I agree - I tried to hit some of theses points but I guess they did
not com across.

---

From: Aki Niemi <[email-masked]>
Date: Tue, 28 Feb 2006 09:51:01 +0200

Inline.

ext Rohan Mahy wrote:
> and the only effective way for this community to get better throughput
> is to focus religiously on a much smaller handful of work items (ex: 4
> or 5) at a time.  I am as guilty as the next person for adding new
> milestones (actually, more guilty as a chair), but it is hard to say no
> to new work when old work that is "almost done" takes so long to finish.

I don't think this will help much. These core efforts are concentrated
to a very small number of authors, perhaps as few as 2-3. How would
saying that the rest will need to stop working on their drafts help
speed up the work done by these 2-3 authors?

Granted, the few core authors are doing an excellent job, but I wonder
if there's anything we could do to balance the load. I just can't see
that the work amount can be carried by such few authors in the long run.
Especially since these same people are holding various other positions
in the IETF at the same time.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Feb 2006 08:18:40 -0500

I agree. While I think there definitely are things that we should say NO 
to, I don't think restricting our efforts to 4-5 things is a recipe for 
success. People are out there trying to apply SIP, and they are finding 
things that need standardization. If we say NO, then either we will 
delay the application of SIP, or else we will force those extras to be 
done elsewhere, leading to more severe fragmentation of sip.

	Paul

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 28 Feb 2006 15:51:34 +0200

Just a small optimization suggestion, can we decide to continue this 
discussion either in sip or sipping (sipping probably is more appropriate 
for this).
We do not need to get a multiple copy of the message so near to the next 
IETF when the IETF mailing lists are full anyway (people that are in the 
to or
cc list get 3 copies...)

Thanks
--Avshalom

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 28 Feb 2006 10:23:57 -0800 (PST)

Hi Aki,

I certainly agree that a small number of busy authors creates a
huge bottleneck for us.  That said, the review time of the entire working
group (including many of the contributors who also author documents) is
also spread too thin.  If a WG is clearly focused on a small set of
documents, and the WG is prompt and thorough about reviewing those
documents and can even get early implementation experience with a small
number of documents, this causes a huge incentive to the author to
prioritize this work.  If the WG takes a long time to review or come to
consensus, the author/editor won't feel the same sense of urgency.

thanks,
-rohan