Re: Front-end delays
Lucy E. Lynch wrote:
Excuse top posting, please.
Many of the issues related to WG progress can be managed using the
excellent web tools provided at tools.ietf.org - see for example:
This site makes review quick and easy. Clicking on a draft title
gets you not just txt but a nits check and diffs from any previous
versions. See: draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
The top menu includes links to email the WG Chair(s) and:
Drafts | Agendas | Minutes | Charter | List Archive
making it easy to review the Charter, check the list archive for
comments on a given draft, and review minutes etc.
These tools are useful, but don't track (for example) working group last
calls. They don't even track interim meetings, at least based on my
Finding list comments by draft in a mailing list works fine when a
working group focuses on one main spec, but there are many working
groups that progress literally dozens of specs at the same time. Just
take a look at the active I-D list for SIPPING and AVT, to cite two
groups I'm familiar with. In some cases, subject headers contain the
draft title - in most cases, they don't and they may use such helpful
subject headings like "Last call comments" or "IETF 62 discussion".
(Besides the problem that a search facility for the mailing list
archives is non-existent. Not a problem for a small mailing list, but
try flipping through the WG list which generates hundreds of messages a
month and has been active for five years plus...)
There is also a link to a Draft dependency graph at the top of the drafts
page. The graph shows you where cross area review might help a draft
progress, as well as highlighting blocking drafts, expired work, etc.
If every WG had and used such a page to triage work based on blocks and
cross-area dependencies things might move faster. Authors (and WG
reviewers) can also use the nits/diffs/and list archives to make sure that
individual documents are in shape to move forward.
I'm sorry to say that for the drafts that took years to progress, 'nits'
problems were not exactly the reason. I wish it was that easy to fix.
Getting people to use the tools is a seperate issue. Just another mash
note from a tools.ietf.org fan...
These are all useful tools and I commend whoever is working on them.
They are just not quite up to the task to address the problems I
mentioned, in my opinion.
Lucy E. Lynch Academic User Services
Computing Center University of Oregon
llynch @darkwing.uoregon.edu (541) 346-1774
On Tue, 14 Jun 2005, Henning Schulzrinne wrote:
There has been a fair amount of effort in accelerating the tail end
of the document process, i.e., after IETF last call. It is unclear
whether this has succeeded (as there don't seem to be any published
measurements), but I believe that the main problem with timeliness is
now in the WG process itself. Each case is unique, but there are a
disturbing number of modest-size documents that have taken 3 to 5
years from first individual draft to RFC. In a separate message, I'll
have more process- and people-oriented suggestions, but here are some
simple things that would at least allow us to measure, and thus
(1) Problem: Currently, the mapping between charter items and drafts
is often vague and those not intimately involved with the process are
often left to guess which draft(s) meant to address which charter item.
Proposal: Once the I-Ds have been created, the charter is updated to
reflect I-D names. This doesn't have to be done for every single
draft, but doing such an update once for each IETF meeting seems
easy, as there are no substantive changes.
(2) The I-D tracker should keep track of the charter deadline for
each document so that the author and WG chairs can trivially see
whether a document is on track or not. [This item can obviously be
used to automatically generate (1).]
(3) At each WG meeting, it should be expected that after the agenda
bashing, the delivery schedule for each draft is reviewed, maybe with
a red (already out of schedule), yellow (likely to miss schedule) and
green (possible/likely to meet schedule) indication.
(4) Just like the RFC editor and IANA provides statistics, each area
should provide an overview of its status at the IESG plenary,
indicating the major work items of each WG and whether the WG is
generally on schedule or behind. Again, one could imagine a color
coding, e.g., if 30% or more of the charter items are "in the red",
the WG is flagged red.
Clearly, WG chairs and ADs could "game" the system to make the WG
look on time, by continuously adjusting schedules or by having
deadlines a decade out. That itself, however, would provide an
indication that a WG is not meeting deadlines or is planning to be
really slow. If one wanted to, one could indicate both original and
current deadline for work items.
None of these items make things faster, but they would allow the IETF
management to apply project management tools, such as reducing scope,
replacing authors, or working group chairs, with some efficiency.
More on hypotheses for why things are late in another note.
Ietf mailing list
Ietf mailing list