ICANN/DNSO
DNSO Mailling lists archives

[nc-transfer]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-transfer] Consensus regarding Recommendations


Folks,

Please review the following to ensure that I have adequately captured the
intention of the discussion on yesterday's call concerning whether or not we
felt that consensus had been achieved on the core recommendations of the
specifics of the policy document.

Each [x] indicates a key thought or series of related thoughts and denotes,
according to the legend, what level of support each recommendation has.

Note that the vast majority of non-consensus items have already been moved
out of this category into other areas as per feedback.

Drop me a note if there are questions or corrections.

Conclusions & Recommendations
[Introductory text to be drafted]
[C]= Consensus
[NC]=No Consensus
[NS]=Not Supported
[UN]=Under Negotiation
[S]=Supported

 - Registrants must be able to transfer their domain name registrations
between registrars provided that the Gaining Registrar's transfer process
follows minimum standards and such transfer is not prohibited by ICANN or
registry policies [C].

- Implementation of these conclusions and recommendations should, wherever
possible, use existing protocols and standards [C].

 - Registrars must provide and maintain an email address for use by all
other registrars and registries where formal communications concerning the
transfer process can be sent and dealt with by the receiving Registrar [C].

 - Inter-registrar domain name transfer processes must be clear and concise
in order to avoid confusing Registrants or other stakeholders. [C]

 - The registrant must be informed of and have access to, the published
documentation of the specific transfer process of their Registrar [C]

 - In EPP-based gTLD Registries, Registrars must provide the Registrant with
the Registrant's unique "AuthInfo Code" within a reasonable period of time
of the Registrant's initial request. [C] The Task Force observes support
that this reasonable time period is 72 hours or a similarly limited period
of time. [S]

 - In EPP-based gTLD Registries, Registrars may not employ any mechanism for
a Registrant to obtain its AuthInfo Code that is more restrictive than what
they require from a Registrant to change any aspect of its contact or
nameserver information. [C]

 - The Gaining Registrar must provide the Registrant or Administrative
Contact of Record the capability to verify their intention to transfer their
domain name registration by filling out the Standardized Form of
Authorization. [C]

 - The Gaining Registrar is solely responsible for validating registrant
requests to transfer domain names between registrars.[C]

 - However, this does not preclude the Losing Registrar from exercising its
option to independently confirm the Registrant's intent to transfer its
domain name to the Gaining Registrar. [C]

 - If Losing Registrar chooses not to or cannot positively confirm the
intent of the registrant, the transfer will still go through. [C]

 - If the Losing Registrar chooses to independently confirm the intent of
the Registrant when the Losing Registrar receives notice of a pending
transfer from the Registry, the Losing Registrar must do so in a manner
consistent with the standards set forth in these recommendations of this
report pertaining to Gaining Registrars. Specifically, the form of the
request employed by the Losing Registrar must provide the Registered Name
holder with clear instructions for approving or denying the request for
authorization and a concise declaration describing the impact of the
Registrant's decision(s) including the outcome if the Registrant doesn't
respond. [C]

 - This requirement is not intended to preclude the Losing Registrar from
marketing to its existing customers through separate communications. This
requirement is intended to ensure that the form of the request employed by
the Losing Registrar is substantially administrative and informative in
nature and clearly provided to the Registrant for the purpose of verifying
the intent of the Registrant. [S/UN]

 - In the event that a Registrant has not confirmed their intent to transfer
with the Losing Registrar and the Losing Registrar has not explicitly denied
the transfer request in accordance with these recommendations, the default
action will be to allow the transfer to proceed. [C]

 - The presumption in all cases will be that the Gaining Registrar has
received and authenticated the requisite request from the Registrant or
Administrative Contact. [C]

 - In instances where the Losing Registrar does not feel that the Gaining
Registrar has obtained the requisite authorizations described in these
recommendations, the Losing Registrar may file a dispute as described in the
Reference Implementation.[C]

 - In the event of dispute(s) over payment, the Losing Registrar must not
employ transfer processes as a mechanism to secure payment for services from
a Registrant (the Losing Registrar has other mechanisms available to it to
collect payment from the Registrant that are independent from the Transfer
process.) [C]

 - In EPP-based TLDs, a Losing Registrar must not refuse to release an
