Re: [RAI] Making RAI work better

[Henning Schulzrinne <[e-mail]>]

Is the number of documents the problem at this point in all groups?  
Examples: SIMPLE has only two early (< 03) documents, SIP only a few  
more. Pressure on WG meeting discussion time in most WGs seems to have  
eased a bit. The problem, in my view, is finishing documents that are  
90%+ done, with essentially no major technical changes in the last few  
meeting cycles. Maybe we need the equivalent of a "closer", i.e.,  
somebody who is assigned by the chairs to work with the (often  
exhausted, having mentally moved on) editors and authors to get the  
document out the door. As noted in my other rant, maybe chairs should  
focus on the high-dependency and high-impact drafts first.

To pick on one RAI WG that traditionally has been very busy: According  
to http://www.ietf.org/proceedings/08jul/slides/sip-3.pdf, for  
example, the SIP WG only has 5 documents that are still in discussion.  
All the rest are in WGLC (7), IESG review (9) and the RFC editor queue  
(7). Thus, reducing the inflow into the WG isn't likely to help much  
at this point, although I'm certainly not advocating that we take on  
new second-order work.

Maybe it would be helpful if there's a state-of-RAI overview (by  
email) every few months, with an update on the statistics, similar to  
the RFC editor statistics presented at the plenary. That way, we'll  
have a better idea where the pipeline is clogged and where Draino is  
needed.

Henning
(who also has a few 90+% drafts that need finishing...)

On Oct 1, 2008, at 4:18 AM, Elwell, John wrote:

