Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering

[Henning Schulzrinne <[e-mail]>]

These are all valuable questions, but the problem is that I don't see  
how you can answer most of these except anecdotally and that the  
cause of delay is, as usual, some combination of all of the issues.  
Looking at the IETF overall, we don't seem to make much headway by  
asking people to do more of the same. The PROTOS experiment indicates  
that having individual responsibility and clear "reporting  
relationships" do seem to help, so maybe we need to do this earlier  
and more.

We can spend the next year debating this issue. Maybe an alternative  
is to do an experiment: Take one of Dean's groups and split it off;  
if, after some evaluation period, the experiment seems successful as  
measured by task completion (which can include dumping drafts), do  
more. If not, the damage is likely minimal - interested authors can  
almost always overcome inertia. Unlike for other new WG creations, we  
don't have a void until the WG gets set up. The drafts would remain  
and make progress, at whatever rate, until the new WG is up and running.

An alternative to topical splits is to have a "short program" split:  
gather all the low-impact, almost-done, short-draft items into a WG  
and appoint a "finisher" as WG chair, i.e., somebody selected for his  
or her ability to get things done, not necessarily to be the most  
brilliant SIP thinker.

Henning


On Feb 27, 2006, at 1:18 AM, Cullen Jennings wrote:

>
> 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
>
>
> On 2/26/06 7:02 PM, "Dolly, Martin C, ALABS" <[e-mail]> wrote:
>
>> 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
>>
>>> -----Original Message-----
>>> From: James M. Polk [mailto:[e-mail]]
>>> Sent: Sunday, February 26, 2006 9:15 PM
>>> To: Rohan Mahy; Dean Willis
>>> Cc: Cullen Jennings; [e-mail] List; Sipping List; Jon Peterson;
>>> Allison Mankin
>>> Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of
>>> Dividingand Conquering
>>>
>>>
>>> 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
>>>>
>>>>
>>>> On Feb 23, 2006, at 16:30, Dean Willis wrote:
>>>>> 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 [e-mail] for questions on current sip
>>>>> Use [e-mail] for new developments on the application of  
>>>>> sip
>>>>
>>>>
>>>> _______________________________________________
>>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/ 
>>>> sipping
>>>> This list is for NEW development of the application of SIP
>>>> Use [e-mail] for questions on current sip
>>>> Use [e-mail] for new developments of core SIP
>>>
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use [e-mail] for questions on current sip
>>> Use [e-mail] for new developments of core SIP
>>>
>
> _______________________________________________
> Sip mailing list  https://www1.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


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP