--On Saturday, March 23, 2013 03:17 +0100 Martin Rex
<mrex(_at_)sap(_dot_)com> wrote:
Melinda Shore wrote:
...
To me, this "gatekeeping" looks more like an act of
self-defence. When I started going to IETFs in July 1995 (33rd
IETF in Stockholm), there were only 2-hour slots and a number
of WGs were using 2 slots. Over the years, the number of WGs &
BOFs grew, and some slots were split in two, fewer and fewer
WGs meeted twice, and then additonal slots were added on
friday, and it became more and more difficult to avoid
conflicts (and for co-ADs to ensure that at least one of them
could participate in WGs of their area).
If that were true, then the ADs are doing a lousy job of it. If
the goal were self-preservation as you suggest, then they would
be drastically reducing the number of WGs, not merely being a
little bit selective about new ones and allowing the work
expansion you identify above. Consideration of that issue is
not exactly new, see the long-expired draft-huston-ietf-pact or
the slightly later draft-klensin-overload (they differ about the
right approach but not about the problem or the need to push
back on the regular expansion on the number of WGs).
Chartering and running a WG has a significant process overhead,
and requires (a) volunteers to do do the work and (b)
volunteers with IETF process experience to drive the processes.
Yes. See the drafts mentioned above.
...
What IETF participants often do to route around this (that is
at least a common practice in the security area), is to set up
WGs sufficiently broad that not only a few WG items are
discussed, but also a number of individual submissions on the
side, only some of which are officially adopted as WG work
items. And WG charters may sometimes be several years out of
date.
One of the problems of long running WGs is, however, that they
may slow down and kill new work due to "diversity" over the
years. PKIX is in such a position. Over the years a huge
number of documents were created, and fixing defects in
existing documents is roadblock by personal pride (for the
original documents, including their defects) and the fear of
loosing face when implementations in the installed base are
suddenly identified as being defective.
These are serious allegations that the Security ADs are not
doing their jobs. Have you discussed the issues with
appropriate Nomcoms? In SAAG meetings? Considered initiating
recalls where you could identify your complaints in public.
The root cause of the many defects is vast feature bloat.
The original design principle "perfection is achieved not when
there is nothing left to add, but when there is nothing left
to remove"
...
I happen to believe this, but have noticed that many WGs don't
behave that way in practice. I've also noticed that the IETF
sometimes seems to be slipping toward what we used to deride as
the decision-making process of the ITU, characterized as
resolving an apparent choice between two alternatives by putting
both in. See the discussion in draft-resnick-on-consensus.
john
does not apply to PKIX. And the same problem is
slowly creeping into other protocols of the IETF security area
as well. TLSv1.2 is also suffering from feature bloat and a
few defects, and pride is likely to prevent dropping of the
goofed SignatureAlgorithm extension.
-Martin