Subject: RE: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)

From: "Liu, Hong" <[email-masked]>
Date: Wed, 30 Oct 2002 14:23:01 -0500

Jim, Asbjorn,

I would like to focus this thread on the advantages and disadvantages of
Single vs. Multi- copy solutions for external host objects.

To recap the discussion on the list, the motivation of dealing with external
host objects on a per-client basis is the ownership problem. Since external
hosts are outside of the registry namespace, no one, including the registry
itself, has exact knowledge about the external hosts. In a word, nobody
actually "owns" an external host as far as the registry is concerned.  

The only use of an external host object in EPP is as a nameserver for
domains of the registry. It merely serves as a pointer to an external
entity. External host objects are not transferred as a result of associated
domain transfer.

Before epp domain mapping -04, external host objects are created by clients
on a FCFS basis. There is a single-copy of an external host in the registry.
Whoever registrar first created an external host becomes the sponsoring
registrar of that object. As such, no other registrars will be able to do
much on the external host object except using it as a nameserver. There are
various headaches stem out of this client-centric single-copy ownership
model. Specifically, when the sponsoring registrar rename the external host
object, all domains that use it as nameserver are changed implicitly. This
has very undesirable effects on domains that are sponsored by other
registrars but use the external host as a nameserver. First, these other
registrars do not know such a change, and some domains may not want to
change to the new nameserver. Second, once the change is discovered after
the fact, these registrars will have to undo the change for all these
affected domains one-by-one.  

To resolve this problem, in epp domain mapping -04, a client-centric
multi-copy ownership model was adopted, and the model was carried over to
the latest epp domain mapping -05. However, after careful study, we find the
multi-copy ownership model only partially solves the update problem. In
addition, it introduces a whole lot of complexity into external host
handling, such as:

(1) Waste of storage space on the server side. Imagine that a registry has
100 registars, and each has a private copy of an external host. Then there
will be 100 private copies of host objects in the registry serving as
pointers to a single external entity. It is not uncommon in many registries
other than com/net/org where the majority of the nameservers are external
host objects.

(2) For all these private copies, the server has to specially manage them on
a per-client basis, i.e., {hostname, clID} pairs. This undoubtly and
unnessarily complicates the server software.

(3) Since each client updates its private copy individually, it is very
difficult to keep the state of these objects consistent. Of particular
difficulty is the presentation of such information to queries based only on
hostname. 

For example, in Whois, what result will be returned for a query on an
external object? All of the instances, none, randomly one? It is extremely
confusing, especially when different instances have different statii, say
one is "ok" while the other is "clientUpdateProhibited", the third is
"linked", and the forth is without "linked" status. 

Similarly, what will be the rules for response to the <info> command from a
client, only its private copy? What happen if the client does not have a
private copy? Should the server return all, none, randomly one? Note that
the current <info> response is not equipped with returning information for
multiple instances.

(4) It introduces undue complexity involving domain transfer, as we have
discussed in some details already. External hosts are not in-zone hosts, as
such they should not be involved in domain transfer. With the multi-copy
model, it requires special handling of external hosts used as nameservers,
as side-effects of domain transfer.

Most importantly, the multi-copy model does not solve the external host
rename problem completely. It just limits the problem from registry-wide to
registrar-wide. It is true that a single rename of the private copy will
result in all domains pointing to a different external host as a nameserver.
But what happen for partial update within the same registrar? If some of the
domains want to retain the old external host namesever, the registrar will
still have to do the update one-by-one. There is no other way around. Note
that this only covers massive renaming from the external to external case,
for external to internal or internal to external, the registrar will still
have to do it one-by-one if the internal host is not sponsored by the
registrar.

So if the only advantage of the multi-copy model is to facilitate the
massive renaming of external nameservers, then I would say that the cost is
too high to warrant such convenience. On the contrary, a server-centric
single-copy model solves the ownership problem in a much simpler and more
effective fashion, and yet does not introduce those undue complexity
mentioned above.

Cheers,

--Hong

---

From: "Gould, James" <[email-masked]>
Date: Wed, 30 Oct 2002 15:48:23 -0500

Hong,

I understand the motivation for supporting multi-copy external hosts.  Let
me address each one of your concerns:

1) Waste of storage space - An external host is light weight and supporting
a set of external hosts per registrar has not been an area of concern in the
registries that I've worked on.  

2) management on a per client basis - Supporting multi-copy external hosts
is extra effort when you have to consider host name changes and transfers,
but it is technically feasible.

3) keeping the state consistent - I don't understand the issue with
consistency, since the information that is presented should be based on the
context of the current EPP session.  If registrar A starts an EPP session,
than any host info commands should respond with registrar A's external host
information.  If registrar A does not have the external host, than the
response should be 2303 "Object does not exist".  It is up to you how you
want to present the information in whois.  You could allow for the passing
of the registrar id, provide back a list of hosts including the registrar
id, etc..    

4) complexity of transfers - Supporting multi-copy external hosts does
represent more effort when it comes to implementing transfer, but it is
technically feasible.  The ability to rename a host which automatically
changes the domain references is an important requirement/feature.  I don't
know of any requests for partial renames.  

I don't believe the only advantage is to "facilitate the massive renaming of
external nameservers", since the support for reference based renaming is a
core requirement with a single copy or multi-copy approach.   I believe that
the single copy approach was a significant complaint with RRP and providing
support for multi-copy external hosts was hammered out a long while back.  

After implementing multi-copy external hosts along with transfer, I do
appreciate the extra effort involved, but I believe this is an
implementation issue and not a protocol issue.  

Jim 

> facilitate the
> massive renaming of external nameservers
> ----------
> From: 	Liu, Hong
> Sent: 	Wednesday, October 30, 2002 2:23 PM
> To: 	[email-masked]'
> Subject: 	RE: Handling of External Host Objects: Single vs. Multi Copy
> Solu tions (was: in the context of domain transfer)
> 
> Jim, Asbjorn,
>