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

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

Jim,

The issue at hand is _not_ what is technically feasible at all cost, but
what requires the least amount of work to get the job done. The
server-centric single-copy approach can accomplish the same goal without
incurring those extra works 1)-4), and other issues described in this email.

In terms of (3), you are making an assumption about server policy in terms
of who is eligible to query an external host using <info>. What if the
server policy is any client is eligible to query a host object? Will the
server return 2303 if the client does not have a private copy while there
are many other private copies out there? How can a server return multiple
instances of the same external host in an <info> response?

So the only way out is to codify in the protocol that a client can only
<info> its private copy for external hosts. This is in effect enforcing a
server policy. As discussed on the list many times before, the protocol
should be flexible enough to allow different policies, but _not_ to enforce
a specific policy. In addition, this is no longer an implementation issue,
it now becomes a protocol issue.

As for whois, to avoid confusion, an end user now needs to use both the
hostname and the registrarID to query an external host. I would not
speculate how many end users really know or care about registrarIDs. They
use whois just want to find out if a host exists or not. Plus, most of the
whois implementations today do not provide {hostname,registrarID} query
capability. Are you suggesting that even the whois part (and user behavior)
needs to be modified in order to accommodate the multi-copy model? Is it
introducing more problems in order to solve _a_ problem?

In terms of the support for reference-based renaming, the server-centric
single-copy model does not prohibit such operation. That is, a sponsoring
registrar is still capable of renaming any internal host objects created
through it. The problem is reference-based renaming for external host
objects. In our single-copy approach, this has to be done one-by-one.
However, for the multi-copy model, reference-based renaming only works for
massive external-to-external nameserver updates. For other cases, it has to
perform the nameserver updates one-by-one for most of the domains:

(5) Partial updates. For example, both registrant A and registrant B use ISP
X's DNS hosting services. Suppose both A and B register their domains
through the same registrar R, using the same set of namesevers provided by X
that are external hosts. Now B decides to use ISP Y's DNS hosting service
instead. Suppose that the nameservers provided by Y are also external hosts.
Then registrar R cannot just rename X's nameservers to Y's since A's domains
are still using X's nameservers. So R has to update B's domains one-by-one.

(6) External-to-internal. Suppose ISP X is also a registrant of R. It
creates a set of internal hosts through R. So R is the sponsoring registrar
of these hosts. Then X decides to use these hosts as nameservers to provide
DNS hosting services to all the domains in the same registry. Then R cannot
just rename the external hosts to the internal ones since those internal
hosts already exist in the registry. So R will have to update each domain of
A and B one-by-one. 

Another scenario could be that R implicitly creates these internal hosts by
renaming the external hosts. In this case, R does not need to update each
domain of A and B one-by-one. However, other registrars will have to update
domains one-by-one: they cannot just rename their private copies to the
internal hosts since they are not the sponsoring registrar of those internal
hosts. 

(7) Internal-to-external. Suppose ISP X has an internal host sponsored by R
that is being used as a nameserver of other domains. Now X wants to replace
that with an external host. There are two cases to consider:
(a) R already has a private copy of the external host. Then R cannot rename
the internal host to the external host. Instead, R will have to update each
domain one-by-one that uses the internal host as nameserver.
(b) R does not have a private copy of the external host. R can rename the
internal host to the external host without any problem since it is the
sponsoring registrar, and all domains sponsored by R that are using the
internal host as nameserver now points to the external host. 
In both cases, domains sponsored by other registrars that use the internal
host as nameserver will have to be updated one-by-one. To make things even
worst, in the case of 7(b), before these updates are completed, domains in
other registrars will be pointing to private copy of external host in R.
This violates the very principle of the multi-copy model!

In summary, I would like to get answers from the multi-copy proponents for
the following questions:

(i) What are the advantages of the multi-copy model as compared to the
server-centric single-copy model?

(ii) What are the complaints on the former client-centric single-copy model
that are not addressed by the server-centric single-copy model, but are
solved by the multi-copy model?

I would really like to be convinced that the multi-copy model is justified
in spite of all the problems uncovered in this and previous emails.

--Hong

-----Original Message-----
From: Gould, James [mailto:JGould@verisign.com]
Sent: Wednesday, October 30, 2002 3:48 PM
To: 'ietf-provreg@cafax.se'; 'Liu, Hong'
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solu tions (was: in the context of domain transfer)


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: 	'ietf-provreg@cafax.se'
> Subject: 	RE: Handling of External Host Objects: Single vs. Multi Copy
> Solu tions (was: in the context of domain transfer)
> 
> 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
> 
>