-> What About Breakups?
by "Dave Collier-Brown"
----------------------------------------------------------------------
Date: 4 Oct 1996 13:31:44 -0700
From: "Dave Collier-Brown"
Subject: What About Breakups?
What About Breakups?
We've discussed how to create relationships between customer (C), registry (R) and domain-name (d),
but what about the relationship of the domain name and its ``owner'' after a three-tuple breaks up?
Basically the relationship can end because
1. the customer doesn't want the domain any more
2. the customer doesn't pay his bills, or equivalently he finds a better registry, or
3. the registry goes out of business.
The customer is going to regard him-(her-)self as the owner of the domain name in any case, just as
she is the owner of the machines it describes.
The registry is going to take the opposite view.
The coordinating-database operator is going to find himself in the middle!
So what are the choices?
Course 1 -- Break Utterly
One quasi-obvious course of action is to break the relationship utterly apart if any of the parties leaves
it. The make goes back into the pool of possible names, the registry goes one way and the customer
goes another.
Alas, this only works well in case (1). If the customer isn't paying her bills, it might be because she's
found a better registry. If that's so, she certainly doesn't want to get into a race to reclaim ``her'' name.
It's terrible in case (3), as the customer loses her domain in the middle of the period she's paid for,
because (in this model), there's nothing left to keep the name alive.
Course 2 -- Name Stays with Registry
In case 1, the customer doesn't care, so the name can happily remain with the registry. The registry can
give it up, sell it to the highest bidder or arrange for it to point to hyperspace. It's the registries name, it
can do what it wants once the customer is out of the way.
In case 2, the customer wants to change registries, but the name belongs to someone else, so she
doesn't get the opportunity. Unless she changes her name, of course.
In case 3, the customer needs the registry to have already made a plan for its dissollution. If the plan is
``sell the business', she get a new registry she may or may not want. If the ``dive down a black hole and
pull it in behind us'', her registration is gone, as are all traces of the registry. If the plan is ``we don't
need no steenking plan'', then her registration will probably stay in the dns, unchanged. This is
inexpensive (no-one to have to pay fees to), but prevents her from ever updating it, save by involving the
cdb or comitting burglary.
Course 3 -- Name Stays with Customer
In case 1, the name belongs to some-one who couldn't care less. If they wish, they can arrange for the
name to be put back into the unused pool. Otherwise it just lies there, pointing to no-one, usable to
no-one else.
In case 2, she need not find a new registry unless she wishes to update the DNS. Despite not paying
anything, the record and DNS data is ``hers'', and will sit there until she decides to hire a registry to
change it.
In case 3, she need do nothing quickly: as with case (2), she needs a registry only if she wants to change
it. This allows catastrophic levels of registry failure without harming customers.
Alas, these are all fairly ugly alternatives. None of them is particularly desirable, save course 3, case 3,
which is robust in the face of error. The rest are various degrees pain-in-the-ass.
But What About Time?
However, the above discussion leaves out time. It's explicitly part of the problem: we see it in fixed
terms of registrations, the race to be first to register a particular name and so on. So we'd best consider
it if we're to address the whole problem.
As it happens, it improves the solutions considerably. If we introduce an explicit date for renewal of the
relationship, we can avoid domains disappearing, as discussed in course 1 above.
We also have the opportunity to define what will happen ``for a short while'' after it ends, and what is to
happen after that time.
HOWEVER, it doesn't solve the problem, it just makes the solutions better. Ownership is the problem,
after all...
Let us assume that we only register domains for 1 year, and that the ``short time'' (also called the
delta-t value) is one month.
Course 1 -- Break Utterly
So our customer and registry break up. The registration stays in place until the year ends, at which time
it ``expires'', and the data is taken out of the DNS, but not out of the coordinating database for another
month.
As far as the outside world is concerned, the domain is gone. If someone tries to allocate it for
themselves during the month, they fail and get the expiry date (which is in the past). This is a tipoff
something wierd is going on.
In case (1) the customer doesn't want the domain any more, so neither the customer nor registry need
pay any more attention to it. If someone else wants it, they will be able to try to claim it as soon as the
month runs out. On the technical side, the cdb needs to make sure the registration is claimable ``fairly''
by any applicant, possibly by allowing a new registration the instant the 30 days are up.
In case (2), where the customer doesn't pay her bills, she is either changing registries or the registry is
forcing them to do so. There is no means for the customer's new registry to claim ``her'' name, so it
must compete with other wishing it. If it wishes to avoid negotiating with her former registry, it must wait
a month for the name to expire and then hope to claim it. So the customer can easily lose her name. This
may or may not be desirable (:-))
In case (3) the registry goes out of business, the customer is left with exactly the same situation as in
(2). And so are all the other customers of the registry. This is almost certainly not desirable.
In all these three cases, adding an explicit period and a delta-t only allows time for manual intervention
from outside the system to correct predictable undesirable features.
Course 2 -- Name Stays with Registry
In this case the registration stays in place until the year ends, then disappears from the DNS, and a
month later from the cdb. The difference is that the cdb record ``belongs'' to the registry, which can edit
it as they see fit, including assigning it to someone else, renewing it, etc.
In case (1) the customer doesn't want the domain any more, so neither the customer nor registry need
pay any more attention to it. If the registry wants, they can delete it, or they can just let it time out. If
they do want it (ie, they have a waiting list), they can then allocate it to the new customer. Or sell it to
another registry.
If someone else wants it, they will be able to try to claim it as soon as it disappears or the month runs
out. As before, the cdb needs to make sure the registration is claimable ``fairly'' by any applicant.
In case (2) with the customer not paying her bills, she is either changing registries or the registry is
forcing her to do so. In all these cases the old registry has the option of changing the record to point to a
new registry. They can give, sell or lease the name as they see fit, or refuse to do so and retain the
name with its data sating anything the want.
There is no means for the customer's new registry to claim ``her'' name, so it must obtain it from the old
registry, or at best compete with other wishing to claim it when it times out. This is arguably bad.
In case (3) the registry goes out of business, the customer is left hoping the old registry sold all the
names to someone reasonable. If they did, there is little or no technical problem. If the old registry sold
the names to a crook, there is a political problem. If the old registry just died without issue, all the
customers are left without means of retaining their names short of competing for them. This is bad.
In all these three cases, adding an explicit period and a delta-t allows time for intervention, and defining
the registry as the appropriate person to intervene gives then to power to act for good or ill.
Course 3 -- Name Stays with the Customer
Again, the registration stays in place until the year ends, disappears from the dns and later from the cdb.
Only this time the cdb record contains a pointer to the customer, not the registry. The customer ``owns''
the record.
In case (1) the customer doesn't want the domain any more, so neither the customer nor registry need
pay any more attention to it. If someone else wants it, they will be able to try to claim it as soon as the
month runs out. Again the cdb needs to make sure the registration is claimable ``fairly'' by any applicant.
In case (2), if customer doesn't pay her bills, the customer retains her registration: only the registry
disappears from the record.
The customer can have her new registry take over her name by providing proof of ``ownership'' to the
cdb, which takes external action to change the registry field of the record, allowing the new registry to
update it.
In case (3) the registry goes out of business, all the customers are left with exactly the same situation as
in (2). This is not particularly desirable. Each customer would have to find a new registry, contact the cdb
(through their registry) and change the registry in their record. This is seriously clumsy.
Next Step
Ok, what do we have to introduce into the problem to get suitable results? I suspect course 3 is the
closest to optimum, but its behavior when a registry fails is quite horrid.
Comments and suggestions, please, folks!
Dave Collier-Brown
