Re: Root Anycast

At 18:12 19/05/04, Kurt Erik Lindqvist wrote:
> > - I talk of real world when you talk of the current (unsecure and
> > overloaded?) implementation of the current DNS architecture.
>
> In what way overloaded? Do you have any pointers? Proof? Data?
Dear Kurt Eric,
Let not play this, please. Either you think after careful personal study 
(or you believe) that the current system is the best solution the world 
needs, and that it only calls for some users to be more educated in using 
it - and we are on planets apart. This is fine with me, and the end of a 
non existing debate.
Or you think the DNS does not match the IETF "core values" in being 
centralized (I do not make that "core value" as described by Harald a 
creed, I think they are often outdated, but I fully agree they are a 
technical minimum). And, together with ICANN, you think IETF is the right 
place to respond ICANN's call for more (ICP-3). So you try to understand 
the problem and to imagine solutions. This is what we did. And I explain 
the solutions we are subsequently working on.
> > The problem we face is an old and too large unique system with a
> > robust yet overloaded engine. With all the problems which come with
> > it. We have to split the zones of usage and risks. Either it is
> > planned by IETF or it is done by the users. I suggest it is done
> > together.
>
> Again, overloaded engine in what way?
I just report on our follow up on this premise. If you do not see it, I 
cannot help with details. Just with the alternative. Yu are the judge.
The DNS "engine" is made of all the root/name servers and resolvers.
- either you are satisfied with their present tools, organization, 
limitations and resulting service, then again I cannot discuss it.
- or you are not, and then the question is to know if your disatisfaction 
results from the used solution or from the way this solution is implemented.
IMO the problem is not with the solution (software) but with its 
architectural deployment and usage. This permits a smooth transition, using 
existing and proven building blocks and expertise. But I think that speed 
if the essence. One may also disagree.
> > Then the agreed file
> Agreed by whom?  In what way?
Let me elaborate quickly. The target is not to obtain a file which pleases 
anyone as today, but a file which reports on the TLD Managers entries. So, 
the point is not who does it but the number of identical independent 
results. What follows is for one single national service.
- National because of the legal and political aspects in many aspects (risk 
containment, sensitive information intelligence leaks, justice obligations, 
etc.).
- But subsidiarity applies to the regional, local, corporate, private 
granularities (I explained what this means in my first mail).
- this means that security and verification will probably repeated 20 to 50 
times accross the world. Once a day in each country could mean every hour 
for global issues such as the DNS (the protocol is the same for every root 
information [time, radio frequencies, weather, hospital situation, etc])
The process we retained is to have at least four different independent data 
collection processes (whatever the processes, starting with a simple 
duplication of the NTIA file in the case of the DNS legacy root). The 
reason for at least 4 is to have at a majority if needed, even if one is down.
There must be five conditions for the result to be accepted (there could be 
more?)
1. there must be no reported alarm (nominal situation) on our monitoring system
2. all the results must be identical
3. there must not be an abnormally large difference with preceding copy 
(variance max to be tuned from experience) - to allow reasonable updates if 
permitted.
4. visual review by the four collection managers is positive
5. there must be no significant (similar to 3) with other partenering root 
files on common part of the root matrix.
If these 5 conditions are not met there will be an investigation and 
concerted agreement to be reached among collection managers, or a "no go" 
and escalation to Execom and to BoD (or Gov). These conditions (or more) 
can be made legal and imposed before a State endorses a Root Service for 
its own use and for legal transactions.
There is a possible alternative: the decision of the Government in case of 
national vital crisis. The role of the collection managers will be to 
advise how to reduce pollution in such cases - this may call for 
international concertation [exemple: the "ambassador lounge" at ITU 
(telephone is real time, no 48 hours delay). A doctrine is to be set-up as 
part of Digital Warfare (US say Cybernetic Warfare). Experience in Mines, 
Electronic or Nuclear Warfares shows this is possible.
> > You want to reduce the calls to your system, right? Let stop the
> > "cache" idea which is something of _your_ system ibn theirs, and
> > propose them an update of _their_ system - like anti-virus updates
> > (ever heard that anti-virus run huge 50x1G systems? And let discover
> > what a user system can bring more to its user owner. So when the user
> > has started using and enjoying _his_ system, you will obtain what you
> > want.
>
> Why would I want to reduce the number of calls on my system? My system  is 
> doing just fine...
What is your system ?

In the case discussed the problem is the current increasing load on current 
servers. That load and that type of calls are inappropriate. The 
architecture is to be changed (all the more than it permits DoS). Keeping 
daily updated files of much larger size than the root file is carried by 
many people around the world more efficiently, more securely and with less 
of constraints to innovative usages.
But again, the very nature of the DNS permits such transition to be 
transparent. So if you love the current architecture, it is OK with me. As 
long as you do not pollute what we do and we do not pollute what you do 
there is no problem. This discussion only concerns those (with ICANN ICP-3) 
who want to experiment and work on the resulting experience, towards a 
better response to the people and Gov demands.
I just describe what we have started working on, with scarce resources, 
along those lines for more than two years. And what we target from then on.
jfc



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