Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

[Patrick <patrick@gandi.net>]

On Wed, Feb 14, 2001 at 06:58:02PM -0500, Sheer El-Showk took time to write:
> > I do not understand why here we try to let the registrant do things
> > wirthout going through a Registrar. Why make the registration of
> > nameserver a different case ?
> > 
> > The same problem exist in other part : like for contacts in the thick
> > registry. How do you handle them ? Someone register a contact through
> > a given Registrar. To help avoid the actual handle problems (each
> > different for a Registrar), they should be unique. Who can change
> > them ? Through wich Registrar ?
> 
> 
> Well, what I had mentioned, and what I think would be a good idea if we
> could find a system that would withstand registrant carelessnes (I'll

It is even more than a good idea : it is _mandatory_ in my eyes.
Other than that someone (the registry ? every registrar ?) will have
to support users and answer their request, when they forget their
password/PGP key/whatever, etc...
And that happens, a _lot_.

If a Registrant can do modifications through any Registrar, the
burden of support is on everyone involved (all Registrars). It might
be quite a lot of work. And Registrars will not see benefit to do it,
since someone can use a Registrar to make its modifications, which
will not mean that the Registrar will earn money with this. That is,
each Registrar will need to give few basic free services, not only to
their customers, but to anyone having registered a domain, even with
another Registrar.

> The problem with this is registrant carelessness.  Not that many people
> use PGP, and its not generally a very good idea to depend on non-technical
> people to safegaurd their data well (not that technical people are good at
> it, but at least they know when its important).  There would conceivably
> be a lot of cases of registrants losing floppies or hard disks with the
> only copy of their private key and hence losing their "proof of
> ownership" of their domains.

Exactly. Even more Registrants will forget their passphrase. Or they
will use bad methods to protect their key, and it will be stolen, and
such... If we go that route, things like that _must_ be taken into
account at the beginning.

> There is a second, and in my opinion, extremely important justification of
> this passthrough key system.  Registrar's aren't necassarily very good at
> maintaining their data integrity, and, as business, are apt to go belly-up
> every once in a while.  This leaves the registry with a lot of domains but

That is true. That is why the ICANN contract for .com/.net/.org
Registrars mentions that. Each registrar must take care of this, so
that its domains are going to another registrar in case of bankruptcy
or such, without noticeable change for the Registrants.

But that leads to a question.
I register a domain with Registrar A.
Then I decide to change the owner of the domain, by doing so through
Registrar B which will authentify me with my PGP key or such.
How are modifications going back to Registrar A in case of a thin
Registry ?
Same thing for change of contacts, nameservers, etc...

Does that mean that Registrars will need to share a common database ?
In that case I think it is more like a thick Registry.
Or will each Registrar have complete read/write access to other
Registrar databases ?

> without any idea of user ownership (in the thin registry model
> anyway) which is a Very Bad Thing (tm).  So, it would be nice if

Yes. Same thing, Registrar must be able to give all details to the
Registry. Date have to be stored securely with frequent backups.

> registrants could carry around some kind of uncompromisable proof of
> ownership of a domain.

Yes, but the problem lies down to : whatever proof you have (PGP key,
certificate, etc...), two things can happen :
- you can forget/destroy it
- someone can steal it from you.

The business in which you need this proof must take into account this
events and provide mecanisms to correct the situation.
Like I said, not an easy task.

Patrick.