My thoughts about the problems of the IETF

[Scott Bradner]

> 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
   specification."

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
working group.

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
consensus.

Scott