Handling of External Host Objects (in the context of domain transfer)

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

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