Date: 4 Feb 2000 01:28:14 -0000
Message-ID: <20000204012814.28947.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: isoc-board@isoc.org
Cc: djb@cr.yp.to
Subject: DNSEXT/DRUMS mismanagement
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

This is a complaint to the Internet Society Board of Trustees under RFC
2026, section 6.5.3.

Executive summary: The IAB/IESG/IETF standardization procedures, as
written and as used in practice, fall far short of the requirements of
United States antitrust law.


Here is a concrete example. I would like the DNSEXT working group to
update RFC 2181 to eliminate a security flaw that I explained on the
bugtraq mailing list. That flaw is present in BIND, but not in my new
DNS implementation.

However, I have been unable to raise this issue on the DNSEXT mailing
list, because Randy Bush---IESG member, DNSEXT chair, RFC 2181 author,
and mailing list manager---has discarded my messages.

This is not an isolated incident. Bush is systematically abusing his
position to prevent DNSEXT from seeing messages that he doesn't like.
Furthermore, IESG is condoning Bush's behavior. Please see

   http://cr.yp.to/dnscache/namedroppers.html

for details of several incidents, and details of my extensive efforts to
correct Bush's behavior through IESG's internal review mechanism.

Please note that my complaint is not merely with Bush's behavior, but
also with the procedures that have allowed such behavior. Bush's actions
should not have been cloaked in secrecy. Bush should never have been
given power to censor the mailing list in the first place. The process
for correcting censorship incidents should be swift and should not rely
on the opinions of a tiny group of people.


Here is another concrete example. I would like the DRUMS working group
to eliminate an ambiguity in RFC 1123 by making clear that SMTP servers
need not support informative responses to VRFY requests. My view is
shared by the overwhelming majority of implementors.

However, DRUMS editor John Klensin has made the opposite change. DRUMS
chair Chris Newman has refused to allow a vote on this issue, even
though ten DRUMS participants have objected to Klensin's action.

This is not an isolated incident. Please see

   http://cr.yp.to/smtp/klensin.html

for a list of specific flaws in Klensin's current document, and

   http://cr.yp.to/smtp/drums/19990215054214-9088-qmail@cr-yp-to

for details of how a typical flaw was added to the document. Klensin is
systematically abusing his position to make changes without DRUMS
approval. Newman is then falsely labelling the results as DRUMS
consensus. IESG is condoning their behavior.

Again, my complaint is not merely with the behavior of these people, but
also with the procedures that have allowed such behavior.


If you weren't aware that standardization organizations are subject to
antitrust law, you should probably read what the Supreme Court did to
the American Society of Mechanical Engineers in

   http://caselaw.findlaw.com/cgi-bin/getcase.pl?court=US&vol=456&invol=556

to punish anticompetitive behavior by a subcommittee chair. ASME didn't
know about the behavior, but its procedures didn't quite ``prevent the
standard-setting process from being biased by members with economic
interests in stifling product competition,'' as the Supreme Court put it
in a subsequent case. Bottom line: ASME paid $4.75 million.

FTC told ANSI in 1971 that standardization organizations must provide
due process, including ``timely hearings with prompt decisions.'' Two
years ago the FTC chairman publicly emphasized the importance of
``clear, fair procedures'' to help the organizations avoid mistakes, to
require ``the presentation of valid reasons for any potentially
anticompetitive activity,'' and to ``provide an antitrust tribunal with
a record.'' The IAB/IESG/IETF procedures plainly flunk these tests.

FTC also has many substantive standardization requirements. For example,
FTC told ANSI that construction standards must never be used when
performance standards can be developed. This is the same principle
expressed in the ANSI C ``as if'' rule, and in RFC 2119 section 6.
Klensin's document repeatedly violates this principle; there is nothing
in the IAB/IESG/IETF procedures requiring Klensin to obey RFC 2119.

---Dan Bernstein