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