-> What About Breakups? (repost)
by "Dave Collier-Brown"
-> Re: What About Breakups? (repost)
by John Leslie
-> name value pairs
by "Richard J. Sexton"
-> nameservers
by "Richard J. Sexton"
-> Re: name value pairs
by "Rick H. Wesson"
-> Re: name value pairs
by "Rick H. Wesson"
-> Re: name value pairs
by "Richard J. Sexton"
----------------------------------------------------------------------
Date: 19 Oct 1996 02:18:32 -0700
From: Simon Higgs
Subject: Re: NEWDOM: shared tld mailing list
At 9:51 PM -0700 10/18/96, Rick H. Wesson wrote:
> Is the shared tld list still up and running?
>
Yup. But it's always quiet when Newdom is noisy.
Simon
- --
"The only thing to prevent what's past is to put a stop to it before it
happens."
-- attributed to Sir Boyle Roche, eighteenth-century member of
Parliament from Tralee, famed for his word-mangling
----------------------------------------------------------------------
Date: 19 Oct 1996 09:47:51 -0700
From: "Dave Collier-Brown"
Subject: What About Breakups? (repost)
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
----------------------------------------------------------------------
Date: 19 Oct 1996 19:54:13 -0700
From: John Leslie
Subject: Re: What About Breakups? (repost)
Dave Collier-Brown wrote:
>
> ... what about the relationship of the domain name and its ``owner''
> after a three-tuple breaks up?
It seems obvious (IMHO) that the break-up of a three-tuple should
have no immediate effect on ownership of a domain name.
> 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.
This division into cases isn't terribly helpful (IMHO). Basically,
I'd say the three-tuple breaks up when:
a) the registry says the customer wants to return the name to the pool,
b) the registry says the customer isn't paying his/her bills,
c) the registry stops paying its own bills, or
d) some other registry says the customer wants to switch.
It's important to keep the distinction between what the situation
actually "is" and what certain parties say it is. The CDB will sink
into the mire if it attempts to adjudicate what "is".
> 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!
The CDB should never adjudge a dispute between a registry and its
customer. It simply _cannot_ be sufficiently impartial.
Whether the customer or the registry "owns" the domain should be in
the contract between customer and registry. Personally, I would prefer
that the customer own the domain -- after all, that's the way most 'Net
users are going to think about it. But if a registry wants to write the
contract so that ownership stays with the registry (or reverts to the
registry under well-defined conditions), it's up to the customer to
decide whether to accept that condition.
> Course 1 -- Break Utterly [name goes back into available pool]
>
> Alas, this only works well in case (1).
Actually, it doesn't even work well when the customer doesn't want
the name any more. Until the name has been out of use for a long enough
time, reassignment will cause confusion. I would think at least a full
year of non-use would be necessary before anybody else could use the
name without coordinating the transition with the previous user.
If the customer doesn't want the name anymore, the owner (whether
customer or registry) should be free to transfer it to another user,
and the name should only revert to the available pool if it remains
unused for a long enough period.
> Course 2 -- Name Stays with Registry
>
> In case 2, the customer wants to change registries, but the name belongs
> to someone else, so she doesn't get the opportunity.
If that's what the contract says, she should live with it. (Of course,
I'd be very hesitant to agree to such a contract.)
(Dave lumps a lot of different situations into "case 3". All of them,
I agree, are unattractive to the customer if ownership of the domain
name goes with the registry.)
> Course 3 -- Name Stays with Customer
>
> In case 1, the name belongs to some-one who couldn't care less.
This is not a bad thing. If the name simply stays unused, we minimize
the confusion to 'Net users.
> In case 2, she need not find a new registry unless she wishes to update
> the DNS.
Dave is mistaken.
If the CDB retains a record for which the registry of record has no
agreement with the customer, then the CDB will have to deal directly
with the customer. This is a bad thing.
But in fact, if the registry believes the customer is a deadbeat,
they will deactivate the domain before removing themselves as registry
of record. This is a good thing.
If the customer wishes to change registries, it is up to the new
registry to arrange the update of the domain name record. The CDB
should only get involved in disputes if they are disputes between
registries.
> In case 3, she need do nothing quickly:
There should never be a problem finding another registry which wants
to take over existing customers. The CDB can reassign customers randomly
if no agreement of transfer is in place.
I reiterate: the CDB should never put itself in a position where it
has to deal with customers directly.
> 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.
Fixed terms of registration are an artifact of the InterNIC.
The race to register "attractive" names is inevitable, and can only
be helped by requirements to put the name into use.
> If we introduce an explicit date for renewal of the relationship,
> we can avoid domains disappearing, as discussed in course 1 above.
Not really -- we just introduce a mechanism for decaying to a known
state. If the situations Dave mentioned happen at the wrong time, these
renewal dates don't help at all.
> HOWEVER, it doesn't solve the problem, it just makes the solutions
> better. Ownership is the problem, after all...
I agree. So let's "solve" the problem of ownership. Once that's clear
the problems disappear.
And recall, I suggested that ownership should be a subject for the
customers and the registries to work out in their own contracts.
> 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.
I'll let someone else assume that -- I don't believe it helps.
> Comments and suggestions, please, folks!
Personally, I'd like to stipulate that in the absence of contract
language, ownership of the domain will remain with the customer.
The obvious reason for a registry to want to "own" the name is to
have a way of collecting fees. I believe that fees can be collected
up front, before the registration is complete, and this problem will
disappear. YMMV...
- --
John Leslie
----------------------------------------------------------------------
Date: 19 Oct 1996 20:37:21 -0700
From: "Richard J. Sexton"
Subject: name value pairs
Can we standardize on what names we make up for name value
pairs for registry software?
I can see registries sending data to other registries
in this format and if my interface send data to
your cgi script the names will need to match.
Anybody who is doing any work in this area
please contact me, we're ready to test things
around the Alter.NIC
- --
"It's too dark to put the keys in my ignition"
----------------------------------------------------------------------
Date: 19 Oct 1996 21:34:45 -0700
From: "Richard J. Sexton"
Subject: nameservers
Further to the issue of my testing registry software,
who here sells commercial nameservice as a product?
send me names and IP's if ya got em.
- --
"It's too dark to put the keys in my ignition"
----------------------------------------------------------------------
Date: 19 Oct 1996 22:52:29 -0700
From: "Rick H. Wesson"
Subject: Re: name value pairs
On Oct 19, 11:37pm, Richard J. Sexton wrote:
> Subject: name value pairs
> Can we standardize on what names we make up for name value
> pairs for registry software?
I think the RIPE format would work nicely.
> I can see registries sending data to other registries
> in this format and if my interface send data to
> your cgi script the names will need to match.
Oh, you wana trade info via cgi? OK use the RIPE
tags.
> Anybody who is doing any work in this area
> please contact me, we're ready to test things
> around the Alter.NIC
I got 15,000 applications made up from whois data, some are good
some are bad. Most of them are new Domain requests. I 'm working
on another script that generates NEW, MODIFY and DELETE templates
for CONTACT, HOST, DOMAIN, and NOTIFY templates. I'll send that
to whom ever would like a copy.
While we are at it is anyone working on a version of Gardian?
I'm tring to work out a test harness for mine, wana work togther?
or at least trade test sets? It is a bitch to generate correct
BEFORE-USE et. al. templates....
As for Ques I've got a nice [read quick] sendmail deliver (via pipes)
to put mail to an address in a que for processing...
I'll set up an annomous ftp site for these things and
more if folks are interested.
- -Rick
>
>
> --
> "It's too dark to put the keys in my ignition"
>
>
>-- End of excerpt from Richard J. Sexton
- --
Rick H. Wesson
----------------------------------------------------------------------
Date: 19 Oct 1996 22:52:35 -0700
From: "Rick H. Wesson"
Subject: Re: name value pairs
On Oct 19, 11:37pm, Richard J. Sexton wrote:
> Subject: name value pairs
> Can we standardize on what names we make up for name value
> pairs for registry software?
I think the RIPE format would work nicely.
> I can see registries sending data to other registries
> in this format and if my interface send data to
> your cgi script the names will need to match.
Oh, you wana trade info via cgi? OK use the RIPE
tags.
> Anybody who is doing any work in this area
> please contact me, we're ready to test things
> around the Alter.NIC
I got 15,000 applications made up from whois data, some are good
some are bad. Most of them are new Domain requests. I 'm working
on another script that generates NEW, MODIFY and DELETE templates
for CONTACT, HOST, DOMAIN, and NOTIFY templates. I'll send that
to whom ever would like a copy.
While we are at it is anyone working on a version of Gardian?
I'm tring to work out a test harness for mine, wana work togther?
or at least trade test sets? It is a bitch to generate correct
BEFORE-USE et. al. templates....
As for Ques I've got a nice [read quick] sendmail deliver (via pipes)
to put mail to an address in a que for processing...
I'll set up an annomous ftp site for these things and
more if folks are interested.
- -Rick
>
>
> --
> "It's too dark to put the keys in my ignition"
>
>
>-- End of excerpt from Richard J. Sexton
- --
Rick H. Wesson
----------------------------------------------------------------------
Date: 19 Oct 1996 23:08:29 -0700
From: "Richard J. Sexton"
Subject: Re: name value pairs
At 10:51 PM 10/19/96 -0700, you wrote:
>On Oct 19, 11:37pm, Richard J. Sexton wrote:
>> Subject: name value pairs
>> Can we standardize on what names we make up for name value
>> pairs for registry software?
>
>I think the RIPE format would work nicely.
URL ?
>> I can see registries sending data to other registries
>> in this format and if my interface send data to
>> your cgi script the names will need to match.
>
>Oh, you wana trade info via cgi?
Yeah, I can see out forms executing part 2 of the
script executing on a rmeote nachine.
>> Anybody who is doing any work in this area
>> please contact me, we're ready to test things
>> around the Alter.NIC
>
>I got 15,000 applications made up from whois data, some are good
>some are bad. Most of them are new Domain requests. I 'm working
>on another script that generates NEW, MODIFY and DELETE templates
>for CONTACT, HOST, DOMAIN, and NOTIFY templates. I'll send that
>to whom ever would like a copy.
can you supply us with a url to one so we can see what you
mean by appliaction?
>While we are at it is anyone working on a version of Gardian?
>
>I'm tring to work out a test harness for mine, wana work togther?
>or at least trade test sets? It is a bitch to generate correct
>BEFORE-USE et. al. templates....
>
>As for Ques I've got a nice [read quick] sendmail deliver (via pipes)
>to put mail to an address in a que for processing...
>
>I'll set up an annomous ftp site for these things and
>more if folks are interested.
All sounds good.
- --
"It's too dark to put the keys in my ignition"
