Subject: [RAI] Making RAI work better

From: Cullen Jennings <[email-masked]>
Date: Tue, 30 Sep 2008 11:37:29 -0400

Over the past year or so, Jon and I have heard concerns about the
efficiency and organization of the RAI Area. We have both observed that
the larger working groups, particularly SIP and SIPPING, continue to
have difficulty tackling some of their more complex projects. The more
critical a document seems to be from a dependency perspective, the more
late surprises seem to emerge in its development and the longer it takes
to escape from the working group process. A relatively small number of
the working groups in the RAI Area seem to encompass the lion's share of
our documents in their scope, which may concentrate too much of our work
in too few areas and cause distracting parallelization.

Ultimately, these problems might result from any number of causes. There
might be structural problems with the manner the RAI Area is divided
into working groups, issues with chartering or focusing of the efforts,
snarls intrinsic to the technology, personnel problems at any number
of levels, questions of participant energy, or any of a number of
combinations thereof.

What we'd like to do is kick off a discussion about ways that we can
make RAI work better. As a part of that discussion we are reserving one
of our precious timeslots for a RAI Area open meeting in Minneapolis (at
least the Friday afternoon experiment will give us one more slot than
usual). In order to help set an agenda for that meeting, we'd like to
invite any comments and discussion on this list ([email-masked]),
or if necessarily in private correspondence to Jon and I. We're
interested to learn to what degree people believe there are problems
that need to be addressed, and what sorts of problems and potential
solutions the community can identify.

Cullen Jennings
Jon Peterson
RAI Area Directors
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Sep 2008 19:24:32 -0500

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Sep 2008 21:46:19 -0400

<rant>
Prioritizing drafts by dependency chains may help. To take an example  
that affects a draft which I'm co-authoring:

draft-shacham-sipping-session-mobility
in RFC editor queue since 2008-01-02

depends on
draft-ietf-sip-gruu
in RFC editor queue since 2007-10-15, i.e., almost a year

depends on
draft-ietf-sip-outbound
NOT-RECEIVED

Unfortunately, the current area management has not responded to  
suggestions to remove incidental dependencies as a second-best option  
when certain documents seem stuck. For example, in our case, the GRUU  
reference is of no great significance (unless GRUU changes drastically  
in the RFC editor queue, none of the details could conceivably  
matter), even more so since the document is informational. The primary  
document has no dependencies on 'outbound', but is "punished" for  
whatever sins are holding up "outbound" in purgatory.

3GPP wants to cite the document, but can't, and there's no way for the  
authors to resolve the issue, particularly since repeated requests  
have gone unanswered.

This is one example, but I suspect others have their own personal  
horror stories. Is it surprising that energy tends to flag given such  
interminable delays and non-responsiveness?
</rant>

Henning

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Sep 2008 21:31:52 -0500

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:
> 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 
> Towards this end, I recently suggested a reorganization (see 
> http://www.ietf.org/mail-archive/web/sip/current/msg23692.html).
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Sep 2008 21:34:22 -0500

Ah, yes. I left out thread prioritization in the mail I just sent. I 
agree with Henning that proper ordering of thread execution is critical.

(If this reads as nonsense to you, read my previous email, which sets up 
the analogy).

/a

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 1 Oct 2008 04:00:05 -0400

Henning,

Speaking to the portion of this about area management, I do acknowledge
(as the responsible AD for your document) that unresponsive management
is a problem in RAI, and that AD sluggishness helps to perpetuate a
cycle of delay. This is indeed one of the reasons why I'm not seeking
another term as an AD; some fresh blood and energy should definitely
help with that.

At a higher level, I also agree that unnecessary normative dependencies
are a problem. I actually wrote a draft about reducing normative
dependencies not too long ago which, I'd say, was met with about equal
parts of avid support and dismissive hostility. In that document I
questioned what it even meant for Informational documents to hold
normative dependencies, and what it meant for a particular piece of text
in a document to constitute a normative reference. I believe that deep
obscurities in this area cause us many process headaches.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Tuesday, September 30, 2008 6:46 PM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [RAI] Making RAI work better

<rant>

depends on
draft-ietf-sip-gruu

depends on
draft-ietf-sip-outbound
NOT-RECEIVED

Henning

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Oct 2008 09:18:33 +0100

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Adam Roach
> Sent: 01 October 2008 03:32
> To: Dean Willis
> Cc: [email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Wed, 1 Oct 2008 11:18:08 +0300

Hi,

one way of improving RAI might be to focus, i.e., shrink, it a bit.  
RAI was created by collecting together related WGs that used to be in  
other areas, mostly in TSV. In hindsight, the split has worked out  
extremely well overall, but there may be one or two WGs or at least  
larger work items that could move somewhere else, thereby reducing  
load a bit.

A concrete example that I've mentioned to some folks is the RTP part  
of AVT, which to me at least could as well become a TSV-area work item  
somewhere. (Especially if AVT should decide to start work on some  
major new version of RTP.) SIGTRAN might be another example. Other  
such work items might exist where RAI intersects with other areas.

Note that I'm not pushing for any of this to happen, I'm merely  
bringing it up as a possibility for discussion, since you asked for  
input.

Lars