[registrars] Registrar Transfer Procedures

["Dan Halloran" <halloran@icann.org>]

Mike,

Congratulations to you and the rest of the constituency for the recent
successful election.  I look forward to continuing to work with you and the
other newly-elected constituency representatives.

I agree that the need to ensure that consumers' wishes are carried out is a
key issue facing the constituency today.  Placing consumers' wishes at the
forefront of the constituency's ongoing discussions about transfers will
give the constituency the opportunity to enhance the public confidence that
will permit private sector self-regulation to succeed.

From ICANN's point of view, the basic issue here should be ensuring that the
consumer gets what the consumer wants: if the consumer wants to transfer,
the consumer should be able to transfer; if the consumer does not want to
change registrars, his registration should not be transferred.

ICANN receives complaints about breakdowns on both sides of this equation:
about registrants who want to transfer, but can't; and about domains that
are transferred without the registrant's informed authorization.

Many consumers have been complaining to us recently that they want to
transfer their name from Network Solutions to another registrar, but they're
having trouble.  Usually they're frustrated because NSI has denied their
request to transfer either because their account is "not in a paid status,"
or because the consumer supposedly failed to follow NSI's transfer
authorization verification scheme.  Also, the registrars these consumers are
trying to transfer to have complained to ICANN.

On the other side of the equation, we have also received complaints from
various sources about transfers that are solicited or take place without the
consumer's informed express authorization.  These complaints fall into
several categories: hijacking/hacking, unauthorized transfers, deceptive
renewal/transfer solicitations, and other miscellaneous situations.  I can't
give you an exact breakdown of the complaints we receive because we don't
categorize them along those lines.

Complaints to ICANN about hijacking are rare.  By hijacking I mean cases
where one person tries to get control of another person's domain, often just
before, during or after a registrar transfer.  We often only hear about
these cases second-hand because they are handled by the registrars involved.
For a variety of other reasons, we may not hear about these situations every
time they occur.  Still, with all respect, I don't think it's right to say
that hijacking is not relevant to this discussion.  The way I see it,
preventing domain hijacking is one of the primary reasons for requiring the
gaining registrar to obtain the registrant's express authorization before
initiating a transfer.

The other important reason for requiring the registrant's express
authorization is to prevent registrars from initiating transfers without the
consent of the registrant.  NSI Registrar recently made public their
concerns regarding possible "slamming" as a justification for their
implementation of auto-nacking of unconfirmed transfer requests.
Register.com has long been using the same auto-nack system, and they've
raised similar consumer protection concerns.

Some have alleged that this purported concern about potential hijacking and
slamming is just a pretext for instituting roadblocks to protect market
share.  If these allegations were true, that would obviously be as troubling
as any alleged "slamming" that may be taking place.  As I stated above,
consumers should be allowed to transfer when they want to, and should be
protected from transfers they didn't authorize.

ICANN's position therefore has been that where the losing registrar has no
concern about the gaining registrar's transfer authorization system, it
should not decline a transfer request based solely on the failure of a
consumer to respond to a request by the losing registrar to confirm the
authorization.  Likewise, a losing registrar should not be required to
automatically accept transfer requests from a registrar without verification
when the losing registrar has legitimate doubts about the authenticity of
the registrant's authorization to transfer.

We are pleased that both register.com and NSI have moved away from their
previous stance to a position where they have agreed to auto-ack transfer
requests from gaining registrars who employ what they consider to be careful
transfer authorization systems.  This is at least a good start.

We are also pleased to see that Tucows and other registrars are recognizing
that a solution to the transfer issue should involve the constituency coming
together to define common customer authorization standards for this
inter-registrar domain name transfers process.  Hopefully all interested
registrars will contribute to this discussion in good faith.  If some
registrars have specific concerns about others' practices, now is probably a
good time to raise them.

I hope to be able to support the constituency with its self-regulation
mission, both with regards to this transfer issue and also with tackling
other important issues such as the adoption of a prohibition on registrar
warehousing/speculation and a uniform policy for handling expired
registrations.

Thanks again for your efforts toward resolving this issue.  Please feel free
to contact me if there is anything I can do to be of assistance.

Best regards,
Dan Halloran