On Mon, Nov 27, 2006 at 10:58:11AM +0100, Patrick Vande Walle <patrick@xxxxxxxxxxxxxx> wrote a message of 32 lines which said: > Add to that the current architecture does not allow competition at > the TLD level. There can only be one registry for any given TLD, > leading to artificial scarcity and lack of consumer choice. It is not artificial, it is the way it has to work. You cannot have multiple registries for one TLD, period. No more than you can have perpetual motion. Demonstration "ad absurdum": let's assume two registries R1 and R2 manage the namespace ".example". A customer C1 wants to create foobar.example and asks to registry R1. A customer C2 wants to create foobar.example and asks to registry R2. There is a conflict. You can solve the problems in various ways (see Emin Gun Sirer's message) but most of them create a "super-registry" on the top of R1 and R2 and you are back to the unique registry model. Other ways to solve the problem, without a super-registry, have other issues: * You can share the namespace, for instance, R1 has the right to names whose length is > N characters (this was proposed in the WSIS: ITU could manage names <= 2 and ICANN the rest). In essence, it makes several namespaces in ".example" so, again, you're back to the rule "One namespace, one registry". * You can give in the "non conflicts" rule. This is what happens to most "alternative inclusive roots". Ask your users how they feel about it. > A possible design is CoDNS > (http://www.cs.cornell.edu/people/egs/beehive/codons.php). CoDoNS, CoDNS is a different thing. It is interesting to see that the CoDoNS guy at the OARC 2006 meeting emphasized exactly the opposite, so I believe you expect from CoDoNS more than what they even promise :-) http://public.oarci.net/files/workshop-2006/Sukhar-P2PDNS.pdf "CoDoNS serves the exact same namespace with the exact same interface." He added "CoDoNS is just a resolver". _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf