To:
"'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From:
"Liu, Hong" <Hong.Liu@neustar.biz>
Date:
Wed, 30 Oct 2002 14:23:01 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: Handling of External Host Objects: Single vs. Multi Copy Solutions (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