-> Modelling the Process
by "Dave Collier-Brown"
-> Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
by "David R. Conrad"
-> Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
by chris@kosh.punk.net (Christopher Ambler)
-> Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
by Michael Dillon
----------------------------------------------------------------------
Date: 22 Aug 1996 00:22:08 -0700
From: Simon Higgs
Subject: Re: yet more unworkable distributed design
At 10:34 PM -0700 8/21/96, Michael Dillon wrote:
>> >Then let's have a PERSON identifier that is stored at the CDB. When
>> >designing the actual record layouts I favor the following technique:
>> >
>> [SNIP]
>>
>> How is this different from the whois contact id?
>
>The whois contact id is internally generated within the Internic. I'm
>suggesting a standard id code that will be used by all international TLD's
>and maintained in the CDB.
>
So why not use the InterNIC ID's? NSI have no proprietry right to them.
Plus, if and when .COM et al become shared, every single InterNIC whois
contact will need to be renumbered to the shared scheme.
There are two choices:
1. Create a new scheme and make InterNIC renumber later. This creates a
big headache when the time comes.
2. Use InterNIC ID's and force InterNIC to honor those created by other
registries. This more or less forces InterNIC into sharing at least
a minor portion of the registration process right from the start.
The less painful is going to be 2.
>> OK, so the update requested can be verified via email before it's
>> completed. Which is exactly why the key could be the From: address (or PGP
>> or any other method).
>
> From addresses can be forged
>And most people will never use a PGP key.
>
You're talking in circles, and appear to have completely missed the point.
The method the key uses is more or less irrelevent, but the necessity for a
key of some kind isn't. If the registry sends a verify message to the From:
address, and it is replied to in the correct manner, then it's authentic.
This is the same method First Virtual use. You can't forge it.
_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...
----------------------------------------------------------------------
Date: 22 Aug 1996 12:42:58 -0700
From: "Richard J. Sexton"
Subject: Re: yet more unworkable distributed design
At 10:34 PM 8/21/96 -0700, you wrote:
>On Wed, 21 Aug 1996, Simon Higgs wrote:
>And most people will never use a PGP key.
They will if they want to change THEIR nameserver...
----------------------------------------------------------------------
Date: 22 Aug 1996 12:43:29 -0700
From: "Richard J. Sexton"
Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
At 12:37 PM 8/21/96 -0400, you wrote:
>information gets hard. Perhaps we should abandon the old style NIC
>handles -- thoughts?
>
>Perry
Perhaps extend them, ie:
internic.net:rs79
----------------------------------------------------------------------
Date: 22 Aug 1996 12:43:36 -0700
From: "Richard J. Sexton"
Subject: Re: yet more unworkable distributed design
At 04:19 PM 8/21/96 -0700, you wrote:
>On Wed, 21 Aug 1996, Simon Higgs wrote:
>
>> We need the handles to identify a specific record in a specific table.
>
>Sequentially assigned numbers will do that.
Yes, but not as well.
NEXT
----------------------------------------------------------------------
Date: 22 Aug 1996 13:03:11 -0700
From: Michael Dillon
Subject: Re: yet more unworkable distributed design
On Thu, 22 Aug 1996, Richard J. Sexton wrote:
> At 10:34 PM 8/21/96 -0700, you wrote:
> >On Wed, 21 Aug 1996, Simon Higgs wrote:
> >And most people will never use a PGP key.
>
> They will if they want to change THEIR nameserver...
No they won't. They will bitch and complain to whoever will listen and the
whole pool of shared-TLD registries will be tarred with the same brush as
the Internic. There is no point in doing shared-TLD's unless it addresses
the needs of the customers, i.e. end users.
Most people don't understand this PGP stuff, don't see why they need it,
don't know where to buy it for their email program, don't understand how
to use it and don't remember where they put their PGP key when they
upgraded to a new notebook. PGP is *NOT* for the masses, at least not
anytime soon.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 22 Aug 1996 13:46:39 -0700
From: Kent Crispin
Subject: Re: yet more unworkable distributed design
Michael Dillon allegedly said:
>
> On Thu, 22 Aug 1996, Richard J. Sexton wrote:
>
> > At 10:34 PM 8/21/96 -0700, you wrote:
> > >On Wed, 21 Aug 1996, Simon Higgs wrote:
> > >And most people will never use a PGP key.
> >
> > They will if they want to change THEIR nameserver...
>
> No they won't. They will bitch and complain to whoever will listen and the
> whole pool of shared-TLD registries will be tarred with the same brush as
> the Internic. There is no point in doing shared-TLD's unless it addresses
> the needs of the customers, i.e. end users.
>
> Most people don't understand this PGP stuff, don't see why they need it,
> don't know where to buy it for their email program, don't understand how
> to use it and don't remember where they put their PGP key when they
> upgraded to a new notebook. PGP is *NOT* for the masses, at least not
> anytime soon.
Of course, people requesting domain names generally aren't "the
masses", by any stretch. But even so, I agree with Michael. The
authority controlling a domain will be mediated through
current standard business practices -- phone, snailmail, email, and
human signatures. I would guess that it will be on the order of 10
years before there is a PK infrastructure in place.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 22 Aug 1996 14:53:13 -0700
From: Simon Higgs
Subject: Re: yet more unworkable distributed design
At 1:44 PM -0700 8/22/96, Kent Crispin wrote:
>Of course, people requesting domain names generally aren't "the
>masses", by any stretch. But even so, I agree with Michael. The
>authority controlling a domain will be mediated through
>current standard business practices -- phone, snailmail, email, and
>human signatures. I would guess that it will be on the order of 10
>years before there is a PK infrastructure in place.
>
You mean like the ability to have individualized key certificates in
current versions of Netscape Navigator & Internet Explorer? It's (maybe) 10
months, not ten years. And that puts us right on schedule.
The following authentication schemes that are working right now are
RSA-key, reply-authenticated email, and paper signature. What exactly is
the problem with adopting them?
_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...
----------------------------------------------------------------------
Date: 22 Aug 1996 15:36:21 -0700
From: Kent Crispin
Subject: Re: yet more unworkable distributed design
Simon Higgs allegedly said:
>
> At 1:44 PM -0700 8/22/96, Kent Crispin wrote:
>
> >Of course, people requesting domain names generally aren't "the
> >masses", by any stretch. But even so, I agree with Michael. The
> >authority controlling a domain will be mediated through
> >current standard business practices -- phone, snailmail, email, and
> >human signatures. I would guess that it will be on the order of 10
> >years before there is a PK infrastructure in place.
> >
>
> You mean like the ability to have individualized key certificates in
> current versions of Netscape Navigator & Internet Explorer? It's (maybe) 10
> months, not ten years. And that puts us right on schedule.
>
> The following authentication schemes that are working right now are
> RSA-key, reply-authenticated email, and paper signature. What exactly is
> the problem with adopting them?
None, that I can see. I was replying to a statement by Michael
(attached below, in case you've forgotten the thread), to the effect
that we couldn't *require* PK authentication of domain name owners.
To clarify my statement -- I don't believe that we will have a
sufficient PK infrastructure that we can *require* a customer to
maintain a digital signature for many years to come. As you say,
technically it is available now. But the question I was addressing is
whether a registry can *require* a customer to maintain one.
I guess the model being contested here is this: the customer receives
a secret key (or a certificate of some sort) for the domain name, and
uses a secret key to prove to another registry that the domain name
can be moved.
IMHO, this is completely unrealistic, and it would be downright
foolish to build it into the desig. To paraphrase you, mechanisms to
handle these issues are completely in the business and legal world.
Attached message:
Michael Dillon allegedly said:
>
> On Thu, 22 Aug 1996, Richard J. Sexton wrote:
>
> > At 10:34 PM 8/21/96 -0700, you wrote:
> > >On Wed, 21 Aug 1996, Simon Higgs wrote:
> > >And most people will never use a PGP key.
> >
> > They will if they want to change THEIR nameserver...
>
> No they won't. They will bitch and complain to whoever will listen and the
> whole pool of shared-TLD registries will be tarred with the same brush as
> the Internic. There is no point in doing shared-TLD's unless it addresses
> the needs of the customers, i.e. end users.
>
> Most people don't understand this PGP stuff, don't see why they need it,
> don't know where to buy it for their email program, don't understand how
> to use it and don't remember where they put their PGP key when they
> upgraded to a new notebook. PGP is *NOT* for the masses, at least not
> anytime soon.
>
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 22 Aug 1996 15:45:18 -0700
From: John Leslie
Subject: Re: New Non-Shared TLD's Create More Monopolies
Kent Crispin wrote:
>
> A database that is the single, central, authorative repository of all whois
> data, and all SLD registrations is over my warning threshold for
> abuse potential. It is also a risk for single point of failure.
Agreed.
> Frankly, I would prefer a solution that does not have a central CDB of
> any type. I would trade off a fair amount of short term simplicity,
> reliability, and performance to meet that goal, because I think in the
> long run it actually is a better model -- registrations should
> continue without a hitch if an earthquake sank IANA and its computers
> beneath the ocean.
I really think it's asking a bit much to say "without a hitch". Would
you settle for "within 24 hours"?
I'd like to see the CDB manage a DNS referring inquiries to the
appropriate registry; mirrored by a bunch of sites, so that if an
earthquake sank it the domain-lookup services would continue without
a hitch.
Registrations, however, would need to stop until the mirror sites
could agree on what replacement site to mirror. This seems to me an
acceptable risk...
Also, when I speak of it being a "light" CDB, I mean it. I don't
want the CDB to be authoritative about anything but the association
between domain name and currently-responsible registry. If one or
more registries wants to contract with the CDB to serve up more info
than a simple redirection, that's between the two of them -- no other
registry should need to know or care about that arrangement.
I can see how it's academically more satisfying to have a "CDB-less"
arrangement; but to be honest, all the ways of doing that increase the
complexity of the system, either at the registry level or the end-user
inquiry level. IMHO, we're better off with something we can implement
without writing new code.
- --
John Leslie
----------------------------------------------------------------------
Date: 22 Aug 1996 17:04:44 -0700
From: Simon Higgs
Subject: Re: yet more workable distributed design
At 3:34 PM -0700 8/22/96, Kent Crispin wrote:
>Simon Higgs allegedly said:
>>
>> At 1:44 PM -0700 8/22/96, Kent Crispin wrote:
>>
>> >Of course, people requesting domain names generally aren't "the
>> >masses", by any stretch. But even so, I agree with Michael. The
>> >authority controlling a domain will be mediated through
>> >current standard business practices -- phone, snailmail, email, and
>> >human signatures. I would guess that it will be on the order of 10
>> >years before there is a PK infrastructure in place.
>> >
>>
>> You mean like the ability to have individualized key certificates in
>> current versions of Netscape Navigator & Internet Explorer? It's (maybe) 10
>> months, not ten years. And that puts us right on schedule.
>>
>> The following authentication schemes that are working right now are
>> RSA-key, reply-authenticated email, and paper signature. What exactly is
>> the problem with adopting them?
>
>None, that I can see. I was replying to a statement by Michael
>(attached below, in case you've forgotten the thread), to the effect
>that we couldn't *require* PK authentication of domain name owners.
>To clarify my statement -- I don't believe that we will have a
>sufficient PK infrastructure that we can *require* a customer to
>maintain a digital signature for many years to come. As you say,
>technically it is available now. But the question I was addressing is
>whether a registry can *require* a customer to maintain one.
>
>I guess the model being contested here is this: the customer receives
>a secret key (or a certificate of some sort) for the domain name, and
>uses a secret key to prove to another registry that the domain name
>can be moved.
>
>IMHO, this is completely unrealistic, and it would be downright
>foolish to build it into the desig. To paraphrase you, mechanisms to
>handle these issues are completely in the business and legal world.
>
Ahem... the whole point of providing a field for a key in a particular
record is that it *COULD* get used, not that it MUST get used. It's really
stupid to leave it out of the design. Record hi-jacking is a legal
liability for the registry. Two fields in the database and it becomes the
applicants problem.
Remember, it's not the job of the registry to provide the key, it's the job
of the applicant. If they don't, no big deal, except the record is not
secure. All the registry has to do is perform due diligence in verifying a
key while performing an update. Guardian does this job right now, and uses
two fields - one to describe the type of key, and the other for the key
itself. Let's include this model in pencil and move on.
_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...
----------------------------------------------------------------------
Date: 22 Aug 1996 17:34:38 -0700
From: Kent Crispin
Subject: Re: yet more workable distributed design
Simon Higgs allegedly said:
>
>
> Ahem... the whole point of providing a field for a key in a particular
> record is that it *COULD* get used, not that it MUST get used. It's really
> stupid to leave it out of the design. Record hi-jacking is a legal
> liability for the registry. Two fields in the database and it becomes the
> applicants problem.
>
> Remember, it's not the job of the registry to provide the key, it's the job
> of the applicant. If they don't, no big deal, except the record is not
> secure. All the registry has to do is perform due diligence in verifying a
> key while performing an update. Guardian does this job right now, and uses
> two fields - one to describe the type of key, and the other for the key
> itself. Let's include this model in pencil and move on.
OK -- Of course you realize that I think a central database of this
stuff is a bad idea, and I will still try to find a better one. But
onward! :-)
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 22 Aug 1996 18:12:04 -0700
From: Michael Dillon
Subject: Re: yet more unworkable distributed design
On Thu, 22 Aug 1996, Simon Higgs wrote:
> The following authentication schemes that are working right now are
> RSA-key, reply-authenticated email, and paper signature. What exactly is
> the problem with adopting them?
This is just a bunch of meaningless technical jargon to most people. The
business people who make the decisions and order the domain names just
don't understand this stuff and too many of their technical "experts"
don't have a clue about it either. Only Internet cultists know and use
this kind of stuff.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 22 Aug 1996 18:12:15 -0700
From: Michael Dillon
Subject: Re: New Non-Shared TLD's Create More Monopolies
On Thu, 22 Aug 1996, John Leslie wrote:
> > A database that is the single, central, authorative repository of all whois
> > data, and all SLD registrations is over my warning threshold for
> > abuse potential. It is also a risk for single point of failure.
>
> Agreed.
Having a single point of failure is a GOOD THING (tm). This makes it easy
to secure that single point and guard against having it fail utterly and
completely.
> > registrations should
> > continue without a hitch if an earthquake sank IANA and its computers
> > beneath the ocean.
>
> I really think it's asking a bit much to say "without a hitch". Would
> you settle for "within 24 hours"?
No! 20 minutes at the absolute maximum. The backup system should be live
and in place just waiting for a human to confirm that it REALLY is
a catastrophic failure that requires the backup to take over.
On the other hand you could probably develop a failover protocol between
the two CDB sites that would be able to hand off in much less time
although it is still good to have some sort of damping algorithm to
prevent a hot potato situation.
> I'd like to see the CDB manage a DNS referring inquiries to the
> appropriate registry; mirrored by a bunch of sites, so that if an
> earthquake sank it the domain-lookup services would continue without
> a hitch.
In fact, the domain-lookup services should not be handled by the true
central database site at all.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 22 Aug 1996 20:02:59 -0700
From: "Dave Collier-Brown"
Subject: Modelling the Process
[oops, mailtool doesn't like forwarding mime messages...]
- ----- Begin Included Message -----
>From hobbes.ss.org!davecb@lethe.ss.org Thu Aug 22 19:47:32 1996
Return-Path:
Received: from lethe.uucp by hobbes.ss.org (4.1/SMI-4.1-1)
id AA00312; Thu, 22 Aug 96 19:47:30 EDT
Received: from ntigate.rich.nt.com by ss.org with smtp (Smail3.1.29.1) id m0uteC0-00024XC; Thu, 22 Aug 96 14:09 EDT
X400-Received: by mta NT.COM in /PRMD=NT/ADMD=MCI/C=US/; Relayed;
Thu, 22 Aug 1996 18:06:16 +0000
X400-Received: by /PRMD=NT/ADMD=MCI/C=US/; Relayed;
Thu, 22 Aug 1996 17:55:51 +0000
X400-Received: by /PRMD=NT/ADMD=MCI/C=US/; Relayed;
Thu, 22 Aug 1996 17:57:48 +0000
X400-Received: by /PRMD=NT/ADMD=MCI/C=US/; Relayed;
Thu, 22 Aug 1996 17:57:47 +0000
Date: Thu, 22 Aug 1996 17:57:47 +0000
X400-Originator: davecb@hobbes.ss.org
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=NT/ADMD=MCI/C=US/;<321C9F9B.794BDF32@hobbes.ss.org]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Modelling the...
From: David Collier-Brown
Sender: davecb@hobbes.ss.org
Message-Id: <321C9F9B.794BDF32@hobbes.ss.org>
To: "Collier-Brown, David"
Cc: David Collier Brown
Subject: Modelling the Process
Organization: The Orville Torpid family and friends
X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.4 sun4m)
Mime-Version: 1.0
X-Url: file:/tmp_mnt/net/nbrws3e5/export/home/davecb/projects/done/tld/Model.html
Content-Type: multipart/mixed; boundary="------------15FB748359E2B6001CFBAE39"
Status: R
This is a multi-part message in MIME format.
- --------------15FB748359E2B6001CFBAE39
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well, it's time t ocomment on requirements next (as I promised
all too many moons ago). This is the partially-proofread example
As with the appreciation, I'll upload it to a web site presently.
- --dave
- --
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | davecb@hobbes.ss.org, unicaat.yorku.ca
N2M 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
- --------------15FB748359E2B6001CFBAE39
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="Model.html"
Modelling the Process
Introduction
This is a background note on what can happen between a customer, a registry and a domain-name, from the point of view of a coordinating database service (a CDB).
It provides enough data to start discussion of policy issues, and given a decision on them, to start modelling what the CDB must be able to do. In other words, start specifying the requirements for a CDB.
This is a technique blatantly stolen from Dr. Jonathan Ostroff of York University's course on designing safety-critical systems, but without the rigor and expertise Jonathan could bring to bear. In fact. it's a subset of the real thing: the author admits to being no more than an interested amateur.
Modeling
We represent a customer by C, a registry by R and a domain-name by d, and claim that we take one each of C, R and d to create a new relationship in the coordinating database (CDB). To represent the result we say (C,R,d).
Having this relation is the desired state. We get into it by joining the three with a successfull allocation from the cloud of unclaimed names and a contract of a simple sort. As a diagram this is
C R d ---> (C,R,d)
This is the easy case, and one which has been discussed to a reasonable degree in the mailing list. The hard cases involve the dissolution of this relationship and their recreation. There are three ways we can break up the three-tuple: (C,R) d, (C,d) R, C (R,d) and C R d.
C R d is just our starting state, and is the ``normal'' dissolution. The others are (C,d) R, a customer leaves a registry with ``his'' domain under his arm, C (R,d), a customer abandons his domain name to a registry (or is tossed out without it for non-payment), and (C,R) d, a domain is pried out of the hands of a registry and customer, leaving they standing there looking stunned.
This enumeration raises the first question: should the domain name go with the customer, the registry or neither if one or the other leaves? This is the first policy question I mentioned above.
I'm going to prejudge it for a moment, purely to be able to draw a pretty picture farther down the page, and pretend that we've let it go with the customer. This raises a second policy question, and the question of time: Should a domain remain with a customer who lacks a registry? And if so, forever or for some specific time?
The Nice-Looking Diagram
Given this much background, I can finally draw the picture I doodled on the coffee-table:
The blob in the middle is the desired state of the world. Each arc is an action, each of which takes some definite time. We can then represent two outcomes of a customer leaving: the error state after unit-of-time t or the making of a new relationship with registry R' (r-prime).
Since this mess is of very moderate size, we can analyze it by exhaustively listing the outcomes, annotating them with what the CDB needs to do on each and what to do on error, including on timeout.
And then we can specify what the ``safe'' transitions are, by stating an answer to all the policy questions. The result is a from of specification of the correct functioning of the CDB.
And I can relax the prejudice I was showing above and consider both (C,d) R and C (R,d).
The States, Transitions and their Effects
Successfull Domain-Name Allocation
C,R,d --> (C,R,d)
The result of this is
CDB creates the record
DNS and whois data is recorded
the domain name is no longer available for claim
Unsuccessfull Allocation
C,R,d--> no change
The name is already taken, the customer needs to select another.
A Customer Leaves with his Domain
(C,R,d) --> (C,d) R
CDB takes R out of record, which now relates only C,r
Question:
Does the DNS data stays the same?
point to R?
point to C?
point to hyperspace?
disappear?
