On Fri, 23 Jun 2006, Joe Abley wrote:
> Hi Dean!
>
> 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.
> Further comments on draft-ietf-grow-anycast should properly be directed to the
> grow mailing list, where I will be happy to contribute if I can add value to
> the discussion. I won't continue discussing them on dnsop, however.
You do not need to discuss the matter if you agree to remove the references.
Otherwise, its part of the content of the draft on this working group.
> On 23-Jun-2006, at 15:47, Dean Anderson wrote:
>
> > On Wed, 21 Jun 2006, Joe Abley wrote:
> >
> >> draft-jabley-as112-ops-00
> >
> > In section 3.1, this text should be removed:
> >
> > o Anycast distribution of DNS services ([ISC-TN-2003-1], [I-
> > D.ietf-
> > grow-anycast]).
> >
> > 1) draft-ietf-grow-anycast is based on a known scientific fraud, and is
> > currently under appeal to the IESG for several inappropriate acts.
> > References to known scientific frauds should be removed.
>
> I'm not familiar with precisely what you have appealed against;
I think you are, or ought to be, being on the GROW WG, and author of the draft
appealed, since this was discussed on the GROW WG, and is documented on the IESG
Appeals page.
> for example, it's my impression that you sent a formal appeal to the IESG
> complaining about a decision that they had not yet made, since the last call
> was still in process, as were the Secdir and Gen-ART reviews.
No, your impression is incorrect. But you can read that in the Appeal.
> Feedback from those reviews has resulted in a -04 draft, which is not yet in
> the i-d queue. Since you haven't seen that draft, your confidence in being
> able to criticise it is puzzling.
I have not made any criticism of the "secret" -04 draft. However, since the
notion of stateful anycast is itself a fraud, it seems impossible that you can
fix the GROW draft. I look forward to seeing the -04 draft, however, and
whatever new complaints arise from it.
> I think the most appropriate thing for now with respect to draft-
> jabley-as112-ops is to leave the reference in place, since it's
> currently the only non-expired document in the IETF which comes close
> to explaining current practice. If it comes to pass in the future
> that the IESG decides not to proceed with draft-ietf-grow-anycast,
> then the reference can be modified or removed as appropriate.
I strongly disagree. The GROW document doesn't explain any current practice
whatsoever. Its entirely based on fraudulent claims and fictions.
> > 2) draft-ietf-grow-anycast documents stateful anycast.
>
> It does describe the anycast distribution of services whose protocols
> involve keeping state. It also documents the anycast distribution of
> stateless services.
The notion of stateful anycast is a fiction.
There is no documentation of stateless anycast in the document that isn't also
contained in RFC1546.
> > Stateful isn't required
> > or used for AS112 operations. AS112 is a stateless operation.
>
> Since AS112 servers answer queries over TCP transport, that's not
> correct.
>
> [octopus:~]% dig @prisoner.iana.org 10.in-addr.arpa soa +tcp +short
> as112.ixnm.net. info.ixnm.net. 2003030100 3600 600 2592000 15
> [octopus:~]%
This isn't a real test of stateful anycast, as you well know.
> > Stateful queries can be dropped. (probably all queries could be
> > dropped)
>
> Operational indicates that such practice has a real impact on production
> services. Regardless of the fact that such services could feasibly be
> described as broken, depending as they do on public authority servers for
> private netblocks to exist and function correctly, any decision which causes
> production services to fail should not be taken lightly.
The purpose of AS112 is to stop otherwise undelegated queries from loading down
in-addr.arpa, .arpa, and ultimately reaching root nameservers. They do not need
actual responses to achieve this goal. All that is necessary are delgation
records, and quickly blackholed IP addresses for the delegated nameservers.
Nameserver software isn't even required.
> > Reference to RFC1546 stateless anycast should be made instead.
>
> Your opinion on this matter is noted!
Thanks. Look for to seeing that in the document.
--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
