Frameworks for analysis: quality control and resource availability

Robert Elz kre at munnari.OZ.AU
Wed Jan 29 17:56:45 CET 2003


    Date:        Tue, 28 Jan 2003 09:54:46 -0800 (PST)
    From:        Bernard Aboba <aboba at internaut.com>
    Message-ID:  <Pine.LNX.4.44.0301280857180.13579-100000 at internaut.com>

I've only just joined the list, so some of what I'm about to say
may be out of place, if so, just tell me (I have read the draft
charter - initially I wasn't sure if perhaps current discussions
were just about it).

I agree with Bernard - redoing work is a problem, and late review is
part of the cause for that.

However I am not sure that measuring ...

  | * Delay between IETF last call and IESG approval
  | * Number of draft revisions betwen IETF last call and RFC publication

will tell us a lot.   I have a draft which is now approaching (I think,
it has been so long I have forgotten) 3 years since IETF last call (might
be just a bit after 2 years).   In that interval there have been several
revisions to the draft, but none that could really be considered rework.
Most of it has been meaningless noise (I changed my affiliation during
that period, some trivial wording changes were made, etc, nothing at all
to the real substance of the draft).   The draft is still in someone's queue,
no signs of it having anything done to it any time soon...  (when it
eventually appears, Henning's max of 5 years & 2 months from I-D -00 to
publication will be blown away, and it isn't because of the WG, which
ceased doing anything much on the draft back about the time of the IETF
last call - there has been no need for more).

Another part of the problem (this particular problem) seems to me that
we have started to strive for perfection in PS's - we want to fix every
possible thing (we being both the WG's, and perhaps even moreso, the IESG)
before allowing publication.

I consider this a problem - in PS's we should be keeping very well aware
of the "Proposed" nature, and stop seeking to make the things perfect.
They should be made better before getting to DS state (by that stage,
good enough that all the substance should be pretty much right) and as
good as we'll ever get them at Full Standard (and even that shouldn't
be expecting perfection - even full standards can be corrected, updated,
etc, as required).

How to get everyone to agree to lower the bar, I have no idea.

  | In terms of resource contraints, I would like to suggest that the IESG may
  | not be the true bottleneck of the process

It varies.   Sometimes they are, sometimes they aren't.   Personally
I certainly believe that the current structure (in terms of responsibilities
expected to be handled) of the IESG cannot do other than cause problems.

  | If true, the solution to this would *not* be to attempt to get those
  | individuals to "do more work" -- but rather to determine whether the
  | resources exist for success before chartering a WG in the first place.

I believe this is done already, as much as it can be.   The issue here
is that you're asking for predictions of the future.   In practice it
just doesn't work.

  | -----------------------------------------------------------------------
  | On December 11, 2002, Harald said:

I wasn't on the list way back then, so I didn't see this message
(actually, until very recently, the last I remember seeing about any
of this was the call for suggestions/volunteers for the chair position.
I wasn't in Atlanta, and didn't know that things had actually really started,
but that probably means I just missed a message).

In any case, I will reply to a few of his points, since you kindly quoted
his message...

  | 1) The standards activity in the WGs could function better.

Certainly it could, and all of the issues stated seem relevant.

But I'd also add the desire for perfection at the first attempt.
So...

  |    Most of the solutions suggested are of the form
  |    "clueful people must do more work".

For this one, the solution would be "do less work" which is always
an attractive answer.

  | 2) The IESG does not have capacity to do more work.

I certainly believe that.   But much of this is of the IESG's
own making.   They don't have to do much of what they currently
actually do, even assuming that the function of the IESG is not
altered.   Again, striving for perfection in everything published
seems to be much of the problem.

  |    The solution set seems to evolve around:
  |    - Get someone else to do part of the work
  |      (farm out policy-setting, document review, WG management....)

This is more important than just reducing workload.   The IESG's
current responsibilities conflict with each other in nasty ways.

Even ignoring workload issues, the responsibilities of the IESG should
be separated out, and the IESG should be returned to doing the job
it had pre-Kobe (that of managing the working groups, and throw in the
overall IETF meetings - which is mostly done by the secretariat anyway),
which is a big enough job all by itself.

But expecting the same people to then be the judges of whether the
working groups (they are responsible for) have been successful or not
is, in my mind, ludicrous.

  |    - Institute rules that are simpler to manage to than current rules

That wouldn't hurt.   Just "less rules" wouldn't hurt.   Part of the
problem may be that more rules keep getting invented, when they seem
likely to help solve an apaprent problem - then they remain around to
be enforced long after the problem (if there ever really was one that
needed this kind of solution) has vanished from view.   (And I know
that we're not supposed to be discussing solutions, here, or perhaps, yet).

  |    - Reduce the size of the IETF

A much offered suggestion, with no practical means of achievement that
would be effective.    Increasing costs just changes the participation
to people with (in many cases) less time, and less capacity, to achieve
something useful.   Splitting into several groups just means that now
lots of people have several groups to participate in, and after overheads
of that are subtracted out, even less time to actually devote to doing
real work.

kre



More information about the Problem-statement mailing list