[registrars] MdR-Agenda.htm

[Elana Broitman <ebroitman@register.com>]

 <<MdR-Agenda.htm.htm>> 

Dear Mike and Tim - the minutes of the MdR meeting have a mistake in them.
In discussing the transfer issue, the old proposal - not the final September
19th one co-authored by Ross and me - is posted.

Also, the historical documents include a number of emails and postings, but
not the email from me outlining outstanding issues.  It is important to
include this email because these issues have become part of the NC TF
agenda.  It was also meant to provide the Register.com position. 

For ease of reference, I have copied and pasted below that email.  To
reiterate our position, Register.com supported and backed the statement of
principles that we co-authored with Tucows.  At the same time, we outlined
key issues that the document did not address.  Therefore we took a position
of abstaining from voting - because we wanted to be supportive of the
principles, while stating that they left significant policy gaps.
Abstention from the vote was the fairest way to signal this position.  

Regards, Elana

 <<< <msg01182.html> Chronological Index <mail20.html> >>> <msg01184.html>
<<< <msg01182.html> Thread Index <thrd21.html> >>> <msg01190.html>
[registrars] Outstanding issues on Registrar Transfers To: "mike palage"
<michael@palage.com <mailto:michael@palage.com>>  Subject: [registrars]
Outstanding issues on Registrar Transfers  From: "Elana Broitman"
<ebroitman@register.com <mailto:ebroitman@register.com>>  Date: Thu, 20 Sep
2001 13:20:32 -0400  Cc: <registrars@dnso.org <mailto:registrars@dnso.org>>
Importance: Normal  Sender: owner-registrars@dnso.org
<mailto:owner-registrars@dnso.org>   Mike and all - I am pleased that we
were able to reach agreement on many issues, such that the RC now has a
single document setting out Registrar Transfer principles and practices to
consider.  Despite our efforts to bridge all gaps, we were left with a few
difficult, but crucial, issues to determine.  Some of these go to the heart
of defining minimum consumer protection standards.  Below, are the issues
and our positions on such issues.  Because they are critical, the RC should
vote on them in addition to the document:   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).

MdR-Agenda.htm.htm