Re: Root Anycast

Dear Paul,
pardon me for the previous response. I could not resist!
This post of yours is a very important one as it expresses, from experience 
and in IETF wording, what I try to convey from another origin, experience, 
modelization, architectural logic and culture.
At 02:16 18/05/04, Paul Vixie wrote:
> The table is round.  Policies are discussed as a group but set individually.
> The result is a service which has never been "down hard", not ever, not for
> any millisecond out of the last 15 years.  This is "strength by diversity."
This is exactly what French and now Eurospeak call "concertation". The very 
basis of the emerging European Constitutional culture based upon 
subsidiarity and granularity. Another less confusing word for English 
speakers, less related to French specific thinking, and corresponding to 
the level of the concerned issue is "intergovernance".
> Careful design by whom?  Organic compared to what?  I assure you that f-root
> has grown by careful design.  It's only organic in that we go where we're
> invited rather than having a gigantic budget that could be used as a leash.
This is what we call subisdiarity. To actively (helping when needed) 
respect the responsibilities of those depending on (not from) you. I am 
sure that as F-Root Manager you do not mess within your mirror sites 
management, but are always ready to help on need.
> Check out <http://www.isc.org/ops/f-root/> and the list of mirror sites, and
> look for some sponsors you know, and call them, and ask why they sponsored
> f-root and whether they're happy about it.  Then find someone in that region
> and ask them to do "dig @192.5.5.241 hostname.bind chaos txt" and tell you
> whether they're talking to a local f-root.  What could scale better, or
> allocate resources more efficiently?  (Central planning didn't help USSR.)
Right. The only problem "we" (myself to start with, but also several Gov 
such as Brazil, India, China, etc. etc. as expressed at WSIS and many many 
others) have is that if Root servers are not centraly planned, they 
broadcast the same centraly planed and edited file. Also that this central 
editing imposes constraints due to the 13 limitation. Apart from the 
political issue, this makes that file and the a-root a world economy, life, 
security, single points of failure. This is something that the "we" quoted 
above do not accept.
> Who is "we", though?  That's always the excluded middle of this debate.  I
> know who I am -- a root operator.  But who are "we"?  And which of the
> million different answers to "who are 'we'?" would you like to see govern
> the choice of "who gets to decide how this stuff ought to work?"  E.g., I'm
> sure, without even having heard it, that you wouldn't want the choice of
> "who decides?" governed by Dean Anderson's answer to "who are 'we'?"
There is a very good response to that. RFC 883. It says "we" are the users, 
in saying that no one will be forced to use DNS data he did not chose. It 
seems a realistic simple way to make the table totally round (or at least 
rounder): if no one ask for more than the today situation, it is OK. If 
some ask for more, let them do it. ICANN ICP-3 gives pretty good and 
reasonable rules about their experimentation and implementation constraints.
> In counterpoint, it seems to me that any unified design will make the system
> subject to monoculture attacks or ISO-L9 capture, and that the current
> system which you call "unplanned and organic" (but which is actually just
> "diversity by credo") yields a stronger system overall.
Here is where I disagree: with the "core value" reading (cf. IETF 
description draft by Harald). You are right about what you say. But this is 
not to be a creed. This is to be architectural efficiency. This is pure 
cybernetics - cynernetics as the technical science of autonomous systems 
(where mathematics are for abstract systems and physics for inert systems). 
This would probably permit you to agree with Dean on a conceivable common 
framework where his concerns and your preriquisites would be addressed.
> If you'd like to unify something, perhaps it could be DNS client behaviour
> and network-owner recursive caching forwarder design.  And while you're at
> it, please outlaw those fiendish DNS-based load balancers.  f-root should
> still be a 486DX2-66 like it was in ~1995, rather than fifty 1GHz pentiums,
> and the 500X load 10 years later is due to client stupidity, not population
> growth or backbone speed increases.
You are damned right! This is exactly what we try to build right now with 
the AFRAC project (the DNS root is _not_ the only one concerned, both as a 
root reference and in the way it is used or can be denied service). We are 
concerned by DNS, adressing, etc. data, but also by geosocietal and defense 
information: every information and source code necessary for tier and tier 
applications (everyone interoperating)
1. first target: distribution of the root machines through a root server 
matrix and core network - containing local root information to make it a 
need. Decrease of the pressure, risk containement, new data, new services.
2. second target : a user MITM providing "hardware, software and brainware 
firewalling". At root system level it means that the user is to cache his 
root system. The reason why he will do it is that his root system will 
_not_ be the default public root system. It will be his own version of it, 
adding his local, private space management and views. Once set-up, calling 
on the root system would actually pollute his root system, so he will not 
do it.
Private roots are not subject to DoS. They certainly permit to survive a 
few hours, days and even probably months. In adding all the root themes we 
can objectively consider today for ubiquist new services, plus a "first 
necessity" software kit and root, we are probably talking of an ASN.1 
structure of less than 20 compacted K (comparable to anti-virus updates).
The figures I discussed in a previous memo, show that we could then come 
back to a "486DX2". However discussing of root server the way we consider 
them today would be quite meaningless.
jfc

PS. I do not consider here the problem of the loggers which is another 
(mainly legal) issue.









_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf