Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 27 Feb 2006 14:05:28 -0500

Cullen,

Your questions echo some that have been bouncing around in my head as
well.  With so many drafts, I tend to think it is a dilution of focus,
where the speed of any one document is progressed at the speed of its
share of the groups collective focus.  In other words, the collective
brain is thrashing from one draft to another.  

If the chairs could get the group to agree on the prioritized list of
drafts (or just make that decision), then have a draft of the month
system where the WG focuses on one draft until it is finished.  The
author should be prepared to update it every workday if needed to keep
pace.  At the end of the month, it goes to last call.  If the author is
not prepared, go to end of the queue, or have another author take over.

Mike

> -----Original Message-----
> From: Cullen Jennings (fluffy) 
> Sent: Monday, February 27, 2006 1:18 AM
> To: [email-masked]; sipping
> Cc: Jon Peterson; Allison Mankin
> Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of 
> DividingandConquering
> 
> 
> 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" <[email-masked]> 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:[email-masked]]
> >> 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
> >> 
> >> 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 
> >>>> [email-masked] for questions on 
> current sip Use 
> >>>> [email-masked] 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 
> >>> [email-masked] for questions on current sip Use 
> >>> [email-masked] 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 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] 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 
> [email-masked] for questions on current sip 
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Feb 2006 16:41:41 -0500

I like this idea. I think it probably need fine tuning regarding the 
number of drafts that can be worked in parallel this way, exactly what 
the timers are (frequency of updates, how long allowed to converge, 
etc.) but the general concept of scheduling things like this sounds good 
to me.

Given people's availability, it might need more than a queue - rather a 
schedule with a queue governing who is allowed to bid for a slot in the 
schedule.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Feb 2006 19:32:17 -0600

> not prepared, go to end of the queue, or have another author take  

We tried this once upon a time, and it just doesn't work with the  
ITEF editing model.

Other groups, like OMA, make it work by having a professional editing  
staff (or in some cases a volunteer editor who is dedicated) that  
maintains the master copy of each draft, and other people submit  
change requests against it. When a change request is "agreed", the  
editor incorporates it into the draft. During a week long meeting, an  
OMA working group like POC (yes, they meet for 40 hours or so in one  
week) may review 300 change requests and agree 50 or so.

IETF editors tend to be not dedicated full-time to their role.  
They're bursty. Stuff happens in unpredictable episodes, and it  
becomes very hard to predict what is happening when and where.

For example:

Despite my attempts to figure out what new -00 drafts needed to be  
approved, I still ended up having to send in late approvals for three  
new SIP drafts. Sure, I could have said no, but that would have  
pushed us even further off the chartered work plan.

Unless we really want to change the way we work and go to "drafting  
sessions" and "weekly conference calls", we just have to accept that  
things are bursty and try to engage simultaneously on several fronts.

Historically, IETF has tried to have working groups that last a year  
or two and produce three or four documents. SIP, by itself, has  
lasted almost 7 years so far  (not counting when we were part of  
MMUSIC) and has generated thousands of documents and 40 RFCs. And we  
have another 20 or so RFCs in the pipeline. Now, while I won't say  
that returning to the traditional IETF "smaller, bounded WG" model is  
the only alternative we have, it really is the only model that the  
IETF currently knows how to work with.

--
Dean