My thoughts about the problems of the IETF
sob at harvard.edu
Thu Apr 17 11:27:50 CEST 2003
> It is a fundamental precept of the IETF that the rough
> consensus of the "mobs", developed in a fair and open
> process, will produce good results. And, all of our
> processes and systems are built around that assumption.
this is far to simplistic
To me, one of the principal things that makes the IETF the IETF and not
"just" one of the many other SDOs, and in particular, other
multi-disciplinary SDOs, is that the IETF has an overarching *technical*
management as part of its process.
The role of the IESG is not just to verify that the processes have been
followed, but to also do an actual technical review. Consensus in a
working group, by itself, has never been sufficient in the IETF to cause
publication as a standards track RFC.
The idea that a technical review of the output of a working group is part
of the IETF is not new. See RFC 1310 (RFC 2026's grand parent) sec 2.6.
At that time the IAB was the formal approval committee (not the IESG) and
technical review could be quite a production, potentially being done by a
specially commissioned technical review committee commissioned by the AD or
IESG even before it got to the IAB where the IAB did its own technical
review. This process was simplified somewhat in RFC 1602 (RFC 2026's
parent) but a technical review was still an important part of the IETF
process. This importance was retained in RFC 2026.
It is my opinion that it is the IESG's responsibility (not just right)
under 2026 to do a technical review and pushback on a working group if
finds a *technical* (or clarity) problem with a proposal. Even if
the working group has a strong consensus in support of a proposal.
I think the IESG has this responsibility under RFC 2026 sec 6:
"The experienced collective judgment of the IESG
concerning the technical quality of a specification proposed for
elevation to or advancement in the standards track is an essential
component of the decision-making process."
and RFC 2026 sec 6.1.2
"The IESG shall determine whether or not a specification submitted to
it according to section 6.1.1 satisfies the applicable criteria for
the recommended action (see sections 4.1 and 4.2), and shall in
addition determine whether or not the technical quality and clarity
of the specification is consistent with that expected for the
maturity level to which the specification is recommended."
. . .
"the IESG may,
at its discretion, commission an independent technical review of the
and RFC 2026 sec 4.1.1
"A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it."
Also, in my opinion, proposals which have inadequate security or might have
a significant negative impact on the health of the Internet (e.g., no or
poor congestion control) fail this requirement for "no known technical
omissions" and the IESG is required to push any such proposals back to the
As an aside, I think that the IESG needs to be quite public when doing any
pushback, it should not just interact in a back room with a document editor
-- any pushback (or other IESG or AD comments on a proposal) must be in
public and recorded for the record.
As hinted above, I do have a problem with the IESG making decisions based
on non-technical issues (other than document clarity, which is specifically
called out in RFC 2026) unless the decision is supported by community
More information about the Problem-statement