David and all,
David R. Conrad wrote:
> Roeland,
>
> > Such a TLD, operating as an expression and implementation of a
> > trademark, has sufficient standing, in court, to tell the root-
> > server operators which name servers it can point to, for resolution
> > of that TLD, and enforce this with court orders as needed.
>
> There are root servers in Japan, England, and Sweden. Court orders from
> those countries (assuming the courts deem TLDs as trademarks something
> worthwhile to issue a court order over) would likely not impact
> operation of root servers in the US.
True enough David, but it would change the virtual landscape a bit should
additional gTLD's be added to those Roots.
>
>
> Oh, you meant court orders in the US.
>
> Well, all you really need is a court order ordering one root nameserver
> ("a") operator (NSI) to insert particular records into its zone, the
> rest (being slaved off "a") will simply copy the new delegations in due
> time. I'd note, however, that NSI seems to have a particularly large
> legal staff. Could be a challenge.
The size of a companies legal staff is mostly smoke, not substance,
unless they decide to disobey a court order of course, which is both
doubtful and could be very dangerous in several ways to NSI. The
expression that come immediately to mind is "Soap on a rope is a good
item to be well stocked up on in these instances".
>
>
> The court order is probably more appropriately directed at the
> organization that defines what goes into the root zone, namely ICANN
> (besides, they have a smaller legal budget).
I believe that NSI and the USG will be determining what goes into
"A" root in the short run. ICANN/IANA may advise, but as in the past
with the IANA and the gTLD-MoU bunch it i unlikely that NSI, whom
currently "Operates" the "A" root is going to taking any advice from
ICANN directly. As to ICANN's legal budget, I believe their total
budget currently is something around the $600k range, hardly a significant
budget, and certainly not imposing. >;)
>
>
> > the root-server operators do NOT delegate authority for a TLD,
> > rather the reverse is true.
>
> Of course not. Root nameserver operators simply secondary a primary
> whose contents are defined by the IANA nee ICANN.
Very true David, however as I have pointed out to you before, there
are ways legally around that scenario as well. SROOTS and BindPlus
make this very simple to do as Jon Postel once spoke to me very concerningly
about....
>
>
> > It now becomes non-hierarchical.
>
> (minor technical nit: this is, of course, non-scalable).
Interesting conclusion David. What is your definitive evidence to support
this dubious conclusion, pray tell? Hummmm? >;)
>
>
> Unfortunately for your theory (hypothesis? proposal?), the DNS actually
> is hierarchical. With a single root (if you want a coherent
> namespace).
Given your qualifier terms here you are of course correct. However
given a change in there being more than a single Root, which will happen,
there will than be a virtual Root structure extended out of a hierarchical
one, and thereby providing more redundancy as well as selection, which
by definition provides a much more coherent Namespace.
> It was designed that way. It is implemented that way.
> Arguing legalisms won't change this anymore than a state government can
> redefine pi = 4.
Nice false comparison here Dave. >;) Quite funny as a matter of fact.
>
>
> > In fact, since the various root-servers are operated by different
> > legal entities, each entity would have to be authorized/licensed to
> > allow them to resolve to the protected TLD.
>
> ISC operates "f". We slave off "a" like all other root nameservers --
> we don't actually ever look at the contents of the zone file, we merely
> insure "f" operates smoothly. Change "a" and the change will be
> propagated automatically to all other roots in due time. Suggesting the
> individual root nameserver operators license something so delegation
> records can be inserted into the root zone file is ... bizarre, tending
> towards silly. Root nameserver operators don't touch the zone file any
> more than a 411 operator mangles the database that phone books are
> generated from. A person unhappy that they can't get their telephone
> number into a phone book is going to sue to force the _operator_ to
> update the database? As my lawyer would say "this doesn't pass the
> giggle test".
Ahhhhh David, as Gerry Spence, a much more authoritative
source to be sure, this (Your) denigrating and completely false analysis
wont pass the sanity test.
I am surprised that Paul would continue to allow you to make such
a total idiot out of yourself, like this, as it reflects so badly on ISC...
>
>
> > For example, were m.root-servers.net to start resolving WEB,
> > under IOD license, independent of the other root-servers,
> > there is nothing that ICANN could do about it.
>
> Sure they could -- they could transfer "m" to somebody else. With the
> exception of USG/NSI cooperative agreements, there is no contractual
> obligation binding any of the parties involved in providing root
> nameservice. ICANN could (theoretically) change any/all of the root
> nameservers (with the exception of "a") at any time and I would imagine
> if one of the root nameserver operators went rogue and started to
> contravene existing policy, they most likely would.
We may get to test this theory David. But I wouldn't if I were you
make book on your conclusion, especially given legal agreements
currently in place along these lines.... Again, your supposition is
bold, bu likely not valid or wise.
>
>
> Of course, the folks at WIDE wouldn't do such a silly thing, there is no
> incentive for them to do this and it would make their lives quite
> painful if they tried. If nothing else, they'd be setting themselves up
> to modify their copy of the root zone for every loon who decides they
> want to run a TLD at the same time as having to keep in sync with the
> real root zone. Oh yeah, and some percentage of the Internet would
> start getting different answers than the rest of the Internet (but I
> gather having a coherent namespace isn't particularly important to you).
Yet again you conclusion here on your scenario borders on insane.
>
>
> > It is an interesting point that, according to my research thus far,
> > dot (".") can NOT be trademarked because it is an implementation
> > mechanism, that is part of BIND,
>
> Not a part of BIND, but rather a part of the DNS. BIND is merely one
> implementation of the (increasingly complicated) suite of protocols
> known as the DNS.
Very true indeed.
>
>
> > This is crucial, because it allows the existance of multiple
> > roots.
>
> Nothing has ever stopped the existance of multiple roots, and in fact,
> there are innumerable roots already in existance behind firewalls or
> BIND 8.* split DNS configurations. Whether a particular delegation is
> made within a root (or non-root) nameserver (primary) is a question of
> policy defined by the people who operate the primary. In the case of
> the Internet DNS namespace (as opposed to intranet namespaces), the
> policy has been "the IANA decides", with the operators of "a" following
> the IANA's requests. As ICANN now subsumes IANA functionality, the
> policy is "ICANN decides" (well, sort of -- it is actually any of ICANN,
> IANA, or Dept. of Commerce).
You know Dave, you really should stay away from those mind altering drugs,
as this conclusion graphically indicates in the extreme. Such a conclusion
is not only not in effect, but is based on false premise as well.
>
>
> Anyone who runs a DNS server is free to point to whatever root
> nameservers they like -- in the case of BIND, all it takes is editing a
> text file. However, if you want to see a coherent namespace, it is best
> if you leave the text file alone...
What is coherent is a matter of conjecture to be sure, as many recent
discussions and court cases have made abundantly clear over the past
few years. To be sure what we have now is certainly arguable as to it's
coherency.
>
>
> Regards,
> -drc
Regards,
--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [EMAIL PROTECTED]
Contact Number: 972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
