Subject: RE: [dnsop] [[email-masked]: Mismanagement of the DNSOP list]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Sep 2005 07:58:00 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tim Bray

> On Sep 24, 2005, at 8:28 PM, Dean Anderson wrote:
> 
> > None of my emails have been abusive.
> 
> Speaking as a 99.99999999% passive observer around here, I consider  
> Dean Anderson's emails, in aggregate, abusive. They consume precious  
> mental bandwidth, in many cases with no material technical content,  
> and thus make it more difficult for me (and I assume many others) to  
> follow the flow of IETF discussion.

I am completely unable to follow the line of argument.

Dean appears to be claiming that DNSSEC is somehow incompatible with the
widespread use of anycast. If for the sake of argument we accept this as
true the only conclusion I could draw from such a situation is that
DNSSEC would have to be sent back to be reworked again. If DNSSEC does
not support existing use cases then it has to be fixed.

But I do not see how DNSSEC is incompatible with anycast. It is merely
an assertion that is repeated without evidence. Anycast might possibly
break TCP/IP fallback but it is unlikely that the anycast routes would
change rapidly enough for that effect to be any more significant than
existing TCP issues created by firewalls.

Cryptography is remarkably indifferent to transport, this is the biggest
challenge in the DKIM spec. Depending on particular transport
configurations has in the past turned out to be a mistake. The
authentication of the end point IP addresses in IPSEC achieves no useful
security purpose, it only causes the protocol to become more brittle in
use.

If the issue is real then it should be raised in DNSEXT where the DNSSEC
specs are being developed. It does not appear to be genuine to me.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dean Anderson <[email-masked]>
Date: Mon, 26 Sep 2005 15:41:56 -0400 (EDT)

> not support existing use cases then it has to be fixed.

It is not DNSSEC that is broken.

> an assertion that is repeated without evidence. Anycast might possibly

There has been plenty of evidence on the DNSOP list and most recently on the 
GROW list.  Without getting into to much detail, Anycast doesn't work with TCP, 
but it also doesn't work with large UDP packets and fragments. DNSSEC requires 
large UDP packets and fragments. The details of why fine grained load balancing 
permitted by RFC1812 break the Anycast Extension are hinted at in RFC1546 and 
the footnotes to my instant criticism on DNSOP. I can send you a more detailed 
explanation if you like offlist.

Your assumption below is common: You assume that everyone does course grained
load balancing or no load balancing. Besides RFC1812 permitting fine grained
load-splitting in "theory", Cisco implements it.  There are active programs
underway such as BGP multipath, which also results in fine grained
load-splitting.  One cannot assume that two successive packets are delivered to 
the same path or that two successive packets will reach the same Anycast 
destination.  This is acceptable for small, stateless UDP packets. It is not 
acceptable TCP or large UDP packets and fragments.

> specs are being developed. It does not appear to be genuine to me.

Its not a problem with DNSSEC per se. It a problem with operation of Anycast 
Root Nameservers.  There should not be any Anycast root nameservers.

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 27 Sep 2005 21:06:12 +0700

Date:        Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
    From:        Dean Anderson <[email-masked]>
    Message-ID:  <[email-masked]>

  | It is not DNSSEC that is broken.

I have not been following dnsop discussions, but from this summary, there
is nothing broken beyond your understanding of what is happening.

  | Without getting into to much detail, Anycast doesn't work with TCP, 
  | but it also doesn't work with large UDP packets and fragments.

Anycast does not work (or perhaps more correctly, in some circumstances
when there is routing instability, will not work) with fragmented UDP packets
(the size of the packets is irrelevant, only whether they are fragmented),
when sending those fragments *to* an anycast address.

  | DNSSEC requires large UDP packets and fragments.

DNSSEC might send large UDP packets, which might be fragmented, from the
server answering a query.   A query itself will not be noticeably bigger
than it was without DNSSEC (and that is generally much smaller any reasonable
MTU).

We send queries to the root servers, and receive answers from them.
An anycast address at the root server cannot possibly have any noticeable
effect upon DNSSEC UDP.

  | Your assumption below is common: You assume that everyone does course
  | grained load balancing or no load balancing.

