IESG--This is probably relevant to the Appeal on draft-ietf-grow-anycast, and
illustrates why the draft-ietf-grow-anycast document should be killed.

I note in the datatracker for draft-ietf-grow-anycast, and am told by Abley,
that they plan to take the document to another draft -04, even though there is
no chance for the document to avoid the stateful anycast subject fraud. Nor is
there any chance of achieving consensus in light of the information known about
the fraud.  Keeping the draft-ietf-grow-anycast document alive in any form gives
the perpetrators the (deception) opportunity to reference the document in new
drafts, as described by Abley below.

Working group chairs should probably also be warned to be alert for documents
that promote the fraudulent stateful anycast scheme.

There is also a note pointed out below from Joe Abley regarding my opposition to
the draft-ietf-grow-anycast which directly contradicts David Kessens statements
in the datatracker comments for draft-ietf-grow-anycast.

More inline. 

 On Fri, 23 Jun 2006, Joe Abley wrote:

> 
> On 23-Jun-2006, at 18:41, Dean Anderson wrote:
> 
> > On Fri, 23 Jun 2006, Joe Abley wrote:
> >
> >> This note has very limited application to the AS112 project, but since you
> >> asked it here I am happy to give you the courtesy of a response.
> >
> > If you want to put it in the draft, and you want DNSOP to consider the
> > draft, then its relevant.
> 
> Not really. The reference [draft-ietf-grow-anycast -ed.] is an active
> document, and its content is relevant to this draft. If the draft referred to
> dies, then replacing it with a different reference might well make sense.
> However, while the draft referred to is alive, and the most appropriate
> reference, I don't see any reason to make a change.

What the DNSOP group may not know, [but ISC, RIPE, Joe Abley, David Kessens, and
the IESG do know], is that the report claiming that stateful anycast was stable
was fabricated, and no stateful testing was performed by the DNSMON program.

The notion of a safe stateful anycast operation as asserted by Daniel Karrenberg
(http://www.nanog.org/mtg-0505/pdf/karrenberg.pdf) has now been discredited.
Karrenberg's document misled people to believe that stateful anycast was safe,
when in fact Karrenberg didn't perform any stateful testing whatsoever.

So, there is no evidence that stateful anycast is safe, and substantial evidence
that it is not safe:  Mark Kosters reports on data gathered at J root:

http://www.nanog.org/mtg-0410/pdf/kosters.pdf

    + Expected to see a saw tooth distribution .
      instead have a noisy distribution in many cases
    + Does not affect UDP
    + DO NOT RUN Anycast with Stateful Transport

http://www.rssac.org/meetings/04-08/2004WashDC.html
    Kosters repeats warning on stateful DNS Anycast, but is disputed by
Karrenberg.  It is later found (January, 2006) that Karrenberg has done no
stateful testing whatsoever, and did not reveal that his testing was only for
stateless DNS, and therefore irrelevant to Kosters data.  This discovery was
only made when Anderson examined the source code to the DNSMON program written
by Karrenberg to conduct this testing.

Now put this in context along with repeated assertions from Joe Abley and others
associated with ISC and RIPE that stateful anycast is safe and even
non-controversial.

> If this were a working group document, then this matter would be a matter of
> consensus. Since it's an individual submission, I believe it's up to us as
> authors, and any differences of opinion you might have with us should properly
> be brought up if the documents are ever last-called.

So, basically, I can't object until it is last-called?  How interesting, given
that the GROW document was improperly last-called without consensus.  So, you
want me to wait till last-call to raise these objections?  That seems like a
waste of time in the meantime.

This draft inappropriately promotes the fraudulent notion of stateful anycast.  
Your scheme here seems to me to abuse the process, in spite of on-going issues
with scientifically fraudulent stateful anycast claims in the GROW document by
you (Abley) and other conspirators named in the IESG Appeal on this subject.

> It's difficult to characterise your objection as anything other than an
> oblique reaction to the anycast draft, however, of which your dislike is
> profoundly on-record.

This strikes me as odd thing to say. Its odd because David Kessens told the IESG
in the datatracker comments on the GROW draft that I (Anderson) didn't object
strongly to the anycast draft.  How do you think he came to that conclusion
when, as you point out, its so plain that my 'dislike is so profound'?  Strange
indeed.  I suppose this and other odd behavior is why I named him as a
co-conspirator, and asked the IESG to take action against him.

However, there is a different characterization of my objection:  Active drafts
shouldn't contain scientifically fraudulent claims.  The inclusion of this
fraudulent claim to your new draft while the GROW draft is disputed for this
very reason, seems to be more evidence of mis-behavior on your part, and also
reflects on your (already named in IESG Appeal)  co-conspirators.  And perhaps
on the person who added this draft to the ID-tracker. Who was that? (you didn't
answer my first request)

> Is there really new ground to cover, here?

No, not really anything new.  So why are you bringing up discredited claims
again?

> Unless anybody else here has a profound desire to see this circular thread
> continue, I think I will stop at this point.

I do agree this is a somewhat circular thread--in the sense that we've had this
dicussion before.  But I think you should have stopped at the GROW document...Or
probably before then.

                --Dean

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






.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

Reply via email to