<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] Proliferation of registrar locks
- To: Marcus Faure <faure@xxxxxxxxxxx>
- Subject: Re: [registrars] Proliferation of registrar locks
- From: "Ross Wm. Rader" <ross@xxxxxxxxxx>
- Date: Sat, 13 Nov 2004 09:45:00 -0500
- Cc: Nikolaj Nyholm <nikolajn@xxxxxxxxx>, "Paul Lecoultre(CORE secretariat)" <secretariat@xxxxxxxxxxx>, Registrars@xxxxxxxx
- In-reply-to: <200411131346.iADDkGGL022732@brian.voerde.globvill.de>
- Organization: Tucows Inc.
- References: <200411131346.iADDkGGL022732@brian.voerde.globvill.de>
- Reply-to: ross@xxxxxxxxxx
- Sender: owner-registrars@xxxxxxxxxxxxxx
- User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
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
People have continuously claimed that auth-tokens were the solution to
the problem. I've never understood this. An auth-token is just like a
passport. When you present it to someone, it allows them to ascertain
what rights the bearer has and ostensibly, if the bearer is who they say
they are. Unto itself, it is not a mechanism to convey an authorization
from the bearer to the inspector. It is just an identity document.
Auth-tokens are precisely the same in this regard. The bearer may
present one and then request a certain action be taken, but a process
must still be followed in order to carry out the process. We still need
to confirm that the bearer is who they say they are, that they have the
authority to make the request etc.
Using auth-tokens as the solution to the transfer problem would have
been the worst outcome and was never a serious option. While we may have
been able to sort out some policies that made sense to govern .info and
.biz, it would have caused a nightmare in .com, .net and likely .org.
It was never a goal to use authinfos as the solution.
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
Yes - similar to the non-standard "register my domain", "update my
nameserver" and "renew my domain" processes that we have to struggle
with now. Standardizing the transfer process and standardizing internal
registrar procedures are two very different things. I can't imagine even
attempting to try and standardize an industry-wide "unlock my name"
process. The policy provides ICANN with the capability and tools it
needs to work with registrars to ensure that their unlock processes are
accesible and useful - I think its appropriate to wait and see what
precedents and actions they take to clarify this in the coming months.
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
I'm not sure I understand this. The registrant has no obligation to
respond to a losing FOA. It is problematic that you cannot retrieve an
authinfo on a locked domain if what you are saying is correct...
So where is the advantage?
Enhanced repudiation and remediation processes, centralized enforcement
framework, clear processes, standardized processes...
--
-rwr
Contact info: http://www.blogware.com/profiles/ross
Skydasher: A great way to start your day
My weblog: http://www.byte.org
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|