Re: Root Anycast

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


We must be talking about two different Internets.

- - kurtis -

On 2004-05-19, at 21.46, jfcm wrote:

> 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
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQKy+CaarNKXTPFCVEQItNACfcM5bSRoC0Xvatk0UnhbCukQuryMAoJr1
7/tT51H4rs0t9JKdmq62a0Ga
=aiJ1
-----END PGP SIGNATURE-----


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