> Adam,
>
> I think you make good points. Theoretically the deliverable dates  
> should
> focus our attention on the ones with earlier dates, but that doesn't
> seem to happen. Perhaps we should set dates (i.e., achievable dates)
> only for a small number of items per WG and push very hard to achieve
> those. I would not want to throw out discussions on future topics
> altogether - that is a recipe for stagnation - but due priority has to
> be given to a small number of achievable targets. Others we can keep  
> in
> a pool and assign dates when resources become available, i.e., when we
> have finished some other targets. If technical difficulties arise  
> with a
> particular deliverable, we can of course delay that, and maybe promote
> something else to take its place.
>
> As a participant, how these items are split between groups is of less
> importance, but if Dean considers the chairs to be overloaded (which I
> can believe), then by all means go for a greater number of groups.
>
> The whole end-to-end process needs looking at, not just what happens  
> in
> the WG. To take a recent example, by my records cc-transfer started  
> WGLC
> in August 2005 and has only just gone to IESG last call. I am sure  
> there
> were delays from all parties (WG members, WG chairs, editors and ADs),
> and I am sure some valid technical concerns came up during that time.
> But 3 years!
>
> John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Adam Roach
>> Sent: 01 October 2008 03:32
>> To: Dean Willis
>> Cc: [e-mail]
>> Subject: Re: [RAI] Making RAI work better
>>
>> I think the problem is that we're constantly increasing the number of
>> threads (documents) we're working on, while the number of CPU
>> cores (key
>> participants) remains fairly constant. We're CPU bound.
>> Increasing the
>> number of processes (working groups) so that they can each have fewer
>> threads in them (but still the same number of threads
>> overall) doesn't
>> change the fundamental problem that we're simply out of CPU cycles.
>>
>> Given that we don't know how to increase the number of
>> processor cores,
>> the only thing we can usefully play around with is thread
>> scheduling. Do
>> we throw all the threads on the processor cores at once, so that they
>> all make progress all the time, but take five to ten years each to
>> complete? Or do we strictly limit the number of threads so
>> that each one
>> completes fairly rapidly and gets out of the way for the next one?
>>
>> I think the latter approach would be far more productive. When I move
>> between work items, I know I have to swap information back
>> into my head
>> to just have the context to think about the related problems. For the
>> past few years, most of my IETF work has been characterized by
>> thrashing, in which I spend much more time re-learning the
>> context for a
>> piece of work than I do actually thinking about the problems
>> related to
>> that work. This is 100% because there's too much going on,
>> and it's all
>> too tightly interconnected to focus on small niches.
>>
>> Robert has pointed out that we can never say "no," only say
>> "not now." I
>> agree with this statement; however, I would go one step
>> further to argue
>> that we don't even say "not now" nearly often enough. And
>> we've become
>> highly inefficient for it.
>>
>> /a
>>
>> Dean Willis wrote:
>>>
>>> The main problem we have with RAI is that some of our
>> working groups
>>> have dozens of documents. Both the brainspace of the WG and the
>>> attentions of the management team (aka, Keith and I, for SIP) are
>>> consumed with swapping between documents trying to give "fair"
>>> treatment to all. Hence, the urgent is balanced against the
>> important,
>>> and we end up more and more fragmented.
>>>
>>> We have huge, eternal working groups that don't focus well. Our
>>> meetings can't focus, our mailing lists can't focus, our management
>>> can't focus, and our participants can't focus. We're like
>>> three-year-olds in a three-ring circus, too busy gawking at
>> the other
>>> clowns to get any work done.
>>>
>>> Several years ago, I proposed a reorganization (slides at
>>>
>> http://www.ietf.org/proceedings/06mar/slides/raiarea-3/sld1.htm). The
>>> consensus at the time was simply to have more rigorous chairs. We
>>> added Keith, who is  quite a rigorous chair, and it helped, but not
>>> enough. We've also tried more organized chairs, like Mary, in
>>> SIPPING.  Again, this helped, but not enough.
>>>
>>> I maintain that what is needed is to reduce the size of a
>> chair's job
>>> so that it can be done well in a reasonable 4-6 hours per
>> week, rather
>>> than done badly with a workload more like 30 hours per week. The
>>> easiest way to do this is to divide the problems up across more
>>> chairs. Of course, getting rid of a few problems would help too.
>>>
>>> Towards this end, I recently suggested a reorganization (see
>>> http://www.ietf.org/mail-archive/web/sip/current/msg23692.html).
>>>
>>> This reorg proposed replacing SIP and SIPPING with a couple
>> of smaller
>>> working groups with narrow charters, including (not nec. in
>> this order):
>>>
>>> 1) RAI Maintenance: Essential corrections to existing RFCs. No
>>> semantic or functional changes, just bug fixes.
>>>
>>> 2) SIP Draft Standard: Whatever is needed to move the SIP
>> spec family
>>> to draft standard
>>>
>>> 3) Real-Time Operations: Deals with the questions of how to do "x"
>>> with SIP and related specs
>>>
>>> 4) Real-Time Policies: Session policies, SAML, etc.
>>>
>>> 5) real-Time Identity Expression, for which I proposed a charter:
>>> http://www.ietf.org/mail-archive/web/sip/current/msg23899.html
>>>
>>> There are some other things that SIP is close to finishing
>> and should
>>> just be left there. I suspect the same is true of SIPPING.
>> When done,
>>> we close those nuthouses down.
>>>
>>> Big, complex documents that have a lot of things depending on them
>>> belong in their own dedicated working groups with a dedicated
>>> management team.
>>>
>>> Related sets of documents with tight interdependencies also
>> belong in
>>> their own working groups. For example, the SIP Consent
>> Framework and
>>> the half-dozen drafts detailing how to use contact-lists
>> for various
>>> SIP requests  might have made for a reasonably chartered
>> working group
>>> with a reasonable 2-year lifespan. A working group that
>> could actually
>>> finish, go away, and free up resources for new work.
>>>
>>> Here's how I envision this working: If somebody dreams up a new SIP
>>> extension that does something the RTOps group can't figure
>> out how to
>>> do reasonably with what we have, then we run a BOF and see if it is
>>> worth working on. If so, then we charter a working group,
>> If not, we
>>> either pursue AD-sponsored individual informational
>> (assuming it does
>>> not need to be a STD track), or we don't work on it.  If we
>> have more
>>> WGs than meeting slots, some WGs don't meet, and we don't
>> charter new
>>> ones until the schedule is relieved.
>>>
>>>
>>> -- 
>>> Dean
>>>
>>>
>>>
>>> _______________________________________________
>>> RAI mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rai
>>
>> _______________________________________________
>> RAI mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rai
>>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai

_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai