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: Sat, 2 Nov 2002 12:17:55 -0500

Hi, Andy,

Actually we may be talking about the same thing, -:) What I meant by
enumerating (5)-(7) was to show that mass update does not work for
multi-copy model in those scenarios. And as such, it is just as good (or
bad) as the the server-centric single-copy model. In other words, mass
update _only_ work in the case of _complete_ external-to-external host
rename. It is the only advantage that I heard so far, but came with so many
baggages.

--Hong

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]]
Sent: Thursday, October 31, 2002 10:22 AM
To: [email-masked]'
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
Solu tions (was: in the context of domain transfer)

On Wed, Oct 30, 2002 at 06:37:34PM -0500, Liu, Hong wrote:
> (5) Partial updates. 
[. . .]
> 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.

I truly do not understand this objection.  This is no different than
if B decides to change name servers using internal hosts, if someone
else is using the host.  (Objection 6 seems to me to be the same:
it's just not a real objection.  Yes, it's a pain to change the
nameservers of a large number of domains.  There's a reason managers
of large networks avoid doing so.)

A
-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                         +1 416 646 3304 x110

---

From: "Liu, Hong" <[email-masked]>
Date: Sat, 2 Nov 2002 13:07:24 -0500

Asbjorn,

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

--Hong

-----Original Message-----
From: Asbjorn Steira [mailto:[email-masked]]
Sent: Thursday, October 31, 2002 12:46 PM
To: Liu, Hong
Cc: [email-masked]'
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy

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

---

From: "Liu, Hong" <[email-masked]>
Date: Sun, 3 Nov 2002 02:53:14 -0500

Jens,

Excellent points. I agree with your analysis. In other words, you went a
step further by stating that there is no way out of the paradox in the case
of 7(b) for the multi-copy model. 

No matter how one argues it being an implementation issue, the host object
handle as exposed in EPP is the hostname. Changing the hostname is
equivalent to deleting the old object and then creating a new one with the
same content. In your analysis, you identified the issue of implicit
deletion of a host object when it is linked to domains. As we all know,
explicit deletion of a linked host object is not allowed in EPP. Your
analysis implied that for the multi-copy model, even the implict deletion of
a linked host object is problematic.

One may argue that a way to get around it is not allowing sharing of
internal host objects as nameservers among registrars. Again we get back to
the issue of server policy. I don't think we should enforce that in the
protocol. What do you think?

Cheers,

--Hong

-----Original Message-----
From: Jens Wagner [mailto:[email-masked]]
Sent: Saturday, November 02, 2002 2:26 PM
To: Liu, Hong; [email-masked]
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)

Hong,

Regarding 7(b), I don't think it is a good idea to let one registrar use
another registrar's private copy of an host object, that's why we call it
private. It would also be inconsistent with the return values of the host
related check and info commands.

Regaring the server policy in (2.):
1. When dom2.tld loses DNS service from ns.dom.ext, this will eventually
render the domain status of dom2.tld from active to inactive. Should
Registrar R1 be allowed/able to deactivate domains from Registrar R2?
2. When the server has to deny a request for changing an internal host to an
external host, how will Registrar R1 be able to know the reason, and how
will R1 be able to resolve that?

Best regards,

-jens

----- Original Message -----
From: "Liu, Hong" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 02, 2002 7:32 PM
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)

> Jen,
>
> Please see my comments below. Thanks!
>
> --Hong
>
> From: Jens Wagner [mailto:[email-masked]]
> Sent: Saturday, November 02, 2002 5:50 AM
> To: Liu, Hong; [email-masked]
> Solutions (was: in the context of domain transfer)
>
>
>
> ----- Original Message -----
> From: "Liu, Hong" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, October 31, 2002 12:37 AM
> Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
> Solutions (was: in the context of domain transfer)
>
>
> ...
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:
> 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.
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.
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.
> ...
> Just thought about your point 7(b):
>
> Registrar R1 creates domain dom1.tld
> Registrar R1 creates host ns1.dom1.tld (internal host)
> Registrar R1 updates domain dom1.tld to use nameserver ns1.dom1.tld
> (internal)
> Registrar R2 creates domain dom2.tld with nameserver ns1.dom1.tld
(internal)
> so far, its seems to be ok:
> ----
> dom1.tld managed by R1 has nameserver ns1.dom1.tld
> dom2.tld managed by R2 has nameserver ns1.dom1.tld
> ----
>
> now we apply Scenario 7(b):
> Registrar R1 renames host ns1.dom1.tld (internal) to ns.dom.ext(,R1)
> (external)
>
> What does the Registry DB look like now?
> ----
> dom1.tld managed by R1 has nameserver ns.dom.ext(,R1) (external)
>
> What happens with dom2.tld? Three possibilities:
> 1. dom2.tld managed by R2 has nameserver ns1.dom1.tld (internal)
> 2. dom2.tld managed by R2 has nameserver ns.dom.ext(,R1) (external)
> 3. dom2.tld managed by R2 has nameserver ns.dom.ext(,R2) (external)
> ----
>
> (1.) should not be possible, because R1 removed the internal host
> ns1.dom1.tld by renaming it.
> (2.) should not be possible, because ns.dom.ext(,R1) must not be
accessible
> by R2.
> (3.) should not be possible, because this would mean that R1 created an
> external host object ns.dom.ext(,R2) in the repository of R2.
>
> Or did I get anything wrong?
>
> <HL>
> Your breakdown of the scenario is excellent. Thanks for doing that.
>
> It seems that whether (2.) is possible or not is _not_ specified in the
> current EPP protocol. As such I viewed that as a server policy. 7(b) in my
> case allows one registrar to use another registrar's private copy, while
> your (2.) does not. We were both right on that sense. In fact, the server
> policy in (2.) makes the multi-copy model even less attractive since now
> either dom2.tld loses DNS service from ns.dom.ext or that the server will
> have to deny the initial request for changing an internal host to and an
> external host. What do you think?
> </HL>
>
> Best regards,
>
> Jens Wagner
> Key-Systems GmbH
>
>