RE: [ga] November 13 GA meeting

[Roeland Meyer <rmeyer@mhsc.com>]

|> From: Jefsey Morfin [mailto:jefsey@wanadoo.fr]
|> Sent: Monday, October 01, 2001 8:02 AM
|> 
|> On 06:10 01/10/01, Michael Froomkin - U.Miami School of Law said:
|> >I believe the passivity is a sign of total demoralization.

Add exhaustion to that and I will agree. The ICANN power-clique is getting
pretty good at wearing out its opposition (those whom are not in that
power-clique).

|> Dear Michael,
|> you want the ICANN to survive to protect your business :-) 
|> !!! Could we see that another way?

ICANN threatens my business and that of my friends, rather than protect. The
trust isn't there.

|> Stuart's proposition is absurd and people feel or realize 
|> that. MdR will make plain that the ICANN is the Internet
|> security weakness: 

Only in that, they seek to bring under central authority, what should be
decentralized. The reason that the Internet was designed the way it is, is
precisely because that threat has always existed. A design that promotes
decentralization and eliminates as many potential choke-points as possible,
is the only means to combat that tendency. In that, the original designers
succeeded, very well. It helped that many, of my generation, were rabid
libertarians at the time. Alas, people change. At the time, people generally
didn't trust large central authorities, IMHO they still shouldn't. The
opportunities , for large scale abuse, are too great and varied. The current
generation is more complacent. 

Multiple decentralized and competing authorities are slightly more chaotic,
but better, in that, they keep each other honest by mutual policing. It
would be most excellent if they didn't trust each other any more then they
had to. If each country ran its own registry, independent of the others,
that would be a general improvement over the ICANN, IMHO. We would also
start seeing some meaningful dialog.

|> Now, there are real issues we can discuss - and we are 
|> starting doing it:
|> 
|> - urgent term solution about root servers:
|>   testing of a duplicate root server galaxies for ccTLDs

That is already being done, outside of ICANN. ICANN may not like it, but
that's life. It's the registry system that is the larger, non-trivial,
problem. Root zone server/cluster systems are only a delivery mechanism.

|> - serious coordination of the value 
|>   added/extended inclusive roots services

Long overdue and what, I thought, ICANN would do.

|> - action against TLD squatting, etc...  
|>   We cannot continue having 6 root servers out of 13 
|>   on the most dangerous spot of the planet toghether
|>   with  25.000.000 DNs on the same name server system
|>   and backup.

Not counting the official root-servers.net constellation, there is the
root-service.net constellation and others. Just one of them comprises many
more than 13 hosts.

|> - short term solution: the end of the root concept and a 
|>   more stable and open resolver system for all as per the
|>   1978 international public service naming plan.

Could you please mention URL's and document listing when you mention these
sorts of things? Are you refering to X.500?

|>   The root is updated once a month even less; 

I do this with my constellations now. It's a 100% automated process, using
out of band updating, via ssh/scp transfers. I publish 5 different root-zone
files, because each client has different local/private TLD zones.

|> - medium term solution: IPv6. The security weakness here is lack of 
|>   education and of debate.

There is even more weakness in that, IPv6 does not yet have a routing
solution. DNS wasn't developed until *after* the routing problems were
solved. On a theoretical basis, nameing and routing may no longer be
entirely seperable, but that still remains to be seen. Thus, far IPv4
mechansims have the traction. But, everyone knows that we need something
better. "Better" doesn't yet exist. IMHO, IPv6 isn't ready for prime-time
yet.

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html