karl wrote:
...
ICANN's job is not to make decisions in secret, by unknown members of
"staff", based on unknown criteria and using unknown assumptions. ...
that sentence is punctuated incorrectly. there's a period after "decisions."
... so, which is what you are saying has been done, is simply yet another
abandonment of ICANN's obligations.
i think there's a tense problem here. icann cannot abandon that which it
never had. perhaps a pretense was abandoned, but not an actual obligation.
The switch to anycast for root servers is a good thing.
again there's a tense problem. there was no "switch to" anycast. the last
time those thirteen (or eight) ip addresses were each served by a single host
in a single location was some time in the early 1990's.
But it was hardly
without risks. For example, do we really fully comprehend the dynamics of
anycast should there be a large scale disturbance to routing on the order
of 9/11?
yes, actually, we do. (or at least the f-root operator does.)
Could the machinery that damps rapid swings of routes turn out
to create blacked out areas of the net in which some portion of the root
servers become invisible for several hours?
nope. or at least, that risk is unchanged from the multihomed servers that
have actual backhaul between their points of presense. (those of you who
are bgp-aware all know that there is no way to tell the difference between
a robustly multihomed network and a robustly anycasted network.) if karl
is going to start worrying about flapdamping, he's late to the party, and
the things to worry about aren't all or even mostly anycasted.
Could one introduce bogus
routing information into the net and drag some portion of resolvers to
bogus root servers?
of course! but then that was always true and will always be true. the only
fix to it is some form of secure BGP which i guess means route-signing and
route-verification and oh my what a mess that turns into very quickly. and
the affected ("at risk") elements are, again, overwhelmingly NOT anycasted.
I'm pretty sure that the root server operators have answers to these
questions. However, it is incumbent on ICANN not to simply accept that
these people know what they are doing; ICANN must document it, ICANN must
inquire whether some of the decisions are made on public-policy
assumptions (in which case "the public" needs to become a party to those
decisions).
that's an interesting view. i'm not sure i don't share it! but that's not
how things work now, or how things have ever worked, and i'm shocked that
karl of all people would want to see ICANN's mission "creep" in this way.
Considering that we know that there would be no ill effects to adding
even a hundred new top level domains, one has to wonder at the degree of
automatic deference (deference amounting to an institutional decision to
be blind) to the deployment of anycast as compared to the hyper detailed
inquiry into matters even as irrelevant as the pronouncability in English
of a few proposed new top level domains.
well, in my role as a root operator i don't care about content either way,
and even as an internet citizen i don't have strong views about adding TLDs
(beyond what i wrote in http://sa.vix.com/~vixie/bad-dns-paper.pdf that is).
but i can tell the difference between a user-visible change that will affect
the internet's financial and information economy, such as adding TLD's, as
opposied to an operator-visible change that users won't even notice and
which creates no new business opportunities.
one of those, and i really do mean only one of them, is in ICANN's ballywick.
In addition, an argument could well be made that anycast violates the
end-to-end principle. For instance, it's hard, or impossible, to
maintain a TCP connection that spans a routing change that sunsets one
anycast partner and sunrises another.
i suspect that concerns of this kind were the main reason why the rootops
waited to see several years of results from nominum's and ultradns's use of
dns anycast before doing widescale anycast. in fact, one concern learned
by watching nominum and ultradns led to the namespace piracy known as either
HOSTNAME.BIND or ID.SERVER (depending on the age of the software). all of
this was in class CHAOS of course. but widescale anycast would have been
impractical without this extension.
as to karl's end-to-end argument, anyone using a hash-based load balancer,
including Stupid OSPF Tricks, for local load balancing would be subject to
the same issues. it is therefore very notable that DNS TCP sessions are
short-lived, and that the "end" can change identities with radically high
frequencies, and there is no observed impact on network load or likelihood
of retrieving a correct and useful answer.
...
But you miss the point - the deployment of anycast for root servers was a
bold operational decision. It was a decision made by the root server
operators alone, without ICANN.
the implied social contract for ISC as a "volunteer" rootop is that we will
serve the data, the whole data, and only the data provided to us by IANA,
and that we will use our (considerable) best efforts to serve it to the
greatest possible number of DNS initiators with the lowest latency and
lowest error rate we can arrange. this is all the original IANA asked of
us, and the current IANA has not (yet?) complained about our performance.
whether it's done with anycast, or with smoke signals, or with one's
complement vs. two's complement arithmetic, is a purely local affair.
ICANN's obligation is to guarantee to the public the stability of DNS at
the root layer.
i disagree...
ICANN's failure to engage in the issue of anycast
deployment was simply and clearly and abandonment of ICANN's
responsibilities.
...which makes this statement, to me, a nonsequitur.
Anycast may even have preceded the creation of ICANN
Yes, anycast has been around for a long time. Multicast, NATs, and OSI
all also preceded the creation of ICANN. But does that mean that ICANN
should freely and and without question allow the deployment of those
technologies for DNS root servers?
use of anycast for root name service did indeed predate ICANN's existence.
I have serious doubts that ICANN will be able to meet its obligations
under the most recent terms of the oft-amended Memorandum of Understanding
between ICANN and the Department of Commerce. I see no sign that the DNS
root server operators or the RIRs are going to allow themselves to become
dependencies of ICANN and to allow their decisions to be superseded by
decisions of ICANN's Board of Directors.
they don't need to become "dependencies" for this process to work
indeed not.
Either ICANN has the final authority to dictate decisions to the root
server operators and RIRs or it does not. If ICANN does not then ICANN
has simply abandoned its responsibilities to the root server operators
and the RIRs.
this kind of black-and-white analysis is too truncative of information to
give us any insight. if ICANN could not get what it wanted from a rootop
then it would have recourse, called "redelegation". this would be a last
resort and very expensive for all parties concerned. but there's recourse,
even if it's probably not what you mean by "final authority." there is no
final authority in the sense that i think you mean, and can never be. (does
karl think anyone outside china has final authority over what Google will
show as its results to chinese web users when taiwan is involved? and
that's just for starters..)
"Coordination" is a weasel word.
coordination is as good as it gets, and anyone who has a god ought to pray
that we can get it and keep on getting more of it.
Either ICANN has the authority to
make a guarantee of internet stability to the community of internet users
or it does not.
that is a false dichotomy. on the internet there can be no dictatorship
since anyone who wants to dig their own sandbox can just go out and do that.
therefore coordination and voluntary participation is really all we can ever
hope for, and i sit here right now, hoping for it, and hoping for more of it.
As I read your comments you seem to be saying that ICANN
does not have that authority. If that is the case, I can only ask, why
should be have an ICANN if it is simply a toothless bureaucracy whose job
is simply to stand by and let other more competent bodies made final
decisions.
"tooth" is a contextual term. there is much good that ICANN can do, but it
will never be the "authority" karl seems to be envisioning here.
...
ICANN can be merely a "coordinator" if it wants. But to do so it needs to
stop trying to deceive the public that it is a player and start being
truthful that its role is merely that of a cheerleader.
that's a straw man argument. coordination is not a definitionally toothless
activity. consider the IEEE802 48-bit address space. i don't think the
coordinating body would sue a manufacturer who started minting their own
prefixes, and in that sense there is no "final authority." however, the
coordinator's will would reign supreme in the long run, even without the
"authority" karl seems to be questing for.
Harry Truman was famous for his desk plaque that said "The buck stops
here." But in the land of ICANN it is clear that the ultimate
responsibility is not ledged in ICANN; it is in the hands, good will, and
expertise of the root server operators and the RIRs. At the present time
those hands are competent, the will is good, and the expertise great.
But in the absence of clear ultimate authority in ICANN, things could
change leaving the internet community vulnerable and without protection.
i guess what karl has shown here is that on the internet there is no buck
or that it doesn't stop anywhere or some combination thereof.
--
Paul Vixie