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

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

Asbjorn,

Please see my comments in line enclosed with <HL/>. I am using MS Outlook,
-:(.

--Hong

-----Original Message-----
From: Asbjorn Steira [mailto:asteira@gnr.com]
Sent: Thursday, October 31, 2002 12:46 PM
To: Liu, Hong
Cc: 'ietf-provreg@cafax.se'
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
Solu tions (was: in the context of domain transfer)


Hong,

please see comments below...

Asbjorn


Liu, Hong wrote:

> In terms of (3), you are making an assumption about server policy in 
> terms of who is eligible to query an external host using . 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 response?
>
> So the only way out is to codify in the protocol that a client can 
> only 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.

I realize that the sponsoring registrar can only view his own copy of 
the host object, and even though this is not perfect, I don't think this 
is a big problem. There is not really any useful information related to 
an external host, the only thing that might be of interest is the status 
of the object.

<HL>
It is a fixed-in of server policy in the protocol, and it is a protocol
issue. And it is a bad fix.

Having multi-copy of the same object but letting these copies be out of sync
in terms of object states is long recognized as a basic flaw in
object-oriented computing. Why are we violating a basic principle to come up
with a kludgy solution to another problem where a simpler solution exists?

Do you think host statii are not interesting or useful? Then why do we keep
them in the protocol in the first place?
</HL>

> 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?

This depends on how you implement it - the end user does not necessarily 
need to know the registrar name/id. For .name we simply return all the 
instances of the object, for example:
http://www.nic.name/cgi-bin/whoisweb.cgi?type=public&page=query&d=d&qt=names
erver&q=NS.NEWDREAM.NET

<HL>
Please see my original posting on (3) regarding whois. Yes, you can
enumerate all private copies of an external object. But it is at best
confusing to the end user of whois. In other to make sense out of the
response, the end user will have to sort through which private copy belongs
to which registrar. The end user will be even more confused when the private
copies have different/conflicting statii. It is inconsistent with internal
host query, which means you need to write the whois code differently to deal
with the two cases. Since it returns more data for external hosts, it is
more likely to overload the whois server. Is it introducing more problems in
order to solve _a_ problem?
</HL>

> 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.

This could be done with only one host update command in a multi-copy 
universe.

<HL>
I would like you to explain how you can do that.
</HL>

> (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. 

Would be the same for single-copy and multi-copy...

<HL>
That means multi-copy offers no advantage for this case.
</HL>

> 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. 

Would be the same for single-copy and multi-copy...

<HL>
That means multi-copy offers no advantage for this case.
</HL>

> (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.

Would be the same for single-copy and multi-copy...

<HL>
That means multi-copy offers no advantage for this case.
</HL>

> (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!

I think this was discussed on the list at some point. And I think this 
is the biggest "problem" we identified with the multi-copy solution.

<HL>
So you agree that this is the biggest problem (note no double quotes). How
are you going to fix it? 

Why are we inventing a model that is basically flawed with inconsistency?
</HL>

> 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?

(a) Mass updates (I). In the single-copy model, a registrar potentially 
needs to do x thousand domain update commands when changing a name 
server name from ns1.example.tld to ns2.example.tld. This can be done 
with only one host update command in multi-copy.

<HL>
First, how often will a registrar update THOUSANDS of domains at the same
time? 

Second, until you could explain to me how you can do partial update with one
host update command, I will have to say this is of such low probability that
it should _not_ be used as the key criteria for protocol design
optimization.
</HL>

(b) Mass updates (II). As far as I can see, the single-copy model won't 
support any kind of moving name servers into the zone, you would always 
need to run update commands for all domains. In most cases, this would 
work fine in the multi-copy model.

<HL>
Could you please expand your point further? I am getting lost here?
</HL>

That's the only things I can come up with right now.

I do see that the single-copy model solves the 7b-problem and 
potentially makes the transfer process a bit easier, and I guess it is 
all about if you want that or if you rather wanna make mass updates 
easier. I see strong and weak points with both solutions...

<HL>
As discussed above, maintaining model consistency is very important in
protocol design. Making the transfer process simple and uniform is very
important. Transfer is the most complicated operation in EPP, and the
multi-copy model makes it even more complicated. Plus the <info> and whois
problems, the complication of server logic to specially handles multiple
copies, the waste of storage, the <check> command inconsistency, the risk of
implicit mass update, etc. These are undue cost and complexity incurred by
the multi-copy model.

Is it still justified to keep the multi-copy model just for the convenience
of complete mass update for external-to-external host renaming? I guess the
answer is pretty clear.
</HL>


> (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?

Not having dealt with RRP registries, I cannot answer this :-).


(Asbjorn)

-- 
Asbjorn Steira
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
*****************