<html>

<body>

Dear Francis,<br>

I am not sure I follow everything here.<br><br>

At 22:31 21/09/2009, Dr. Francis MUGUET wrote:<br>

<blockquote type=cite class=cite cite="">DearĀ  Jeffrey, dear all

<br>

<blockquote type=cite class=cite cite="">

<blockquote type=cite class=cite cite=""><pre>And things in the RFC that

have not yet been implemented and tried may  

or may not work.

</blockquote>Many don't initially and as such require and are updated

accordingly. 

</pre><font face="Courier New, Courier"></font></blockquote>

exactly,Ā  the DNS soft need update to fully implement the

<a href="http://tools.ietf.org/html/rfc5395"><b>RFC 5395</a> </b>( old

2929Ā  easier to remenber ) <br>

and test if the update works, but this is a not breathtaking effort...

there is no conceptual difficulty in programming, <br>

Ā a fixed parameter becomes a variable as it should have been in the

first place. </blockquote><br>

What do you mean by "DNS soft", there are many DNS programs.

All of them should support classes.<br><br>

<blockquote type=cite class=cite cite="">

<blockquote type=cite class=cite cite="">

<blockquote type=cite class=cite cite=""><pre>and how many DNS

implementations would need to be updated?

as for

<a href="http://www.icann.org/en/meetings/stockholm/unique-root-draft.htm">

http://www.icann.org/en/meetings/stockholm/unique-root-draft.htm</a>

The problem here is that was just an assumption, but when people  

started looking at doing it, they started to find all the reasons

why  

it would be very

difficult.</pre><font face="Courier New, Courier"></font></blockquote><br>

<pre>Wrong.  It's not difficult at all.  What is difficult is

cooperation

of the legacy root structure to other and newer existing and future

root structures.  

</pre><font face="Courier New, Courier"></font></blockquote>exactly,<br>

the key point would be who is going to be the trusted authority<br>

to store the "cache"Ā  currently InterNIC<br>

<a href="http://www.internic.net/zones/named.root">

http://www.internic.net/zones/named.root</a><br>

for all the <i>classes</i>,Ā  so that DNS servers software may be

updated whenĀ  there are new <i>classes</i> createdĀ  and

updateĀ  onĀ  root servers of existing

<i>classes</i>..</blockquote><br>

There are several manners to implement classes, and many reasons why.

Hoever, classes are tied to domain names as well as domain names to

classes. You cannot decide to create a new root file with .com in a new

class and not to be sure that the ICANN root will not support that class

too. But if you create a new root that uses a new group (TLDs) and you

get successful, ICANN cannot stop you to become a real competition. There

is nothing special in a root file, except the use people make of it and

the trust they have in it. Progressively complexity, e-empowerment, and

security issues will make that people will only eventually use their own

root.<br><br>

Domain names, classes, groups and presentations are way to sort the same

names into different sub-spaces with or without the same ties. So

actually the root we currently use is a one dimmension matrix, but

actually the root matrix is number of TLD x number of classes and the

user space is still to be multiplied by the number of supported

presentations.<br><br>

This complexity is practically un-centralisable. Because by essence

everyone can decide of the picture he will actually use. The whole system

is only based upon the people acceptance of the ICANN, while ICANN does

not really care about what people really need. <br><br>

jfc<br>

</body>

</html>