It is irrelevant what *everyone* does - only what the root nameservers do.

It is anycast at the root name servers that you seem to be complaining about.
If the root servers are going fine grained load balancing, then it would not
only be routing instability that would result in a switch of server.   I am
by no means convinced that even that would be any kind of a serious problem
for the root servers (or those sending legitimate queries to them - they
should not be receiving large queries, and should never be sent a query via
TCP under any circumstances - unless they send you a reply with TC set, and
I doubt the root servers are going to start doing that).

But which of the root servers are doing fine grained load balancing using
anycast that way?   And why would they even consider that?   Spreading
root servers around the globe, using anycast (coarse grained anycast) makes
lots of sense, load balancing amongst several servers on the same cable
(that is, near the end of the same path) makes almost none.

Now, if you, the client, are using anycast, and you're sending DNS queries
from what is effectively an anycast address, then you're likely to have
all kinds of problems.   But that's your problem, no-one else's.

But, even assume that there was some validity in your argument (which there
isn't), the way to make it, would be something more like what you have in the
message I am replying to.     Note in this message there was no mention of ISC,
and no hints at some kind of conspiracy by anyone to do something with which
you disagree, and somehow sneak it in everywhere without your permission
(though why anyone would need that I fail to see either).   It was that
part of your messages which is what I assume was objected to, plus, quite
probably, your seeming willingness to keep on making the same invalid
argument over and over, even though you're convincing no-one who can see
past the volume.

If you want to make what you believe is a valid technical argument, make
just that, and leave out the name calling.   That is, if you're ever
allowed back onto the dnsop list in the first place.

Finally, just for your information - the IETF does not control the root
nameservers, and never has, and nothing the IETF says or does has any more
than an advisory impact upon how they operate.

kre

---

From: wayne <[email-masked]>
Date: Tue, 27 Sep 2005 11:34:13 -0500

> when sending those fragments *to* an anycast address.

In order for anycast DNS to fail, either due to the use of TCP or in
cases where the UDP DNS query was fragmented, doesn't the network
routing instability have to be such that retries also fail?  A single
failure isn't fatal, after all.  The routes would have to be flapping
pretty badly to most of the root servers (anycast or not) for this to
cause any problems, in which case, I think we would be far more
worried about other things.

> for the root servers (or those sending legitimate queries to them [...]

I'm not sure I see any problem at all here, serious or not.  Even if a
root server is doing fine grained load balancing, all the packets will
still end up at the destination address, where fragments can be
reassembled and out of order reception can be resolved.

> all kinds of problems.   But that's your problem, no-one else's.

Yeah, I can't see how a DNS client could work as an anycast
destination.  Getting an answer on a machine that you didn't send the
query from isn't going to be very useful.

This is all theoretical arguing and theory is different than
practice.

Can someone show an actual case where the use of anycast DNS servers
cause problems?  Using standard commands like dig or nslookup would be
best, but even if you have to create a specialized DNS client and/or
server, that would make any real problems much clearer.  I'm not
looking for rock solid, can-not-get-around examples even, just like I
don't think you need to show that a buffer overrun can actually cause
an exploit.  Just a proof of concept will do.

Right now, it looks like in theory, the use of anycast DNS servers
can't be a significant problem.  So far, I have seen no demonstrations
of practical problems. To the best of my understanding, this has been
the state of the debate for years now.

This looks like a tempest in a teapot to me.

-wayne

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 27 Sep 2005 16:39:41 -0400

> is nothing broken beyond your understanding of what is happening.

It's worse.  The reasoning is broken on other points, as well.

In these arguments, RFC 1812 has been cited repeatedly as a
specification for load-splitting.  By my reading, 1812 is extremely
vague about the topic, and does not require a specific spreading
algorithm.  Its strongest recommendation is that there be a way to turn
it off if it doesn't work for you, which should by itself be a clue that
load-spreading should be used with caution; it also cautions that that
load-splitting was an area of active research at the time 1812 was
published.

Moreover, load-splitting which results in the sort of flow-shredding
which would disrupt multi-packet anycast exchanges also causes
significant difficulties for unicast.  To quote from rfc2991 section 2:

   Several router implementations allow multipath forwarding.  This is
   sometimes done naively via round-robin, where each packet matching a
   given destination route is forwarded using the subsequent next-hop,
   in a round-robin fashion.  This does provide a form of load
   balancing, but there are several problems with approaches such as
   round-robin or random:

   Variable Path MTU
         Since each of the redundant paths may have a different MTU,
         this means that the overall path MTU can change on a packet-
         by-packet basis, negating the usefulness of path MTU discovery.

   Variable Latencies
         Since each of the redundant paths may have a different latency
         involved, having packets take separate paths can cause packets
         to always arrive out of order, increasing delivery latency and
         buffering requirements.

         Packet reordering causes TCP to believe that loss has taken
         place when packets with higher sequence numbers arrive before
         an earlier one.  When three or more packets are received before
         a "late" packet, TCP enters a mode called "fast-retransmit" [6]
         which consumes extra bandwidth (which could potentially cause
         more loss, decreasing throughput) as it attempts to
         unnecessarily retransmit the delayed packet(s).  Hence,
         reordering can be detrimental to network performance.

   Debugging
         Common debugging utilities such as ping and traceroute are much
         less reliable in the presence of multiple paths and may even
         present completely wrong results.

And folks I know who build gear which does load-splitting seem to be
scrupulously careful to avoid these sorts of problems. 

					- Bill

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 27 Sep 2005 20:09:00 -0500

Thus spake "wayne" <[email-masked]>
> > Anycast does not work (or perhaps more correctly, in some
> > circumstances when there is routing instability, will not work) with
> > fragmented UDP packets (the size of the packets is irrelevant, only
> > whether they are fragmented), when sending those fragments *to*
> > an anycast address.
>

The issue is when a network, usually at neither the client nor server end of
the path, uses PPLB such that packets from the same TCP query or fragments
of a single large UDP query will consistently arrive at different anycast
server instances.  The IETF and network operators have long understood that
this is a Bad Thing(tm) in general, and is one of a long list of reasons why
PPLB is strongly discouraged and sees little use today [1].

> > It is anycast at the root name servers that you seem to be
> > complaining about.  If the root servers are going fine grained load
> > balancing, then it would not only be routing instability that would
> > result in a switch of server.   I am by no means convinced that even
> > that would be any kind of a serious problem for the root servers (or
> > those sending legitimate queries to them [...]
>

Anycast in the face of PPLB has been accepted (by most of us, at least)
specifically for the root servers because current queries to the roots do
not need to be fragmented and do not use TCP.

It appears that Dean is alleging that DNSSEC will cause queries to the roots
to be fragmented or to be transmitted over TCP, thus invalidating the
exception which allows root server operators to use anycast.  While I admit
to not having followed the DNSOP list, I've seen no substantiated claims so
far that indicate DNSSEC will cause queries to exceed the minimum MTUs for
IPv4 and/or for IPv6 [2].

> the state of the debate for years now.

If Dean (or someone else) shows that the above problem case will indeed
occur in real-world situations, the criticism of DNSSEC and/or anycasting is
valid and one of the two needs to be fixed.

> This looks like a tempest in a teapot to me.

Based on the messages to the IETF list so far, it appears so.

For the record, I support a PR action against Dean due to his consistent
provocation of flame wars, particularly as they form a long-term pattern of
harassment of a particular company or persons.  Note that I consider it
irrelevant whether his position in this or any past instance turns out to be
correct: it's the form, not the content, of his efforts that is the problem.

S

[1] Many modern routers, particularly ones used in the Internet core, do not
even have the ability to enable PPLB, and the places where I've seen it used
in the last five years have exclusively been topologies that will always
re-merge the balanced traffic further upstream.
[2] I have seen misguided operators set MTUs below 200 bytes, but my
position is that these people deserve what they get in such cases.  We
cannot cater to deliberately broken implementations.

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: [email-masked]
Date: Tue, 27 Sep 2005 21:19:11 -0400

As a lurker, love him or hate him, Dean does evoke responses as varied 
as any I've observed.  Unfortunately all too often that's the only way 
some truth will be allowed to leak out.  Or people finally put pieces 
together.

-----Original Message-----
From: Stephen Sprunk <[email-masked]>
To: [email-masked]; wayne <[email-masked]>
Sent: Tue, 27 Sep 2005 20:09:00 -0500
Subject: Re: [dnsop] [[email-masked]: Mismanagement of the DNSOP list]

> worried about other things.

The issue is when a network, usually at neither the client nor server 
end of
the path, uses PPLB such that packets from the same TCP query or 
fragments
of a single large UDP query will consistently arrive at different 
anycast
server instances.  The IETF and network operators have long understood 
that
this is a Bad Thing(tm) in general, and is one of a long list of 
reasons why
PPLB is strongly discouraged and sees little use today [1].

Anycast in the face of PPLB has been accepted (by most of us, at least)
specifically for the root servers because current queries to the roots 
do
not need to be fragmented and do not use TCP.

It appears that Dean is alleging that DNSSEC will cause queries to the 
roots
to be fragmented or to be transmitted over TCP, thus invalidating the
exception which allows root server operators to use anycast.  While I 
admit
to not having followed the DNSOP list, I've seen no substantiated 
claims so
far that indicate DNSSEC will cause queries to exceed the minimum MTUs 
for
IPv4 and/or for IPv6 [2].

If Dean (or someone else) shows that the above problem case will indeed
occur in real-world situations, the criticism of DNSSEC and/or 
anycasting is
valid and one of the two needs to be fixed.

For the record, I support a PR action against Dean due to his consistent
provocation of flame wars, particularly as they form a long-term 
pattern of
harassment of a particular company or persons.  Note that I consider it
irrelevant whether his position in this or any past instance turns out 
to be
correct: it's the form, not the content, of his efforts that is the 
problem.

S

[1] Many modern routers, particularly ones used in the Internet core, 
do not
even have the ability to enable PPLB, and the places where I've seen it 
used
in the last five years have exclusively been topologies that will always
re-merge the balanced traffic further upstream.
[2] I have seen misguided operators set MTUs below 200 bytes, but my
position is that these people deserve what they get in such cases.  We
cannot cater to deliberately broken implementations.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 27 Sep 2005 23:19:58 -0400 (EDT)

I'm rather reticent to add real technical discussion to the issue of list 
mismangement. 

On Tue, 27 Sep 2005, Bill Sommerfeld wrote:

> algorithm.  

Yes. It gives the implementor tremendous lattitude. But plainly, it is 
appropriate to do (as Cisco did), per packet load balancing, where successive 
packets can be expected to take different paths.

> Its strongest recommendation is that there be a way to turn

And now there are implementations and users that use it. 

But to make anycast work with TCP or large UDP and fragments, one needs to
guarantee that two successive packets (actually an entire session) uses exactly
the same path.  No load balancing (or very course grained load balancing) is
required.  The prescription given in RFC1546 needs to be changed:

RFC1546 page 5:
---------------------------------------------------
How UDP and TCP Use Anycasting

   It is important to remember that anycasting is a stateless service.
   An internetwork has no obligation to deliver two successive packets
   sent to the same anycast address to the same host.
---------------------------------------------------

RFC1546 also gives a prescription for alterations to TCP so that TCP can work
with Anycast and with the condition on successive packets above. So far as I
know, no one has implemenated this prescription in a TCP stack.

> significant difficulties for unicast.  To quote from rfc2991 section 2:

RFC2991 is a Informational, and is wrong in some of its assertions. This was
discussed on the GROW list.

>          by-packet basis, negating the usefulness of path MTU discovery.

This is not a real problem. The MTU is reduced to the smallest MTU of any path.  
If PMTUD is turned off (an option rarely used) the DF bit is also turned off and
so packets will be fragmented.  While the smaller packet size might be
sub-optimal on the larger MTU paths, this is just a (tiny) performance
consideration.

It is not the case that the usefulness of path MTU is negated.

>          reordering can be detrimental to network performance.

RFC2991 also mis-states the TCP issue. RFC2581 describes the Fast retransmit
behavior as follows:

   "The TCP sender SHOULD use the "fast retransmit" algorithm to detect
   and repair loss, based on incoming duplicate ACKs.  The fast
   retransmit algorithm uses the arrival of 3 duplicate ACKs (4
   identical ACKs without the arrival of any other intervening packets)
   as an indication that a segment has been lost.  After receiving 3
   duplicate ACKs, TCP performs a retransmission of what appears to be
   the missing segment, without waiting for the retransmission timer to
   expire.

RFC2991 mis-states this as follows:

         When three or more packets are received before
         a "late" packet, TCP enters a mode called "fast-retransmit"

This is not the case. [However, if it were the case, it would still only affect
6% of the packets.] A fast retransmit is made after 4 idential ack packets are
received, which means that 4 packets have to be received before the late packet.

A more thorough reading of RFC2581 reveals when an ACK should be sent:

   A TCP receiver SHOULD send an immediate duplicate ACK when an out-
   of-order segment arrives.  The purpose of this ACK is to inform the
   sender that a segment was received out-of-order and which sequence
   number is expected.  From the sender's perspective, duplicate ACKs
   can be caused by a number of network problems.  First, they can be
   caused by dropped segments.  In this case, all segments after the
   dropped segment will trigger duplicate ACKs.  Second, duplicate ACKs
   can be caused by the re-ordering of data segments by the network (not
   a rare event along some network paths [Pax97]).

While out-of-order packets could trigger the fast retransmit, it occurs
just 3% of the time.  So just 3% of packets are unnecessarilly
retransmitted.  Not a great performance impact.

But again, at worst, this is merely a performance issue that may be more than
compensated for by the additional performance and availability of multiple
diverse links.

But lets not forget the benefits of load balancing over diverse paths:

For example, when a path fails, it can be immediately removed from the routers
FIB, and another path can be immediately used without waiting for routing
processes to select the next best route and add it to the FIB. [no more
blackholes until next BGP scan after link failure]. While little benefit to
SMTP, This greatly benefits VOIP and streaming audio and video.

VOIP RTP buffers have no such performance issues with multipath. As long
as each packet arrives before it is to be consumed, it does not matter
what order they arrive in.  PPLB would greatly improve VOIP performance
characteristics.

> scrupulously careful to avoid these sorts of problems. 

The equipment cannot do anything to avoid these problems. Except turn off load
balancing if necessary.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 28 Sep 2005 02:21:26 -0400 (EDT)

> not need to be fragmented and do not use TCP.

Right. But all DNS in the past (and most in the present) is small, stateless UDP
packets.  RFC1546 Anycast allows PPLB on diverse links.  But future DNS will use
large UDP packets, fragments, and more TCP.

> IPv4 and/or for IPv6 [2].

Plainly, TCP isn't going to work. Do you agree? 

But, its not merely the size of the request that is important. Its the fact that
a transaction may involve several packets and state on the server, even if that
state isn't explicitly maintained by DNS.  ENDSO will try to send large or
multiple UDP packets back to the client. This may result in PMTUD packets back
to the anycast root server. There is no guarentee that this ICMP packet will get
to the correct anycasted root server.  Result: client does not get a response.

There is a bit of history here: At first, it was assumed the DNSSEC would
require TCP. By requiring ENSDO support in the security-aware resolvers, TCP is
not necessary for DNSSEC.  So, for a while, I thought this might be a non issue
for root servers, but still an issue for servers that had to support TCP. Then
Iljitsch van Beijnum (an expert on BGP) noted that fragments would have a
terrible problem with Anycast and PPLB. This makes root servers problematic. At
about this same time, ISC submitted the anycast extension to the GROW working
group. So, discussion has moved there. No one on the GROW list asserts that the
Anycast Extension can work with fine grained load splitting as described with
TCP or with Large UDP Packets and fragments. 

> valid and one of the two needs to be fixed.

I've tested that TCP does not work with Anycast and PPLB.  Not that this is any
surprise. RFC1546 indicates this.

Also, as I tried to point out to Phillip Hallam-Baker, but he didn't seem to get
it: There is nothing in the problem specific to DNSSEC, nor is DNSSEC itself
broken. There is no way to fix DNSSEC to work with Anycast.  The problem occurs
with any protocol that uses TCP, or large UDP packets or fragments.  DNSSEC is a
protocol that uses either TCP or large UDP packets or fragments. It is not
possible to make DNSSEC work exclusively with small, stateless UDP packets. This
is why EDNSO is required for DNSSEC.

> provocation of flame wars,

Note that Stephen Sprunk has disagreed vehemently with me on non-IETF issues on
Nanog. 

I have been involved in a number of controversial or unpopular issues. And on a 
great number of these, I have been vindicated over time. I've said things like:

 	Anti-trust law will apply to blacklists. It did.
	The First Amendment isn't a defense against anti-trust. It wasn't
	Electr. Comm. Privacy laws prevent unauthorized boycotts. They did.
	Electr. Comm. Privacy laws prohibit reading email. They did.
	That the IEMCC was a good compromise. It was.
	That a complete ban on commercial email was unreasonable. It was.
	etc

Many of these things were absolute heresy to the anti-spam crowd at the time
they were said.  Some of them still are.  But as President of the League for
Programming Freedom, I knew a lot about boycotts and anti-trust law. I had
supervised boycotts and I had been involved in organizing protest marches with
proper permits.  I had supervised court cases through to the US Supreme Court. I
talked with a lot of lawyers, and asked a lot of questions.  I wanted to know
how the law worked. As a result, I had read a lot of law, and knew a little
about things like statutory construction.  This prepared me to analyze the ECPA
when people on Nanog suggested reading customers' email to see if was
commercial. People on Nanog said the ECPA didn't apply to email. They were
plainly wrong, but hated me for saying so.  When Nanog'ers were fired for
conducting abuse, they blamed me.

The above issues are all supposed to be outside of the IETF. But I've been
harrassed by the people who engaged in these arguments ever since, including at
the IETF.  You can frequently identify them by their participation in Nanog and
anti-spam issues.

Just recently, people wanted the IETF to associate with counterfeit
anti-spammers who were also 3-time court-proven liars. This was really
remarkable, since many on the IETF are academic or research scientists.  
Associating with such dishonesty would discredit them in their professional
life. I've never seen people try so hard to associate with the dishonest, and
try so hard to suppress facts that are easilly checked, like that fact of being
a court-proven liar, twice lying on the subject of open relays, which was what
the IETF people wanted to associate and trust them on.  This provoked a very
strong response in personal harrassment.

But that was truly remarkable, so much so, I'll digree here for a moment. I've
worked in research environments (Charles Stark Draper Lab), and attended MIT,
I've had a little experience with this community.  My GF teaches at MIT. She's
had a couple students plagarize over the years.  This is a very serious academic
offense. It is grounds for expulsion. Years of work is lost. What good school
wants to admit a plagarist?  I know what "professional dishonesty" means to an
academic or researcher.

Academic and research professionals have great concern for things that go under
the heading of "professional dishonesty".  Professionals don't associate with
liars, particularly when those lies are established by a court, and on the same
topic. Honest people seek truth, not lies. No professinal wants to be associated
with dishonesty. Security clearances are denied for dishonesty. Professional
credibility, established over a lifetime, is lost.  And by "professional", I
don't mean "someone who does something for a living", as in "Professional
car-mechanic". I mean academic and research professionals, who have standards to
meet, and a career at risk.  

Back to controversies:  Just recently, the DNSEXT chairs also tried to violate
the patent policy of the IETF by suppressing discussion, and failing to obtain
disclosure statements.  This is another valid complaint, which is also under the
supervision of David Kessens. Plainly, the DNSEXT WG Chair doesn't really
appreciate my contribution to adhering to IETF policy.  Kessens' has so far
ignored the complaint, except to try to prevent me from posting, on a frivolous 
claim.

Another controversy: Certain IETF WG Chairs think they can do IETF work
according to their own terms, and according to their own policies.  Ususally
employees that refuse to adhere to company policies are shown the door. Usually,
the sooner this is done, the better.

These things make me unpopular with some people. These things don't justify the
harrassment that has been directed at me. The policies of the IETF are meant to
protect me from this harrassment.  The management of the IETF has the authority,
responsibility, and obligation to protect me from this harrassment, and from
defamation by IETF officials.  It is a scandal that the IETF management is
involved in conducting the abuse, and has failed to stop the abuse and the
defamation. 

> particularly as they form a long-term pattern of harassment of a particular
> company or persons.

I have not harrassed anyone.  I have been harrassed, as evidenced by the
numerous school-yard name-calling, defamation, disparagement, etc. I have not
engaged in this behavior. Mostly, this behavior is motivated for my positions on
the above (many not IETF relevant) issues. But the harrassment isn't limited to
harrassing Dean Anderson or Av8 Internet. There are a small number of abusers.
They abuse many people, and their abuse is unchecked by IETF management.

In the case of instant criticism of ISC, several people have raised the same
objections, and have been similarly attacked.  Attacks for genuine ISC criticism
are not limited to me personally.

But Non-IETF conflict should be kept out of IETF business. There are policies to
disclose conflicts of interest.  This does not mean that ISC should be immune
from criticism for improper root server operation on the DNSOP list. That topic
is specifically listed in the DNSOP charter. It does mean that ISC employees
should be prevented from using their official IETF position to defame Av8
Internet. It means that people should be prevented from disparaging Dean
Anderson and Av8 Internet, as well as a number of other people. 

> Note that I consider it irrelevant whether his position in this or any past
> instance turns out to be correct: it's the form, not the content, of his
> efforts that is the problem.

Note that Stephen Sprunk has disagreed vehemently with the above listed non-IETF
issues on Nanog.  There is plainly nothing wrong with the form of my messages.  
The attacks are personally motivated.

> even have the ability to enable PPLB, and the places where I've seen it used

This is a false statement.  Many small ISPs still use Cisco 7200 and 7500 series
Cisco routers. These routers are capable of PPLB.  Further, PPLB does not need
to be done in the core, or on core routers. It can be done on a CPE Cisco 2600
that has 2 T1s which have diverse paths. Many ISPs large and small offer
multiple T1 services to different ISP sites. Many ISPs do hot-potato routing.  
PPLB does not require BGP. It can be done with multiple default routes on the
just described 2600.

> re-merge the balanced traffic further upstream.

This also isn't true. Not "exclusively" by a longshot. Many small ISPs have
multiple sites with different upstream connections at each site. Some such ISPs
use default egress routes. Even with BGP, the different sites frequently do
hot-potato routing. Packets that go to one site, go to one upstream. Packets
that go to the other site, go to a different upstream.  Remember that CPE 2600
that is doing fine grained load balancing between these sites.

> cannot cater to deliberately broken implementations.

Your opinion of "deliberately broken" may not be shared by everyone. This is why
we have standards that set things like minimum MTU.  But your attitude and
disregard for standards reveals a lot.

Fortunately, we realized long ago that people like Stephen Sprunk couldn't be
trusted to run root DNS servers however they thought right, to the detriment of
those they thought "broken". So we've had standards (RFC2870) for operation of
root DNS servers.  This may be the only IETF RFC that someone actually MUST
comply with, and can't ignore if they please.

---

From: Kevin Loch <[email-masked]>
Date: Wed, 28 Sep 2005 04:22:48 -0400

> large UDP packets, fragments, and more TCP.

That's a big change for something we depending so much on today.
Perhaps this future DNS should have a new name and use a different well
known port to avoid confusion.  I suggest calling it "LDAP" and using
ports 389/636.

Add "discourages protocol bloat" to the list of well known benefits of
anycast DNS.

- Kevin

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Sep 2005 17:03:40 +0200

> some truth will be allowed to leak out.  Or people finally put pieces 

this particular cure -- if one lives in a world where this is a cure -- is far 
worse than the disease.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: "Thomas Gal" <[email-masked]>
Date: Wed, 28 Sep 2005 17:06:37 -0700

> Behalf Of Stephen Sprunk
> 
> Note that I consider it irrelevant 
> whether his position in this or any past instance turns out to be

	That is a perilous line of reasoning indeed. You're saying if I
don't like the way you put something then I should be able to get you
booted. 

	In fact we're talking about DOS here. IF the subject matter is
relevant to the working group, or in the case of the IETF list, generally
converning the IETF's activities, procedures, and standards etc. than the
discourse is serving it's purpose. Getting things done is not *typically*
easy and pain free. In fact, if it is, then likely something was supressed,
or the issues wasn't really in need of discussion. 

	Is this issue preventing a working group from reaching consensus? Is
the issue here that maybe this concern was addressed, not accepted to be
calamitous enough by the working group to change course, and yet the same
issue was raised again (that's what it seems like to me)? That may justify
possibly suspending posting rights to the dnsop list (though I'm not making
that claim) but how does that just extend to the IETF list in any way?
Backing down because of fear of retribution from AD/Chairs/IESG etc.
certainly is not condusive to progress so I don't consider much of this
discussion off topic. As for what I've seen from the DNSOP list, as well as
past history with Dean is that he is certainly forceful and opinionated in
the way many of the vocal, active, and frankly productive members of the
IETF are. I think we've gotten Dean's summary explanation of the situation
from the message forwarded to the IETF list along with his other comments. 

	What I've not seen is any sort of detail/outline with references to
a series of emails which demonstrate a pattern of abuse, a warning, and
continued abuse that one could verify but examining archives of email
transmissions. It seems that rather quickly upon commencement of this topic
people diverged into arguing the technical issues associated with his
challenge, and personal matters relating to Dean.

	So in summary I pointedly disagree, and believe that the content of
the messages ( and frankly the lack of pointed content in the challenge )
should be the primary factor in this matter, and I hope that being too
forceful, stubborn, or persistent (NOT oblivious or ambivalent) doesn't
become justification for reprimand.

-Tom

---

From: grenville armitage <[email-masked]>
Date: Thu, 29 Sep 2005 10:56:01 +1000

Thomas Gal wrote:

	[..]
> I hope that being too

Since when have political conspiracy theories, allusions to impending
legal action and references to other people's dating lives been admirable
examples of 'forceful, stubborn, or persistent' discourse?

cheers,
gja

---

From: "Thomas Gal" <[email-masked]>
Date: Wed, 28 Sep 2005 18:12:27 -0700

> 
> Thomas Gal wrote:
> 
> 	[..]
> > I hope that being too
> > forceful, stubborn, or persistent (NOT oblivious or ambivalent) 
> > doesn't become justification for reprimand.
> 
> Since when have political conspiracy theories, allusions to 
> impending legal action and references to other people's 
> dating lives been admirable examples of 'forceful, stubborn, 
> or persistent' discourse?
> 

I guess those first two kinds of things (my personal least favorite is the
age old "if the IETF doesn't [insert personal uber-issue here] then it shall
be doomed to irellevancy") usually end up slipping in as an adjunct to
heated converstation, hence I proposed a cooling off mechanism in another
email.

That being said references to other people's dating lives (true or not)
clearly has no way of being on topic, and definitely would make a good
example of what I mentioned could be a series of examples of innapropriate
posts. In fact even in the case of political conspiracy and impending legal
action, despite being dropped here and there, there's nothing to stop the
parties at any time from lapsing back to pointed objective discussion of the
facts. It just usually doesn't work out that way.

-Tom

---

From: Dean Anderson <[email-masked]>
Date: Thu, 29 Sep 2005 08:31:25 -0400 (EDT)

On Thu, 29 Sep 2005, grenville armitage wrote:

> Since when have political conspiracy theories, 

Political conspiracy theory? The disparagement machine is working overtime.

> allusions to impending legal action

I made no allusions.  I demanded compliance with the law and performance of
fiduciary duty, and for the IETF to stop defamation. That isn't an allusion.

> and references to other people's dating lives 

I made no reference to anyone else's dating life.  However, memory serves that
we dated the same girl.  It is quite reasonable to question if the new partner
of a lost romance is a target for long term vengeful behavior and animosity.  
Some people hold these grudges their entire lives.

> been admirable examples of 'forceful, stubborn, or persistent' discourse?

These characteristics are all more admirable than "court proven liar",
"professionally dishonest", or "lack of personal integrity"

		--Dean