--On Saturday, March 23, 2013 03:17 +0100 Martin Rex <mrex@xxxxxxx> 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