<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Proliferation of registrar locks
- To: ross@xxxxxxxxxx
- Subject: RE: [registrars] Proliferation of registrar locks
- From: Nikolaj Nyholm <nikolajn@xxxxxxxxx>
- Date: Fri, 12 Nov 2004 23:02:17 +0100
- Cc: "Paul Lecoultre(CORE secretariat)" <secretariat@xxxxxxxxxxx>, Registrars@xxxxxxxx
- Sender: owner-registrars@xxxxxxxxxxxxxx
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
>>>
|