To:
ietf-provreg@cafax.se
From:
Patrick <patrick@gandi.net>
Date:
Thu, 17 Jan 2002 20:58:39 +0100
Content-Disposition:
inline
In-Reply-To:
<20020117175307.29926.qmail@www3.nameplanet.com>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mutt/1.3.24i
Subject:
Re: <info> Command and authInfo
On Thu, Jan 17, 2002 at 05:53:07PM -0000, asbjorn.rrp@theglobalname.org took time to write: > On Thu, 17 Jan 2002 16:43:20 +0100 Patrick <patrick@gandi.net> wrote: > >IMNSHO auth info should enable someone having it to make > >modifications (that is update at least, maybe delete and renew) > >through any other ways (other Registrars, or even the Registry > >directly). Protocols should make that possible, and then > >local policies should specify if it is to be used or not, and if yes, > >how. > > I can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar. > > Scenario: Registrar A is extremely cheap so I register my domain there, but registrar B has a great user interface for maintaining and modifying objects, so I use their interface instead of registrar a's. Registrar A will get my money, whereas registrar B has to do all the work for a "non-customer". I misexplained myself. I myself would not like that what I describe is possible. However I think this is a policy problem, not a protocol on. Thus the protocol should not be made so that this policy is not possible, if the Registry of a given TLD chooses to do so. There are Registries dealing with customers directly. .uk comes to my mind. The case of doing changes through a different Registrars might be something very interesting when one Registrars fails or has so many problems that it is not used anymore. As for your example it is flawed, since Registrar B can totally ask for a fee to change domain names handled by other REgistrar. Your money problem disappear. So my point is that we should take into account all models, and leave place for all future ones. We should not do things as they are currently in .COM/.NET/.ORG just because they are so. If the true aim of this protocol is to be generic, and not to be just a replacement of RRP, then it must not add constraints that may be problems. Patrick.