| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Message-Id: <200111191613.fAJGDhgi008278@foo-bar-baz.cc.vt.edu>
To: Simon Higgs <simon@higgs.com>
Cc: nanog@merit.edu, bwg@dns.list
In-Reply-To: Your message of "Sun, 18 Nov 2001 17:56:44 PST."
<5.1.0.14.2.20011118170031.00aa1b30@oak.higgs.net>
From: Valdis.Kletnieks@vt.edu
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1710390537P";
micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Mon, 19 Nov 2001 11:13:43 -0500
Errors-To: owner-nanog-outgoing@merit.edu
--==_Exmh_1710390537P
Content-Type: text/plain; charset=us-ascii
On Sun, 18 Nov 2001 17:56:44 PST, Simon Higgs said:
> prevail and that running code and rough consensus demands the peering of
> non-conflicting TLDs for everyone's benefit. It's a common practise in
Hmm.. "non-conflicting". Let's think about this for a moment.
Let's assume we have 3 TLD managment groups called A, B, and C. In order
for there to be non-conflicting roots, A, B, and C have to enter into some
sort of agreement that if A registers a TLD .frobozz, that B and C will
promise to not register a conflicting definition of said TLD.
So what we really have here is (A+B+C) functioning as a single root, but
A, B, and C individually publishing only a subset of the root to their
customers (although why the customers want a value-subtracted view of the
DNS is beyond me).
So, to name names - if the ORSC crew and the ICANN crew were to collaborate
on a non-conflicting definition of "the root", then the composite of the
two of them would be a root, with each feeding only a subset to their
customers.
Of course, such collaboration is *NOT* happening in the real world, so we
*will* eventually see a conflict. It will probably happen the first time
ICANN allocates a new TLD that ORSC carries, but nominates a different
registrar or a different server on the NS record for the TLD.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
--==_Exmh_1710390537P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
Comment: Exmh version 2.5 07/13/2001
iQA/AwUBO/kvt3At5Vm009ewEQKOMACgrAKWT4Ryumk40Uvi+nd9dtXmB3gAoM8+
A6nPkCKuIF5DgvyLfPRdwAwT
=d0ge
-----END PGP SIGNATURE-----
--==_Exmh_1710390537P--
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |