RE: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering

["Mary Barnes" <[e-mail]>]

I think this is a reasonable approach. Although, given the amount of
work, you might have to do a different draft every two weeks to get
things progressed or interleave 2 drafts. And, perhaps, to further
expand on this suggestion, each draft should have several people (i.e.,
dedicated reviewers selected from a pool of volunteers) who have
committed (upfront) to providing the necessary feedback. If you can't
get that commitment, then you skip the draft straightaway and move on to
the next.  This certainly would require some housekeeping work by the
chairs to keep things going, but with the volume of work, there needs to
be a way of forcing attention to work to get it progressed.    

I still think the directorate concept is also not unreasonable and that
after x amount of time spinning in the WG, a draft should go to the
directorate (with any known open issues identified).  The directorate
could decide whether they think the draft in it's current form has any
hope - I think one of the problems is that it's hard for the original
authors/editor to see cases where significant rethinking might be
necessary and again, it's hit or miss whether someone else in the WG
takes the time to do this sort of review with the current volume of
work.  I think catching problems and doing this sort of revie earlier in
the cycle might help improve overall quality and speed things up.  

Mary. 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[e-mail]] 
Sent: Monday, February 27, 2006 1:05 PM
To: Cullen Jennings (fluffy); [e-mail]; sipping
Cc: Jon Peterson; Allison Mankin
Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle
ofDividingandConquering


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: [e-mail]; 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" <[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
> 

_______________________________________________
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


_______________________________________________
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