"AuthInfo Codes" to the registrant solely because there a dispute between a
Registrant and the Registrar over payment.[C]

 - The Administrative Contact and the Registrant, as outlined in the Losing
Registrar's publicly accessible Whois service are the only parties that have
the authority to approve or deny a transfer request to the Gaining
Registrar. In all cases, the authority of the Registrant supercedes that of
the Administrative Contact. [C]

 - The Gaining Registrar must use a Standardized Form of Authorization to
seek the approval of the Registrant or Administrative Contact. [C]

 - ICANN should support the development of this Standardized Form of
Authorization through staff consultation with impacted stakeholders with
guidance as to intent and scope from this Task Force. This form must be
useable in both physical and online automated systems (web, email). [C]

 - In the event that the Gaining Registrar must rely on a physical process
to obtain this authorization, a paper copy of the Standardized Form of
Authorization will suffice insofar as it has been signed by the Registrant
or Administrative Contact and is accompanied by a physical copy of the
Losing Registrar's Whois output for the domain name in question.

 - If the gaining registrar relies on a physical authorization
process, they assume the burden of obtaining Reliable Evidence of Identity
of the Registrant or Administrative Contact and that the entity making the
request is indeed authorized to do so.

 - The Task Force notes support for the concept that recommended forms of
identity that constitute Reliable Evidence of Authority include:
· Notarized statement
· Valid Drivers license
· Passport
· Article of Incorporation
· Military ID
· State/Government issued ID
· Birth Certificate

 - The Task Force notes support for the concept that in the event of an
electronic authorization process, recommended forms of identity would
include;
· electronic signature in conformance with national legislation, for
instance, the United States e-Sign Act
· email address matching Registrant or Administrative Contact email address
found in authoritative Whois database. [C]

 - Gaining Registrars must maintain copies of the Standardized Form of
Authorization by the Registrant or Administrative Contact of Record as per
the standard document retention policies of the contracts. [C]

 - Gaining Registrars must allow inspection by the Losing Registrar, and
other relevant third parties such as ICANN, the Registry Operator or a third
party Dispute Resolution Panel, of the evidence relied upon for the transfer
during and after the applicable Inter-registrar domain name transfer
transaction(s). [C]

 - Copies of the Reliable Evidence of Identity must be kept with the
Standardized
Form of Authorization. The Gaining Registrar must retain, and produce
pursuant to a request by a Losing Registrar, a written or electronic copy of
the Standardized Form of Authorization. The Losing Registrar retains the
right to inspect this documentation at all times consistent with existing
document retention standards. [C]

 - In instances where the Losing Registrar has requested copies of the
Standardized Form of Authorization, the Gaining Registrar must fulfill the
Losing Registrar's request (including providing the attendant supporting
documentation) within a reasonable period of time from the receipt of the
request. The Task Force recommends (3) business days. Failure to provide
this documentation within the time period specified is grounds for reversal
by the Registry Operator or Dispute Resolution Panel in the event that a
transfer complaint is filed in accordance with the recommendations of this
report. [C]

 - A Losing Registrar may deny a transfer request only in the following
instances; [C]

· Evidence of fraud
· UDRP action
· Court order
· Reasonable dispute over the identity of the Registrant or Administrative
Contact
· No payment for previous registration period (including credit card
charge-backs) if the domain name is past its expiration date or for previous
or current registration periods if the domain name has not yet expired. In
all such cases, however, the domain name must be put into "Registrar Hold"
status by the Losing Registrar prior to the denial of transfer.
· Express written objection from the Registrant or Administrative contact.
(eg - email, fax, paper document)

 - Instances when the Losing Registrar may not deny a transfer include, but
are not limited to; [C]

· Nonpayment for a pending or future registration period
· No response from the Registrant or Administrative contact unless the
Losing Registrar shows evidence of express written objection from the
Registrant or Administrative Contact.
· Domain name in Registrar Lock Status unless the Registrant is provided
with the reasonable opportunity and ability to unlock the domain name prior
to the Transfer Request.
· Domain name registration period time constraints other than during the
first 60 days of initial registration.
· General payment defaults between registrar and business partners /
affiliates in cases where the registrant for the domain in question has paid
for the registration.


                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog



<<< Chronological Index >>>    <<< Thread Index >>>