[SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... >May I remind you that this is the Internet _Engineering_ Task Force. The >IETF's task is to propose and implement technical solutions for the >Internet. Political arguments on meta designs such as who should control >the Top Level Domain(s) or why some organisation with an amusing acronym >should not be in control, whilst an amusing and non-productive way to >wile away an afternoon, should not be part of the IETF discussions. > >Alternative Roots are just that, Alternatives, or more accurately, amusing >Non-Portable Fragmented Extensions of the Current Root. > >- -- > Bruce Campbell. My opinions are my own. [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... I think it is time for a little adjustment of the semantics of this discussion. There are no "Alternate" roots, in spite of many who persist in using the term as a wedge issue to prevent meaningful discussion. ORSC is not an alternative in the normal sense of that word, which is that one must choose A, or B, but not both. To the contrary, ORSC is Inclusive, by careful policy design. Users of ORSC root servers have access to ICANN TLDs Plus ORSC TLDs. So, your choice is between an Exclusive root (ICANN), or an Inclusive Root (ORSC). In fact, every computer system user with root privileges has the power to select in the privacy of his or her own bedroom, which root service to use. This is in the DNS standards specifications, and is going to be very hard to either remove, or unilaterally override, or to simply ignore. Of course, ORSC, will be called an "alternative" root by those who do not want conflict problems resolved, for reasons that we can only speculate about, and speculation is no longer useful here, so I will not speculate. The fact of being stalled is clear enough without speculating about why or how we got here. Obfuscation is not going to lead to any useful results! We must clean up our use of our language if any progress is to be made. In an ideal world, the inclusive root would not have any collisions because the root service operators and the TLD applicants would talk with each other to sort out the issues and resolve all the conflicts. But, in the real world, if the Exclusive Root Service has no incentives to talk to the Inclusive Root service, then the Inclusive Root service has no way to deal with cases where the Exclusive Root Service simply barges into a collision without affording any way to resolve the injuries and damages thus caused, either before or after the colliding TLD is/was actually mounted. It is exactly like trying to sleep with an Elephant. The elephant might not be malevolent, but it is going to be really hard to get any sleep. Such is the case for the relationship between ICANN and ORSC at this point. The Exclusive Root Service refuses to accept that there is anything to discuss with anyone when they decide to award a new franchise to any new TLD registry bidder, when the new Exclusive Root TLD conflicts with an existing Inclusive Root Service TLD. This is the case even after due notice has been given in advance to the Exclusive Root Service Board of Directors. In fact, in the .BIZ case in hand, the already operating (since 1996) .BIZ TLD registry also submitted an application at a non-refundable cost of $50,000, just to be considered, so it is very hard to see how this collision could have been an accident. I will not speculate about any motives. So, here we are, stuck in a situation where there is no way out short of the two parties actually discussing the issues and seeking some kind of mutually acceptable resolution. This process is normally called "Coordination"; without which it is going to be exceedingly difficult to coordinate future TLD delegations by the Exclusive Root Service. By proceeding with blinders on (i.e., DWB: Driving While Blind), the Exclusive Root Service is in fact destabilizing the net when its given mission is supposedly to stabilize the net. In the midst of all the hoopla surrounding these issues, this case is the only really serious unresolvable conflict collision problem to have arisen since 1996. So, the (ORSC) Inclusive Root Service's primary request of the Exclusive Root Service, is to be fairly considered and to be allowed to sit down and have a rational discussion about how to resolve the difficulties with conflicts, and resolve this (.BIZ) conflict in particular. In short, the ORSC request it to engage is some useful coordination. Why coordination is not allowed is left as an exercise for the readers;-)... ORSC (the Inclusive Root Service) has done a very good job over the last 4-5 years of coordinating the Inclusive Root Zone and resolving conflicts, until the Exclusive Root Zone control agency unilaterally created a collision and refuses to acknowledge the fact of it. Our policy is simple and clear. ORSC will not admit any new TLD registry if there is any outstanding claim by another party to the same TLD name. This policy derives from clear text in RFC-1591, under which the disputed TLD was granted permission to proceed to mount .BIZ in 1996. It has survived until now. So, the Inclusive Root Service (ORSC), which has honored that first deployment of .BIZ from its establishment, considers that the .BIZ rights have been trespassed, and that there exist solid grounds for at least engaging in discussions. .BIZ was established next after .WEB, which was given due consideration for it's existence, but was denied entry into the Exclusive Root Service. I, and ORSC, make no claims as to how the .BIZ situation might be resolved. Our only claim is for the right to a fair and honest discussion of the facts and an honest effort to find a resolution. When completed, we will have seriously tried to find an acceptable resolution to all the outstanding issues in the conflicted situation. There are no technical issues involved in this situation, other than the technical fact that a collision with two .BIZ TLD registries with colliding SLD entries causes trouble for the current DNS operations of both root services and both .BIZ registries and all .BIZ registrants, and the appropriate way to resolve the collision cause is to discuss it among the contending parties. The ORSC policy rule (ala RFC 1591) would be that without the two contending TLD Registry operators agreeing to a settlement that reduces the conflict to a single contender, neither can be entered in either (or any) root service. The details of this need to be resolved by the two contending TLD registry applicants. Melding the two registries is a problem that they two registries should figure out. Any form of accepted mutual resolution should be acceptable. If ICANN had set this rule in place when approving their .BIZ candidate, I am certain that a settlement would have been found post haste. And still could be found post haste if ICANN will agree to proceed with coordinative discussions. So far ICANN denies all knowledge of any of the facts; While ORSC stands ready to engage in finding a resolution between the contending registry applicants. Without ICANN engagement, the ICANN delegate has no incentive to settle any differences. Tennis anyone;-)...\Stef