On Wed, 23 Jan 2008, David Conrad wrote:

> [It has been suggested that I ³not feed the trolls² and that this isn't
> really relevant to the EVIL 'BIND COMPANY' (which appears to be growing to
> encompass the remaining free world) PLOT known as "AXFR Clarify", so this
> will be my last response on this thread. Iıve been responding to give
> people an idea of how things work at IANA. Feel free to delete this message
> if this isnıt of interest]

First, IANA is a US government function. Its records are government
records. Altering government records without authorization is felony.
As a custodian of government records, ICANN has some serious
responsibilities for their care. I think Mr. Conrad should take those
responsibilities much more seriously than it seems he does. It seems
highly improper for Mr. Conrad, under official ICANN and IANA
(government) colors, to engage in exaggerations such as the above which
ridicule and defame and are inappropriate to the IETF.

Second, the misconduct alleged on the AXFR-clarify draft from 2000 to
2003 happened while David Conrad was the CEO of Nomimum, and shared an
office with Paul Vixie. The original AXFR-clarify draft was submitted by
a Nominum employee. The false assurances that no wire changes were made
by a Nomimum employee. People relied on these false assurances.

During this period (1996-2002), Paul Vixie misled the internet community
that MAPS was a non-profit enterprise. Sharing an office with Vixie,
Conrad must have been aware of the true facts about MAPS status, but
kept silent.

As I already noted in my previous message, Vixie was a shareholder and
Board Member of a commercial bulk emailer known as Whitehat
(1998-2002+). But this wasn't widely known at the time. Sharing an
office with Vixie, it seems hard to believe that Conrad wasn't aware of
that. Conrad still kept silent.

Also during this period (2000-2001), Paul Vixie was a defendant in
Exactis v. MAPS, which cited charges of Tortious Interference with
Contract, Tortious Interference with Prospective Business Relations,
violation of the Colorado Consumer Protection Act, Intentional and
Negligent Misrepresentation and Extortion, violation of the Colorado
Communications Privacy Act, violation of the Colorado Organized Crime
Control Act, violation of the Sherman Antitrust Act, violation of the
Colorado Antitrust act. A Temporary Restraining Order (TRO) was
obtained. Vixie and MAPS attempts to have the case dismissed failed,
and MAPS settled out of Court. MAPS no longer blocks Exactis.

A TRO is a fact. A TRO is citable in subsequent litigation. A previous
TRO helps establish that similar facts are sufficient to establish
similar claims.

A TRO is a decision that the facts cited, if true, are sufficient to
establish the claims made and that the plaintiff can prevail absent
false facts or some defense. MAPS and Vixie tried vigorously to have the
case dismissed, using defenses they also cited in their reply. Those
efforts to have the case dismiss failed. Those are facts, too.

Exactis V. MAPS is basically a RICO case. The statute of limitations of
RICO is 10 years. Anyone who is injured by the RICO enterprise can
bring a RICO case. Indeed, I think I have been injured by this
enterprise. In 1998, I was threatened on NANOG with physical harm in
connection with this RICO enterprise. This threat is a violation of the
Hobbs Act (a RICO predicate act). Mr. Conrad was a member of NANOG at
that time, but he kept silent. More injury from this enterprise has
happened since 1998, some of it in connection with the AXFR-clarify
scheme, even. When a non-profit is involved, economic harm can be the
unlawful object of a RICO enterprise, in addition to economic profit.

So, during the same time as events of Exactis V. MAPS, during the period
of the AXFR-clarify events (2000-2003), Mr. Conrad was in the same
office as Paul Vixie, overseeing in the AXFR-clarify scheme involving
false statements (the fact that there were no wire changes in
AXFR-clarify) that people relied on (the members of the IETF WG).
Nominum, ISC and UltraDNS were the benefactors of that scheme.

Without commenting on whether any laws were broken, there are clearly
ethical problems and serious misconduct of IETF officials and other IETF
members, including Mr. Conrad.

> Dean,
> On 1/23/08 3:48 PM, "Dean Anderson" wrote:
> >> It isn't clear to me that they did, at least since I've been at IANA -- the
> >> last change to the dns-header-flags registry was done on 9 June 2005 (as a
> >> result of RFC 4035).

> >
> > Hmm. A line became wrong, as Ed noted. Was it always wrong? Are there
> > archives? Is there version control?

> It just may be Ed made a bit of a booboo. As Josh pointed out, the registry
> appears to always have been the way it is. Whether it is wrong is likely a
> value judgment. Yes, there are internal archives and version control.

At least, there is version control. I suppose that's a start. But then
in that case, why weren't the dates of changes clear to you in your
first response?

> > Perhaps IANA should notify more contacts of changes to IANA documents.
> > I'd like to be on that notification list.

> We don't currently have a mechanism in place for this. If others think it
> useful, I'll ask to have this discussed with the IESG to see if they feel it
> appropriate (and if so, what priority they'd place on it).

Good. Though, it seems ICANN could do this without input from their IETF
technical consultant. It seems to be an administrative matter, more than
a technical matter. I think consultation with the Department of Commerce
would also be appropriate. But of course, speaking for myself, members
of the IETF will offer technical assistance as necessary.

> > What controls does IANA have in place to prevent unauthorized changes?
> >
> > Most institutions have audit trails to discover and prevent unauthorized
> > changes to important "stuff".

> Audit trails, of course, do not prevent unauthorized changes.

Audit trails deter unauthorized changes when employees understand there
is an audit trail, and the audit trail can't be altered by the

> All changes (and proposed changes) are tracked via a ticketing system.
> Modification of the IANA registries is limited to authorized personnel
> (IANA staff) and are version controlled. We're looking into PGP/GPG
> signing the registries, but other priorities have consumed our limited
> resources.

This all sounds good.

> > Lets try not to have "stuff happen" to important "stuff"

> So kind of you to make the suggestion. We'll try to keep it in mind.

I'm not very assured you will when you make the excuse that "stuff
happens". I'm not at all convinced you are the right person for that


Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.