RE: Definition of "External" Host

["Liu, Hong" <Hong.Liu@neustar.biz>]

Scott,

Please see my comments below enclosed by <HL/>.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Wednesday, October 09, 2002 7:29 AM
To: 'Liu, Hong'; 'ietf-provreg@cafax.se'
Subject: RE: Definition of "External" Host

> 
> Maybe an example will help explain my point. Suppose we have 
> a TLD .tld with
> two 3rd level delegations del1.tld and del2.tld. So there are 
> three disjoint
> name spaces under .tld: del1.tld, del2.tld and anything else 
> under .tld.
> These three name spaces have different registration policies. 
> They may also
> share some common registration policies.
> 
> If I understand correctly, .tld, .del1.tld, and .del2.tld are 
> considered as
> three separate "repositories". If not, please ignore the rest of the
> message.

My contention is that they are all under the same ultimate management
authority and part of the same repository because they are all part of the
same TLD branch.

<HL>
This is where you and I have different views. Yes, they are all part of the
same TLD, but they are different name spaces with different registration
policies. While it is true that the complete name space is governed by the
same management authority for most gTLDs, it is not true for many ccTLDs. So
in general, we cannot regard a TLD as one repository because there are
delegations under the same TLD, mostly at the second level, but also can be
extended to higher levels.

Back to the example, the name spaces are defined as follows:

.del1.tld: anything under the subtree rooted at .del1.tld. Registration
occurs at the 3rd level in the form of abc.del1.tld.
.del2.tld: anything under the subtree rooted at .del2.tld. Registration
occurs at the 3rd level in the form of def.del2.tld.
.tld: anything under .tld that are NOT under .del1.tld or del2.tld.
Registration occurs at the 2nd level in the form of ghi.tld.

Logially, these are three separate repositories, each of which has its own
registry DB and zone file. If an entity happens to manage both .tld and
.del1.tld, as an implementation optimization option, it may choose to
combine both registry DBs and generate one zone file. But that is registry
implementation option. It should not be codified into the protocol as the
generic case. I personally don't think that is good engineering since
optimization by collapsing logical structures often limits future
extensibility and may come back to haunt software development.

Of course, in order for DNS to work, del1.tld and del2.tld must be
registered under .tld as part of the pre-provisioning process by the .tld
registry operator. So if ns.del1.tld is a nameserver for del1.tld, then a
glue record must be created in the .tld zone file for that host.
</HL>

Think of it this way: should I or should I not be publishing glue records
for hosts registered under these domains?  If the answer is "yes", they are
not external hosts.  If the answer is "no", they are external hosts.

<HL>
I don't disagree with that, but I think the cause and result should be
reversed. Whether a glue record should be generated for a host w.r.t a
repository is determined by whether the host name belongs to the name space
in question. If the host is external to the name space, then no glue record
should be generated for that host. 

That is why it is so important to be explicit about the name space when
creating a host object. In EPP-07, the rules for creating an external host
are different than those for creating an internal host.
</HL>

-Scott-