Folks,
Anyone who agrees with the CfC statement, and doesn't say anything,
is fine, because the CfC doesn't need or want their support. ...
That's pretty much how I've seen IETF consensus work over the years.
There are two, essential assumptions that serve as underpinnings for the IETF's
rough consensus construct:
1. Participation in the IETF is dominated by those with sufficient
expertise for making informed assessment, and
2. Participation in the IETF is dominated by those with sufficient interest
to ensure forward progress is made in a timely fashion.
Today's IETF is marked by massively more diversity than was present 15 years
ago. For most IETF activities, most IETF participants do *not* have very much
knowledge or interest.
While this violates the stated assumptions, it also means that such folk stay
pretty quiet, about most IETF activities. For these cases, the "see who
objects" model makes sense and appears to work acceptably... once the basic
competence of a proposal or specification is assessed.
However, many IETF activities draw the attention of these folk who lack
knowledge and/or lack a desire for making near-term progress (or any progress at
all.) If a topic is sufficiently "interesting" it draws quite a few of these
people and the current model effectively gives them a veto.
We need to fix this.
The IETF needs to modify its method of assessing rough consensus, to
distinguish between those motivated to make timely progress and those with
other agendas. Of course, this needs to be accomplished in a way that
continues to attend to basic technical and operational competence.
Other agendas include such sources of delay and distraction as expanding the
scope of the work, pressing for alternate solutions, or raising a myriad of
generic concerns that really are present for all new work. (Hence, attending to
them represents either a strategic issue for the IETF or an unsolvable problem.)
In other words, those trying to solve a particular problem in a competent
fashion, and to get it deployed in a timely manner, need to be able to make
progress efficiently.
Anyone, at any time, may expose a critical risk or critical failure in a
proposal or specification. No IETF procedure should *ever* work against having
such exposures gain attention.
That said, the current IETF process allows delay and distraction for many
reasons that are entirely secondary.
I believe that utility, quality and timely progress are not mutually exclusive
and that a rather simple framework can accommodate all of them:
1. A constituency is a group of otherwise-independent individuals seeking to
produce a specification that provides a set of desirable enhancements or fixes
an acknowledged set of problems.
2. A charter specifies the scope, schedule and deliverables for a
constituency's efforts. Those claiming to be part of the constituency are
committing to that scope, schedule and deliverables.
3. On-going review and input by others are essential to a constituency's
efforts. Anyone can come up with a good idea or solve a difficult problem. This
is a key lesson of the IETF.
4. A particular bit of input that addresses a critical failing MUST be
heeded, no matter when it is offered.
5. Other bits of input MAY be heeded, when the constituency agrees that the
input is within scope, does not endanger the schedule, and is supported by the
constituency. Otherwise the input MAY be deferred or even ignored.
6. The chair(s) enforce these constraints.
Of course, any suggestion like this list of rules requires that the community be
willing to exercise self-discipline, rather than permit individuals to veto
valid group efforts.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf