Melinda Shore wrote: > Martin Rex wrote: > > > > As I understand and see it, the IESG is running IETF processes, > > is mentoring IETF processes (towards WG Chairs, BOFs, individuals > > with complaints/appeals), and is trying to keep an eye on the > > overall architecture, and put togethe the pieces from reviews > > they obtain from their trusted reviewers, such as directorates. > > They also gatekeep the work. If they don't believe that something > is a problem, whether it because it's outside of the experience or > expertise, or it really isn't a problem, it doesn't get chartered, > it doesn't get sponsored, and it doesn't get published. If > everybody serving that gatekeeper function comes from a similar > background (western white guy working for a large manufacturer) > it's going to tend to create certain biases in the work that's > taken on. 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). 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. Before allowing a new WG to start, ADs seem to make an assessment of whether there are sufficient volunteers of both kinds to do the work, whether there is sufficient expertise in the IETF to perform adequate review of the results and whether there is sufficient momentum in the effort (sufficiently large interest group, sufficiently strong desire) so that there is actually going to be results. 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. 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" 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