Subject: Handling of External Host Objects (in the context of domain trans fer)

From: "Liu, Hong" <[email-masked]>
Date: Mon, 28 Oct 2002 17:28:08 -0500

Ed, Scott, et al,

As indicated in my previous posting, I would like to bring up this topic
again to the list. I understand that that the related texts were introduced
in EPP-06, and related topics were heavily debated before EPP-06. However,
there are still lingering issues in the specs. This email serves two
purposes: to identify the problems in current spec, and to present a
strawman proposal to fix these problems.

I apologize in advance for this long email. I have tried to keep the
description short for these complicated issues without losing the details.

Here are the issues with EPP-07:

(1) External host objects are managed on a per-registrar basis in a
regsitry. There could be more than one instances of the same external host
object in the registry. In reality, <hostname, clID> uniquely identifies an
external host object. This requires special handling of external hosts at
the registry DB level. It also complicates registrar admin to deal with all
these external objects.

(2) To transfer a domain, if a domain contains a link to an external host
object as one of its nameserver, the following condition MUST be met in
order for a transfer request to be accepted by the server:
(a) The domain cannot refer to the external object of the losing registrar,
and
(b) A copy of the external object must exist in the gaining registrar.
The same conditions MUST also hold at the time the transfer is approved.
See
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-05.txt,
Section 3.2.4 EPP <transfer> Command, page 25, last paragraph.

This implies that in order to do a domain transfer, the registrant must
first ask the current registrar (i.e., the losing registrar) to remove the
link to the external object, then ask the gaining registrar to create one if
it does not exist. The only problem is that if all domain nameservers are
external objects. The registrant will lose DNS service during the transfer
pending period, and thus be discouraged from doing transfer at all. 

One may say that removing condition (a) will solve the problem. Yes, it
solves the problem if the standard specifies that by the time of transfer is
completed, the registry should do the switch-over of pointers to external
hosts from the losing registrar to the gaining registrar in one DB
transaction before approving the request.

I think that the multi-copy solution is kludgy for both registries and
registrars. I have a simpler one-copy proposal: 
[NOTE: I understand that it is late in the process. I just want to make sure
that solution works and it is simple.] 

(A) At most one instance of an external object is allowed in a registry.
(B) The registry is the neutral owner of all external objects, i.e., <clID>
is the registry, not any registrar.
(C) A registrar can create an external host if the host does not exists in
the registry. The registrar will be recorded in <crID> of the external host
object.
(D) A registrar cannot delete or update an external host. To change a
nameserver to another external host, just create one or point to another
existing one.
(E) The registry may perform garbage collection on those external hosts that
are not linked by a server-defined period of time.
(F) As for transfer, the links to external hosts remain unchanged. No extra
work needs to be done, by the registry, or by the two registrars involved.

Since most of the problems regarding handling of external host objects are
related to who owns the data, centralizing the management to the registry
eliminates the ownership controversy and its raminifications, allowing
external host objects be handled in a uniform and simple fashion.

--Hong

---

From: Asbjorn Steira <[email-masked]>
Date: Tue, 29 Oct 2002 10:26:14 +0000

[Time to unlurk]

Hi Liu,

please see below for comments...

> Ed, Scott, et al,
[SNIP]

> object in the registry. In reality,  uniquely identifies an

Yes, it does require some special handling of external hosts, but I am 
not sure it complicates things too much for registrars. Instead of 
having to worry and deal with other registrars' external hosts, they 
merely have to think about their own set of external hosts.

[SNIP]

> This implies that in order to do a domain transfer, the registrant 
> must first ask the current registrar (i.e., the losing registrar) to 
> remove the link to the external object, then ask the gaining registrar 
> to create one if it does not exist. The only problem is that if all 
> domain nameservers are external objects. The registrant will lose DNS 
> service during the transfer pending period, and thus be discouraged 
> from doing transfer at all. 

I don't understand the first part here, why would the losing registrar 
need to delete the link to the external host before transfer? He would 
only need to go to the new registrar and create the external host there 
(if it is not already there), request the transfer, and the domain would 
automagically swap to "using" the newly created external host when the 
transfer is completed. The domain will resolve during the whole process.

> (B) The registry is the neutral owner of all external objects, i.e.,
> the registry. The registrar will be recorded in  of the external host
> object.
> Since most of the problems regarding handling of external host objects 
> are related to who owns the data, centralizing the management to the 
> registry eliminates the ownership controversy and its raminifications, 
> allowing external host objects be handled in a uniform and simple fashion.

The problem with this is that when registrar A in the (for example) 
dotInfo registry later wants to rename his host ns1.example.com to for 
example ns1.example.info (i.e., moving it into the zone), he would have 
to first create the new host, and then update all the 1267 domains using 
ns1.example.com to use the new host. This is not a problem in the 
current solution.

Regards,

Asbjorn

-- 
Asbjorn Steira
Senior Developer
The Global Name Registry, Limited

Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************