Subject: Definition of "External" Host

From: "Liu, Hong" <[email-masked]>
Date: Tue, 8 Oct 2002 16:56:29 -0400

Scott,

I have a question for clarification regarding the definition of "external"
host in the 2nd paragraph of Section 1.1 in
draft-ietf-provreg-epp-host-05.txt. Does it mean that a host object is
external to the current TLD only if the host name belongs to another TLD?
There are other cases that a host can also be external under the same TLD
but belongs to different 3rd level delegations. Thanks!

--Hong

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 8 Oct 2002 19:58:47 -0400

> but belongs to different 3rd level delegations. Thanks!

I think the definition in section 1.1 is pretty clear: if there is no
superordinate domain name (a domain name higher up in the hierarchy)
registered in the repository, the host is considered an external host.  What
matters is where the management authority for the host's registered domain
lies:

"Such hosts are
described as "external" hosts in this specification since the
management authority for these hosts is external to the repository in
which the host is being used for delegation purposes."

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Tue, 8 Oct 2002 22:29:40 -0400

Scott,

The sentence you quoted seems OK if the terms "management authority" and
"repository" are precisely defined. It is not a problem if the repository is
the whole TLD and the management authority is the TLD registry operator.
However, it is getting complicated when delegation of name spaces occurs
under the same TLD in 3rd level and up.

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.

Now suppose registry operator A is responsible for .tld and .del1.tld, and
registry operator B is responsible for .del2.tld. So A is the management
authority for .tld and del1.tld, while B is the management authority for
del2.tld. 

Let's say three domains have been created in the three repositories,
respectively: abc.tld, def.del1.tld, ghi.del2.tld. Suppose def.del1.tld
wants to use hosts ns.abc.tld and ns.ghi.del2.tld as its nameservers. The
questions are:

(1) Is ns.abc.tld an external host of def.del1.tld? 
The answer seems to be "yes" since .tld and .del1.tld are two different
repositories. However, the management authority of ns.abc.tld is identical
to that of del1.tld, i.e., registry operator A. In other words, A is not
external to def.del1.tld.

(2) Is ns.ghi.del2.tld an external host of def.del1.tld?
The answer is "yes", and the definition is fine.

So it seems what needs to be clarified is the case where two separate
repositories under the same TLD are administered by the same management
authority. The key lies in the delineation of repository, not the management
authority. In the above example, if we stick to the name space definition,
then the answers would be "yes" to both questions.

The real sticky issue is whether a host is external or not may not be clear
at the time it is created. In the above example, when ns.abc.tld is created,
it is not clear whether it will be used as a nameserver for abc.tld or
def.del1.tld since registry operator A operates both .tld and del1.tld. It
will only be clear when it is associated with either abc.tld (delegated) or
def.del1.tld (external). Additional questions are:

(3) Can ns.abc.tld be created without abc.tld being created first?
The answer seems to be "no" in the case. That is, the "subordinate host
rule" should take precedence over the "external host rule" for host object
creation.

(4) Can ns.abc.tld have multiple copies, one per registrar?
For the "subordinate host rule", the answer should be "no". But for the
"external host rule", the answer should be "yes". The dilemma is that
ns.abc.tld cannot become an external host unless it is associated with
def.del1.tld. However, it cannot be an external host for def.del1.tld unless
it is created as an external host object for the sponsoring registrar of
def.del1.tld. On the other hand, a subordinate host object ns.abc.tld
already exists for domain abc.tld. So creating another copy would fail!

With connection-oriented transport bindings such as TCP, (3) and (4) can be
resolved by assigning different connections between the registry and the
registrar for .tld and del1.tld. The server will be able to tell from the
connection whether the host object created is intended for .tld or del1.tld.
While this is not very efficient, it can be made to work. With
connection-less transport, such as HTTP or SMTP, we are not as lucky. Maybe
we should include a <respository> parameter in the <login> message for the
client to indicate to the server which name space(s) the session is set up
for.

I apologize for the long message. Basically I am talking myself through
these issues. I hope that I am not making this issue more confusing than
necessary, -:)

Regards,

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 7:59 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Definition of "External" Host

"Such hosts are

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Wed, 9 Oct 2002 18:28:33 -0400

Scott,

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

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 7:29 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Definition of "External" Host

> three separate "repositories". If not, please ignore the rest of the

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-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Oct 2002 21:54:42 -0400

I still do not understand what you do not understand.  In the specialized
case of a host being a name server, the host is either registered in a
repository that is authoritative for the IP address association with that
host or it isn't.  If it isn't, we came up with the "external host" term to
note the distinction that requires special DNS processing for name server
hosts.

host.2ld.tld is internal to the 2ld.tld repository.  It is external to any
other repository, including those that might exist under 2ld.tld, such as
3ld.2ld.tld, for reasons including some of those you described.  I'm not
sure where my earlier responses suggest otherwise, but they way you
described collapsing DBs and zones suggests that you've interpreted
something I said in a manner that I didn't intend.

This has nothing to do with registration policies, business practices, or
whatever.  It is ultimately related to the DNS and the zone file in which a
glue record for the name server should properly be published.

So, I think we're talking about the same thing.  Could you get to the point
of whatever it is you have an issue with?  If you don't like the way these
special-case hosts are described in the current document, please suggest
alternative text to describe the concept.

By the way, none of this was introduced in EPP-07.  It's been this way for
several revisions, including the one that passed WG last call.

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Thu, 10 Oct 2002 01:53:27 -0400

Scott,

The text I would like to propose to change is in
draft-ietf-provreg-epp-domain-05.txt, section 1.1, second paragraph, last
sentence: 
change 
"Such hosts are described as "external" hosts in this specification since
the management authority for these hosts is external to the repository in
which the host is being used for delegation purposes."
to
"Such hosts are described as "external" hosts in this specification since
the name of such host does not belong to the name space of the repository in
which the host is being used for delegation purposes."

I would also like to add some text in section 1.1 for the case where a host
object is used as a nameserver for a domain, but it is neither an external
host nor a subordiate host of the domain. That is, a host object that is
internal to the repository but external to the domain where it is being used
for delegation purpose. For example, ns1.abc.tld is a subordinate host of
domain abc.tld, and it is being used as a nameserver for domain def.tld. EPP
seems to allow this scenario, but it is not explicitly covered in section
1.1. The suggested text can be the following:

"Whether a host is external or internal is with respect to the repository in
which the host is being used for delegation purposes. Whether an internal
host is subordinate or non-subordinate is with respect to a domain within
the respository. For example, host ns1.abc.tld is a subordinate host of
domain abc.tld, but is a non-subordinate host of domain def.tld. ns1.abc.tld
can be used as a nameserver for def.tld. In this case, ns1.abc.tld MUST be
treated as an internal host, subject to the rules governing the operations
on subordinate hosts within the same repository."

I will leave it to you as how to incorporate the above paragraph in section
1.1. 

What do you think?

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 9:55 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Definition of "External" Host

[snip...]

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 10 Oct 2002 07:21:12 -0400

> I will leave it to you as how to incorporate the above 
> paragraph in section 1.1. 
> 
> What do you think?

I'm OK with your clarifications.  Thanks for providing the text.

-Scott-