RE: [registrars] Outstanding issues on Registrar Transfers

["Michael D. Palage" <michael@palage.com>]

Elana:

Your request to re-open discussions on the XFER document is premature. Let
me remind you that what we are looking for is consensus and not unanimity.
If there is no consensus when the votes are tallied, then I agree that we
should return to negotiations.

Mike

P.S. I have not yet received Register.com's vote.




> -----Original Message-----
> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Elana Broitman
> Sent: Sunday, October 07, 2001 4:34 PM
> To: registrars@dnso.org
> Subject: [registrars] Outstanding issues on Registrar Transfers
>
>
> In view of the many emails, such as from Larry, Bhavin, and Bruce
> regarding
> the transfer policies, it appears that there remain some significant
> outstanding issues for the transfer process.  It raises the question of
> agreeing on a document before dealing with these significant
> issues that may
> change the transfer principles.  I want to raise that as a
> question ahead of
> the Tuesday call.  I also want to resend the list of issues that I thought
> remained outside the document, below.
> Regards, Elana
>
>
> 1)	Definition of individual who has the apparent authority to
> legally bind
> the Registered Name holder.
>
> The Registry Agreement and ICANN's statements do not clarify this term.
> Yet, it is often the crux of the issue and there is often a
> difference among
> registrars regarding the definition of "apparent authority."  Some
> registrars consider only the registrant or administrative contact to be
> authoritative. Others may allow billing, technical, or other contacts to
> serve as authorized representatives for the purpose of granting apparent
> authority.  Yet others allow resellers to provide apparent authority.  We
> could draft a list of authorized contacts, but that runs the risk of
> unnecessarily limiting some registrar's legitimate definition or business
> model.
>
> However, there clearly needs to be some standard, so that we do not have a
> situation where conflicting transfer instructions are sent on behalf of a
> registrant. Just as the IRDX document has a procedure pursuant to which a
> gaining registrar refers to the Whois of the losing registrar in order to
> verify a transfer request, similarly the gaining registrar must
> refer to the
> apparent authority recognized by the losing registrar in the initial
> registration process in order to obtain authorization for the
> transfer.  In
> other words, if an admin contact was the apparent authority during
> registration, then the individual holding that position should
> authorize the
> transfer or at the very least authorize the new "authority."  This would
> allow for an objective standard while retaining flexibility.
>
> RECOMMEND: "apparent authority, as defined by the Losing Registrar's
> practices"
>
>
> 2)	Process for Transfers initiated by Indirect Partners of Gaining
> Registrars.
>
> The current IRDX document allows for only 2 processes - paper and email -
> both of which rely on a direct channel from the registrar to the
> registrant.
> This WOULD NOT allow  indirect partners to initiate or process transfer
> requests.  Yet, there is no reason to stifle this business model currently
> used by many registrars, as long as appropriate protections and
> documentation are in place.
>
> RECOMMEND: Include process for transfers going through indirect channels,
> and require such processes to be authorized using the same
> documentation as
> the direct channel + evidence of a contract between the indirect
> partner and
> the registrar that obligates the indirect partner to adhere to the same
> minimum standards.
>
>
> 3)	Gaining Registrar transferring domain names back to the
> Losing Registrar
> in a case where it has been demonstrated that the Gaining
> Registrar did not
> act in accordance with the practices and processes contemplated by this
> document.  Gaining Registrar's indemnification of the Losing Registrar
> against legal recourse in such cases.
>
> This is a matter of making all parties whole after erroneous transactions.
> If registrars are to trust each other's processes so that they
> make changes
> without requiring confirmation by their customers, they and their
> customers
> must be made whole if transfers were not authorized. A gaining registrar
> that initiated and completed the transfer of a domain name without proper
> authorization must transfer the name back, and indemnify the losing
> registrar against any potential liability associated with this
> transaction.
> This entire exercise is about instilling trust in transfer processes such
> that registrars can essentially "take each other's word for it."  If a
> registrar fails that test, and is not providing for consumer protection,
> other registrars must be able expeditiously to return to checking
> with their
> registrants, at least until confidence is regained.
>
> RECOMMEND:  In cases of erroneous or unauthorized transfers, Gaining
> Registrar transfers domain name back to Losing Registrar and indemnifies
> such registrar against any potential liability.
>
> 4)	Appropriateness of Registrar Lock.
>
> Some registrars have a business model of "locking down" their customers'
> domain names - in other words, automatically nacking all
> transfers for such
> domain names without checking with the registrant.  Some registrars may do
> this only upon request by customers; others may institute such a policy
> automatically for all customers.  The "lock down" policy is
> clearly at odds
> with one of the fundamental principles motivating this document -
> to promote
> market choice.
>
> RECOMMEND: We must consider and institute the appropriate benchmarks for
> "locks."
>
>
> 5)	A requirement to authenticate or notarize some, or all, of
> the transfer
> documentation procured by the Gaining Registrar.
>
> Contracts - particularly between companies - are often
> authenticated.  It is
> not always necessary to use a notary public, but it does provide an
> important lawyer of security to rely on authentication authorities,
> particularly if the issue of "apparent authority" is unclear.
>
> RECOMMEND: Written contracts to be authenticated (e.g., in the US
> this could
> mean notarized).
>