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

["Henry Sinnreich" <[e-mail]>]

>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.

I could not agree more, except to add the highest value is added by people
who also write code before submitting an I-D written on a word processor.

Mybe most of the issues discussed here could be solved by imposing the good
old IETF rule "we believe in running code".

Writing code first would certainly reduce the avalanche of word processor
output that gave us the problems that Dean mentioned.

Actually, how much value is there in an I-D that is not backed up by running
code? Admittedly there are some framework documents, requirements, etc., but
they are the exception to the rule "we believe in running code".

Thanks, Henry

 

-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]] 
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
>> 

_______________________________________________
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