ICANN/GNSO GNSO Email List Archives

[registrars]


<<< 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 >>>