First, remember that Bill Strahm is a working group chair who doesn't believe he
has to either 1) interact with IETF participants, or 2) not defame IETF
participants in his official duties. He thinks its perfectly OK for Rob Austein 
of ISC to use his IETF position to defame Av8 Internet:

On Fri, 18 Jun 2004, bill wrote:
> As a working group chair - I would refuse an e-mail account that I am
> not allowed to spam control on my own terms.
>
> Before long these published email addresses would become spam sponges -
> and completely worthless (or expensive timewise to correctly filter
>
> Bill

The IETF email lists and other accounts seem not to have this problem.

Bill Strahm should also be removed as a WG chair for refusing to perform his
duties as a WG Chair according to the IETF rules.

On Sun, 25 Sep 2005 bill@strahm.net wrote:

> Nicholas Staff wrote:
> > If so are you telling me that I have to be afraid of ever voicing a
> > complaint or problem to the IESG because an AD can use that as a reason for
> > retribution?

> The way I see it - the answer is, under normal circumstances NO.  However,
> in the history of the IETF there have been several cases where people go
> out of their way to send unwarranted complaints to various ADs/IESG/IAB
> with unwarranted claims.
> 
> If you were to do this more than a few times...  Well, lets just say
> crying wolf once isn't a foul - but after a couple more times the town
> won't come out to see if there is a wolf in the pasture.

I haven't seen very many unwarranted claims, outside of Kessens instant claim,
of course.  There are few precedents for that kind of abuse.
  
However, the abuse documented by myself and others is pretty plainly abuse:
Schoolyard-level name-calling, publishing unsubscription addresses and such are
plainly abuse.  Professional dishonesty [that is to say, denying proper credit,
or crediting someone else improperly, or reporting falsely and disparagingly on
the contents of a document one hasn't read] is plainly abusive.  Defamation is
plainly abusive.

Unjustified threats to suppress valid technical criticism is a bit more
sophisticated.  I can't think of another case similar to that.  But of course,
we can figure out if my technical criticism is justified, and if it is, it
completely undermines the credibility of Kessens' complaint.  And in this case
the answer is easy to find. Simply answer these questions:

1.  Does Anycast Extension work with fine grained per packet load splitting as
    described by RFC1812 and as implemented and documented for example in Cisco
    PPLB on various Cisco routers?

If the answer to the above question is "No", then Dean Anderson, Dan Bernstein,
and Iljitsch van Beijnum are right, and ISC is wrong.  On two Working Groups, no
one has claimed that the answer is "Yes". The opposing arguments generally
either claim that PPLB is impossible (easily refuted), or that the Anycast
Extension works with course grained load balancing (which doesn't answer the
question and isn't "Yes").

2.  Has the IETF approved the Anycast Extension?

The answer is plainly "No". There is no RFC and no approval.  This is plainly
found in IETF records.

3.  Does ISC F Root operational deployment of the Anycast Extension comply 
    with RFC2870?

There is a technical standard for Root Server operation. There are technically
unambiguous ways to determine compliance with RFC 2870. Since there is no IETF
approval of the Anycast Extension, and since this Anycast Extension can't work
in general for those users that exercise fine grained load splitting according
to RFC1812, a Root DNS server with this extension cannot meet the requirements
of RFC2870 Section 2.6.  So, the answer to question 3 is "No". Therefore, this
unapproved extension should not be deployed on Root Nameservers, and ISC should
not be encouraging root server operators to do so by telling people it is safe,
approved, or "uncontroversial".

And Therefore the following are true:

	1) my criticism is valid
	2) Kessens' threat is plainly inappropriate
	3) My complaint about Kessens threat is substantiated

There is no case where Kessens complaint in retaliation to my administrative
complaint of his threat is justified.  This is because even if I and the others
were wrong in our criticism, I am still allowed to complain about the threat.  
There is no case where Kessens is allowed to retaliate for my complaint.

Second, my criticism of ISC F Root operation is well-justified, footnoted, and
technical. And it also has the characteristic of being correct and
substantiated.  But the point of posting any technical criticism is to discuss
the issues. A well-justified, footnoted criticism could possibly turn out to be
wrong. But even if some such criticism was subsequently found wrong, it is still
inappropriate to threaten a well-formed criticism. Thats just part of
discussion.

Kessens' involvement in this discussion is because he doesn't want ANY criticism
of a particular group. A group that is being inappropriately protected by
members in the IETF leadership.  This protection is well-documented in the
unchecked abuse that has been conducted and reported by several people.  

But there has also been abuse of Dan Bernstein after posting on the topic of the
Anycast Extension as well.  Bernstein's email address was posted in violation of
IETF rules.  This shows that it isn't just Dean Anderson being attacked, but a
certain group being protected.  

Kessens is supposed to promote IETF interests in his position as Area Director.  
The IETF leadership, the IESG, the A.D.s, and the WG chairs are also supposed to
act in the IETF interests and uphold the rules of the IETF.  The management of
an organization has a legal obligation to uphold its rules and act in the
organizations' interests, rather than their personal interests.  In this case,
the rules are written down, and clear.


Dean Anderson
Av8 Internet, Inc


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








_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf