<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] Proliferation of registrar locks
- To: Nikolaj Nyholm <nikolajn@xxxxxxxxx>
- Subject: Re: [registrars] Proliferation of registrar locks
- From: "Marcus Faure" <faure@xxxxxxxxxxx>
- Date: Sat, 13 Nov 2004 14:46:16 +0100 (CET)
- Cc: ross@xxxxxxxxxx, "Paul Lecoultre(CORE secretariat)" <secretariat@xxxxxxxxxxx>, Registrars@xxxxxxxx
- In-reply-to: <2F15A97500CFA0469C9BACC2041F8AC70632D079@aries.dk.speednames.com> from Nikolaj Nyholm at "Nov 12, 2004 11:02:17 pm"
- Sender: owner-registrars@xxxxxxxxxxxxxx
Hi all,
other than you I am sure that this IS a step backward. Let's just look at
goals and the results:
Goal: We wanted a standardized transfer process
Result: We do not have it. While the transfer itself is standardized now,
almost all registrars have now locked their domains, forcing the
customer into a non-standardized "have my domain unlocked" process
Goal: We wanted transfers to become easier
Result: We can not check authinfos before we went through the FOA process.
If the FOA is successfully returned and the authinfo is incorrect,
the whole process has to be restarted.
From the customer perspective, a transfer is now at least a 4-step
process: unlock the domain, initiate the transfer, reply to FOA on
gaining side, reply to FOA on losing side
Goal: We wanted to authinfos to be the solution for transfer problems
Result: Authinfos are now not only useless, they effectively make the
process more complicated. Speaking of that, I would like to remind
you that for example the NSI webinterface does not know about
authinfos at all. You have to know they exist and you have to contact
customer support to have it sent (by email) to your address. We
have documented cases where after five customer requests the domain
holder still has not received the authinfo.
So where is the advantage?
>From my point of view, we should enforce the following:
- Enforce the usage of authinfos for all gTLDs
- Use Authinfos as a valid authorization
- Prohibit the "protection" of domains unless the customer explicitly wished
to have it.
But it problably takes another 3 1/2 years until we are there :-(((
Yours,
Marcus
CORE Council of Registrars
> Ross,
>
> I am not in any way claiming this is a step backward. Indeed, I agree that
> it is a clear improvement on the former policy (if you can call it a policy
> at all).
>
> However, as you even seem to claim yourself ("NSI's perverted take on new
> ICANN Transfer Policy":
> http://www.byte.org/blog/_archives/2004/9/10/138240.html), the
> Registrar-Lock is a loophole the size of Texas.
>
> CORE, who Paul represents, was one Registrar who at one would only authorize
> a transfer if accepted by the 'sponsoring' reseller. CORE resellers were
> free to define the format of the authorization from the Registrant and when
> to honor the authorization request.
> While I trust that CORE won't replicate such practice, how would it
> translate to a Registrar-Lock removal?
>
> While I agree that there are now mechanisms for resolving disputes and
> misuses, I don't believe it will install trust in the system with
> Registrants, in which case we all lose once again.
>
> I do hope (and expect!) that it will be a well debated subject in Cape Town.
> I'm sure we can all bring the first examples of misuse to the table then.
>
> /n
>
>
> > -----Original Message-----
> > From: Ross Wm. Rader [mailto:ross@xxxxxxxxxx]
> > Sent: 12. november 2004 22:07
> > To: Nikolaj Nyholm
> > Cc: Paul Lecoultre(CORE secretariat); Registrars@xxxxxxxx
> > Subject: Re: [registrars] Proliferation of registrar locks
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 12/11/2004 3:52 PM Nikolaj Nyholm noted that;
> > | Ross,
> > |
> > | You can't seriously claim that the transfer policy is not
> > open to misuse.
> >
> > I'm not making that claim. If pressed, I would make the claim
> > that this
> > policy is a far sight better than what we had yesterday.
> >
> > | Stating that "the Registered Name Holder [must be] provided with the
> > | reasonable opportunity and ability to unlock the domain
> > name prior to the
> > | Transfer Request", is *not* very clear.
> >
> > What is unclear about it? This is the same question I asked Paul.
> >
> >
> > | As I remember it, (losing) Registrars have previously
> > successfully argued
> > | that requiring a fax with a copy of incorporation documents and/or
> > driver's
> > | license is a "reasonable opportunity and ability" to authorize a
> > transfer.
> >
> > Authorizing a transfer and unlocking a domain name are two different
> > things. I don't remember the argument you refer to, but
> > insofar as this
> > policy is concerned, if the gaining registrar is in possession of a
> > valid FOA that's backed up by those documents, then yes - it would be
> > appropriate to consider the transfer request as being
> > "authentic"...but
> > there is no notion of "reasonable opportunity and ability" as far as
> > authorizing transfer requests go. Either they are, or they
> > are not - and
> > in all cases, without fail, the gaining registrar must receive
> > authorization from the registrant prior to initiating the request.
> >
> > | C'mon Ross, we can do better.
> >
> > Surely we can, but at the same time, lets not fall prey to the now
> > mythical misunderstanding of this new policy. The community seems to
> > completely ignore the fact that there is old policy that this
> > new policy
> > is replacing - and that this new policy closes many of the
> > old loopholes
> > and insecurities of the old policy. This new policy is simply an
> > evolution of the policies we've been using for the last five years.
> > - --
> >
> >
> >
> >
> > ~ -rwr
> >
> >
> >
> > Contact info: http://www.blogware.com/profiles/ross
> > Skydasher: A great way to start your day
> > My weblog: http://www.byte.org
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.3-nr1 (Windows XP)
> >
> > iD8DBQFBlSXZ6sL06XjirooRAgm5AKCHC6B7OltnCmHZMd3+ur7HJB5DWgCfVUFX
> > +WZvh3eiBfGgzETnadcnuK8=
> > =R50B
> > -----END PGP SIGNATURE-----
> >
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|