Final Report
and Recommendations of the GNSO Council's Transfers Task Force
Policies and Processes for Gaining and Losing Registrars 12 February 2003
Contents
Executive Summary
Policy Recommendations
of the Task Force
Preamble
Consensus Policy Recommendations
Supporting Arguments
Impact, Cost, and Risk Analysis
Impact to Registrants
Impact to Registrars
Impact to gTLD Registries
General Risk and Cost Analysis
Constituency Impact (CI) Reviews
Detailed
Implementation Analysis and Task Force Comments
Other Observations &
Considerations
Terms of Reference
Background
Record of Outreach
I. Conference Calls & Meetings
Open to Non-Task Force Participants
II. Public and Constituency Comments
Received by the Task Force
Minority Reports
Historical Proposals
Exhibit A: Reference
Application
Exhibit B: Proposed
Dispute Resolution Model
Exhibit C: Standardized
Definitions
Exhibit D: Transfers
Implementation Task Force Report
Exhibit E: End
Notes
Version and Revision Information |
Version Dec. 12: 20021212.NCTransferTF-gaining-and-losing-registrars.html
Version Nov 30: 20021130.NCTransferTF-gaining-and-losing-registrars.html
Note: On 02/12/03, this report was updated to include
feedback received from the GNSO Transfers Implementation Committee.
All changes adopted by the Task Force and included in this report
are clearly marked for the record. No further changes were made
to this document during this particular revision.
On 12/12/02, this report was updated to include feedback received
by the Task Force during the final public comment period and also
to include a late submission by the Registry Constituency. The
following sections of this document were updated and all additions
are clearly marked:
|
Executive
Summary
When private sector competition was introduced into the registration
functions of the generic Top Level Domains, the community greeted this
concept with great enthusiasm and high expectations. Now that competition
has been implemented, the community enjoys the benefit of having access
to a healthy and diverse community of competitive Registrars who offer
differentiated services, at different prices. They are located in different
countries. Some work through ISPs, some sell direct. Some are "niche"
providers, who actually primarily offer ISP or web hosting services, or
the registration service is largely a courtesy but an important one, to
their existing customers. To many, registration services are their core
business. While this description does not do justice to the range of innovation
of the competitive Registrars for gTLD names, it begins to capture the
key and critical message: Registrants should be able to choose a
Registrar who can serve their needs, and they should be able to “move”
from one Registrar to another, if they are dissatisfied, for any reason.
But, can they?
As the Task Force examined the issues, it became apparent that it is
difficult, if not impossible for self-interested parties to voluntarily
agree on changes to the policy. In fact this has been attempted on more
than one occasion and the experiences of Registrars, Registries, Registrants
and the ICANN Staff demonstrate that the voluntary approach to solving
these complex problems is not a valid approach to resolving the issues
identified by the community. The practices of a single large Registrar
can affect dozens of small Registrars, while actions by 2-3 of the largest
Registrars means that choice is simply ‘on hold’. Despite several
attempts at forging voluntary agreement on the necessary changes, the
record shows that there are still problems with the “portability” of domain
registrations – customer choice remains limited.
The outreach undertaken by the Task Force supports this view. ICANN staff
has further acknowledged this. With this understanding the Task Force
proceeded with one assumption: regardless of the reasons why a transfer
is approved, denied, blocked, delayed, or misdirected, Registrants are
entitled to transfer their registration from one Registrar to another
and the process to do so should be easy, fluid, transparent, and inexpensive.
When mistakes, errors, or fraudulent transfers happen, there should be
a quick and simple “recovery” process available. There should be an appeal
process to deal with the complicated situations. All of this should be
clear, understandable, and speedy, and limit the time and financial investment
of Registrars, Registries and Registrants.
The Task Force summarizes these requirements in four simple words; Security,
Transparency, Stability and Portability. Any recommendation approved for
implementation as policy must meet these four standards and achieve balance
between them. The Task Force believes that its recommendations fulfill
this obligation in all regards.
More broadly speaking, the characteristics that benefits Registrants
should also provide benefit for Registrars and Registries. The Transfer
Task Force has tried to approach the problems and concerns with that goal
in mind a mutually beneficial approach that ensures the satisfaction
of the Registrants, Registrars and Registries. This system must enable
a fair, balanced, competitive environment, provide Registrants with choice
give them the capability to exercise that choice and provide Registries
and Registrars with the safeguards necessary to limit their exposure,
costs, and liability.
The Task Force engaged in extensive outreach to the impacted community
over a number of months. Some accepted the invitation to provide input
and comment, others did not. Registrars had legitimate concerns about
abuse of a system which might mislead Registrants and cause them to agree
to a transfer, which they didn’t understand. Others are concerned about
"slamming". Some raised questions about "customer fraud".
The Task Force dealt with these as serious concerns. The processes recommended
provide an option for the losing Registrar to contact the Registrant for
validation, should they suspect slamming or fraud.
If there is a single theme to the work of the Task Force, it is that
the system of transfers between competitive Registrars is to serve Registrants.
As you read our report, this theme should be kept in mind: Transferring
domain name is about customer choice.
The Task Force has benefited from the ongoing contribution of all members
of the Task Force, who spent numerous hours in seeking to understand,
document, and cooperate to develop a process which can bring more certainty
into a critical process and which addresses the needs and interests of
the supplier of the registration process, and the user of that process
in a fair, open, and cost effective manner, and which provides an appeals
or problem resolution process with those same characteristics.
Many individuals and companies shared their views and experiences with
us. ICANN staff provided essential clarification and offered analysis
of the existing agreements; Constituency and General Assembly members
(and others) participated in open calls. Many dissenting and many supporting
comments were received. The Task Force thanks all who spent their time
in educating, agreeing, and disagreeing with their recommendations. We
made every effort to reflect the input we received. We acknowledge that
we may have missed some of the specifics but we believe that we have captured
the themes and broad concerns.
As we enter the final comment period lasting eight days, Constituencies
are asked to present Constituency Impact Statements. Others may choose
to submit dissenting opinions or expressions of support. Any submissions
on impact or minority opinions received will be included in that final
submission, along with the comments of the Task Force.
This Final Report of the Task Force builds on previous reports that attempted
to describe the nature of the problem. This report is built on the need
for a change in process and describes high level principles to guide policy,
provides extensive policy recommendations and documents where consensus
exists and where it does not. Finally, it establishes some areas where
unresolved work items exist. This report will be presented to the Names
Council for acceptance and forwarding to the Board for agreement. We anticipate
that there may be questions and stand ready to provide all assistance
to the approval and implementation processes.
Submitted by the Transfer Task Force,
November 30, 2002
Policy
Recommendations of the Task Force
Preamble
The Task Force respectfully submits the following policy recommendations
to the Names Council for consideration as Consensus Policies in accordance
with the standards set forth in the Names Council Rules of Procedure.
Unless noted otherwise, the Task Force believes that these recommendations
are consistent with community consensus as it relates to the policy implications
raised by the Task Force mandate.
Further explanation of these recommendations and documentation of the
level of support that these policies have can be found elsewhere in this
report.
Consensus Policy Recommendations
[Note to 12 February 2003 version: Based on
the Implementation Committee analysis and recommendations, some wording
improvements resulting from the implementation committee report have been
incorporated to improve the clarity and hence ease of implementation of
the recommendations. "The Detailed Implementation Analysis and Task
Force Comments" is also incorporated in full in this Report. For
ease of identification, these changes have been tracked throughout this
portion of the document. Stricken text appears in a strikethrough
font and amendments and additions appear italicized. No policy
changes were made in the document.]
1. 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.
2. Implementation of these conclusions
and recommendations should, wherever possible, use existing protocols
and standards.
3. Registrars must should
provide and maintain an unique and private email address
for use only by all other Registrars and the rRegistriesy:
where formal communications concerning the transfer process can be
sent and dealt with by the receiving Registrar.
a. This email is for transfer issues only.
b. The address should be managed to ensure messages
are received by someone who can respond to the transfer issue.
c. A timeframe should be required for responses
such as this: "commercially reasonable" but not to exceed
XX time period.
d. XX time period will be be established and
agreed upon during the implementation process, prior to the implementation
of these recommendations.
4. Inter-Registrar domain name transfer processes
must be clear and concise in order to avoid confusing Registrants or other
stakeholders.
5. The Registrant must be informed
of and have access to, the published documentation of the specific
transfer process of their current Registrar. The Task Force notes that
it would also be useful for Registrants to have access to the transfer
process documentation of Registrars that the Registrant is considering
switching to. Registrars should make reasonable efforts to inform
registrants of and provide access to, the published documentation of the
specific transfer process(es) employed by the Registrar. The Task Force
notes that it would also be useful for Registrants to have access to the
transfer process documentation of Registrars that the Registrant is considering
switching to.
6. 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. The Task Force observes support that this reasonable time period
is 72 hours or a similarly limited period of time.
7. 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.
8. The Gaining Registrar must verify
the intention of the Registrant or Administrative Contact of Record to
transfer their domain name registration by requiring that the Registrant
complete a valid Standardized Form of Authorization. The Gaining
Registrar must confirm a transfer request, by requiring that the Registrant
or Administrative Contact of Record as listed in the WHOIS complete a
valid Standardized Form of Authorization. A transfer must not be allowed
to proceed if no confirmation is received.
9. The Gaining Registrar is solely
responsible for validating Registrant requests to transfer domain names
between Registrars.
a. 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.
10. 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 that
the Losing Registrar must allow the transfer to proceed. In the
event that a Registrant or Admin Contact listed in the WHOIS has not confirmed
their request 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 that the Losing Registrar
must allow the transfer to proceed.
11. 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.
a. 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.
b. No Registrar shall add to the Standardized
Form of Authorization or any form or application used to obtain the
consent of the Registrant or Administrative Contact of Record, any
additional information.
c. The Standardized Form of Authorization
should be sent as soon as operationally possible but must be sent
not later than 24 hours after receiving the transfer request.
12. The presumption in all cases will
be that the Gaining Registrar has received and authenticated the requisite
request from the Registrant or Administrative Contact.
13. 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. Either registrar should
be able to file a dispute.
14. 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.) Except
for non-payment for previous registration period if transfer is requested
after the expiration date, or non-payment of the current registration
period, if transfer is requested before the expiration date.
15. 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.
16. 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.
The Administrative Contact and the Registrant, as outlined in the
Losing Registrar’s or Registry’s (where available) publicly accessible
WHOIS service are the only parties that have the authority to approve
or deny a transfer request to the Gaining Registrar. In the event of a
dispute, the authority of the Registrant in the authoritative Whois service
supercedes that of the Administrative Contact.
17. The Gaining Registrar must use
a Standardized Form of Authorization to seek the approval of the Registrant
or Administrative Contact. The Gaining or Losing Registrar must use
a Standardized Form of Authorization to seek the approval of the Registrant
or Administrative Contact. English shall be the primary and default language
for these communications. Additionally, Registrars may communicate
with registrants in other languages provided that this principle of standardization
this principle is satisfied .
18. 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 (paper form,
fax version, etc.) and online automated systems (web, email, etc.).
19. 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.
a. 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.
b. 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
c. 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.
20. 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. 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. Each Registrar is responsible for keeping copies of documentation
that may be required for filing and supporting a dispute resolution process.
21. 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). Both gaining
and losing registrars must allow inspection by the other registrar who
is party to the transfer transaction (Gaining or Losing), 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).
22. 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
requirements.
23. 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.
24. A Losing Registrar may deny transfer
requests only in specific instances and that there should be a finite
list of allowable reasons for denying a transfer request with the understanding
that procedures should be put into place to modify the list if registrars
support changes to the list, and that such changes be approved by ICANN
staff, or another equally appropriate body, and that in the event that
the changes requested constitute new policy, or are not otherwise authorized
by ICANN staff or the appropriate body, that the matter be referred to
the GNSO Names Council for consideration. Further that, upon denying a
transfer request for any reason, registrars must provide the registrant
and the other registrar the reason for denial. Therefore, a A
Losing Registrar may deny a transfer request only in the following instances;
a. Evidence of fraud
b. UDRP action
c. Court order
d. Reasonable dispute over the
identity of the Registrant or Administrative Contact
e. 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.
f. Express written objection from
the Registrant or Administrative contact. (e.g. – email, fax, paper
document or other processes by which the Registrant has expressly
and voluntarily objected through opt-in means)
domain name is in lock status provided that the registrar provides
a readily accessible and easy means for the registrant to remove the
lock status.
A domain name is in the first 60 days of an initial registration
period.
A domain name is within 60 days (or a lesser period to be determined)
after being transferred (apart from a transfer back to the original
registrar).
25. Instances when the Losing Registrar
may not deny a transfer include, but are not limited to:
a. Nonpayment for a pending or
future registration period
b. No response from the Registrant
or Administrative contact unless the Losing Registrar shows evidence
of express written objection from the Registrant or Administrative
Contact. (e.g. email, fax, paper document or other processes
by which the Registrant has expressly and voluntarily objected through
opt-in means)
c. 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.
d. Domain name registration period
time constraints other than during the first 60 days of initial registration.
e. General payment defaults between Registrar
and business partners / affiliates in cases where the Registrant for
the domain in question has paid for the registration.
26. That Registrars have access to a suitable process(es)
by which they can dispute any specific transfers that they might object
to after the fact (i.e. a dispute resolution processes as
outlined in the Reference Implementation described elsewhere in this report).
And that such processes specifically include provisions that fulfill the
following requirements;
a. Resolution of the disputes should be administered
by a third party or the pertinent Registry operator or both.
b. That the processes be limited in scope to
issues arising out of inter-Registrar domain name transfers
c. That the processes be solely initiated by
a Registrar.
d. That appeal of rulings is allowed, but is
limited in number.
e. That the policy include specific obligations
for all parties to the dispute to provide documentation to the dispute
resolution provider
f. That the Registrar filing a dispute pay the
cost of filing the dispute, that the party that "loses"
the dispute pay the cost of administering the dispute resolution and
reimburse the filing Registrar for the filing fees if applicable.
g. That the third party dispute resolution service
or Registry be able to direct the appropriate Registry or Registrar
to return a domain name to whatever state the dispute resolution provider
deems appropriate based on the facts presented during the proceeding.
27. That Registries implement a "Transfer Undo"command
mechanism that will assist Registrants and Registrars in resetting
a domain name back to its original state in the event that a transfer
has occurred in contravention of the recommendations of this document.
28. That the implementation and execution of these
recommendations be monitored by the DNSO. Specifically that;
a. ICANN Staff analyse and report to the Names
Council at three, six and twelve month intervals after implementation
with the goal of determining;
i. How effectively and to what extent the
policies have been implemented and adopted by Registrars, Registries
and Registrants,
ii. Whether or not modifications to these
policies should be considered by the DNSO as a result of the experiences
gained during the implementation and monitoring stages,
iii. The effectiveness of the dispute resolution
processes and a summary of the filings that have been resolved through
the process.
b. Pursuant to which, the Names Council may
instruct the staff to;
i. Continue bi-annual reviews in a manner
consistent with the aforementioned requirements, or;
ii. Report again to the Names Council in
an additional twelve month time frame.
c. The purpose of these monitoring and reporting
requirements are to allow the Names Council to determine when, if
ever, these recommendations and any ensuing policy require additional
clarification or attention based on the results of the reports prepared
by ICANN Staff.
29. Guidance. The Task Force has completed three
supplementary documents ("Exhibit
A, Reference Implementation", "Exhibit
B, Proposed Dispute Resolution Model" and "Exhibit
C, Standardized Definitions") in support of these recommendations.
These exhibits are submitted as guidance to those that will be required
to craft and/or implement the policies adopted as a result of these recommendations.
Supporting
Arguments
There are many complex issues that derive themselves from the current
policy on inter-Registrar domain name transfers. The Task Force does not
believe that the issues can be substantively dealt with by a single policy
pronouncement that magically rectifies the problems experienced by Registrars,
Registries and Registrants.
Accordingly, the Task Force adopted an approach to formulating its recommendations
that were rooted in conditioned principles upon which all stakeholder
groups agree.
These principles fall into four broad categories:
- security
- transparency
- stability
- portability
The condition associated with these principles is equally simple: balance.
The recommendations developed from these principles must provide sufficient
balance between the often competing principles so as to ensure that the
requirements of a broad range of stakeholders were adequately considered
and dealt with. For instance, security at the expense of transparency
would likely leave Registrants without a proper understanding of what
processes they would need to engage in if they wished to move their name
from one Registrar to another. Alternatively, recommendations that place
too much emphasis on portability at the expensive of stability would leave
most parties involved in the process without a predictable process by
which they could easily remedy errors or proactively protect against them.
The recommendations contained in this report are the product of an open
and transparent process that took place over the course of a year. Hundreds
of hours of discussion were devoted to the topic, many proposals were
considered, dozens of revisions were proposed and thousands of words debated
the merits of specific recommendations and alternate approaches. In other
words, a process took place by which the best recommendations were substantively
discussed, clarified, compromised and eventually manifested themselves
as the consensus recommendations contained in this report.
The Task Force believes that it is this approach, the process, which
represents the single most compelling argument in favor of adopting these
recommendations. The fact they do represent the best ideas of the community,
the ones upon which we most agree and perhaps most importantly, the ones
with the most understood and refined impact. This is not to say that concepts
and ideas that did not make it into this report were not good or well-considered,
to the contrary, there were many that were. But, these bright ideas did
not get the support of the community necessary to include them as a consensus
recommendation of this report. Similarly there were also many reasoned
criticisms of these recommendations that were put forward. But, unless
they were shared by a reasonable cross-section of the community, it was
equally impossible to put them forward as the consensus of the community.
This is one of the features of the consensus policy development process
– both the consensus support and consensus disagreement must be substantively
dealt with. Again, the Task Force believes that it has fulfilled this
required.
However, we have no presumptions that new consensus ideas and dissent
won’t emerge from the DNSO. Accordingly, we have attempted to temper these
recommendations with very finite and predictable review mechanics that
will allow the DNSO to adjust or correct the policy over the short, medium
and longer terms. We believe that a moderate approach of this nature ensures
that the policy in effect will continue to reflect the will of the community
for the foreseeable future.
The consensus policy development process is neither easy nor trivial.
Nor should it be. Appropriate processes lead to appropriate results. Balanced
processes lead to balanced results. The Task Force believes that the processes
employed in the development of these recommendations are both balanced
and appropriate, but to the extent that the results need to be adjusted,
a similarly balanced and appropriate approach should be taken so as to
ensure the continued integrity of the results.
Impact,
Cost, and Risk Analysis
The Task Force has an obligation to ensure that the Names Council is
informed of any significant implementation or operational concerns posed
by the recommendations included in this report. The Task Force devoted
substantial attention to the question of what constituted “significant
implementation or operational concerns” and concluded that the most effective
and practical definition was to analyse the policy recommendations from
the standpoint of those parties that might be specifically impacted. Accordingly,
Task Force representatives were asked to conduct an analysis that described
what obstacles may exist as it relates to the implementation of these
recommendations and any undue burden or unintended consequences that may
occur as a result of the implementation.
This is further amplified in the General Cost and Risk statements and
will be presumably be augmented by any Constituency Impact reviews received
by the Task Force during the public comment period. The Task Force believes
thatthis reports provides the Names Council with the supporting guidance
necessary to accept these recommendations.
Impact to Registrants
The Task force has made it clear that it accepts that the transfer process
has a significant impact on Registrants, in offering them choice to more
from one competitive Registrar to another, regardless of the reason that
the Registrant has. Comments were received from ICANN staff and from Registrants
themselves, as well as from Registrars and Registries, noting that Registrants
can be harmed in several ways when a transfer is undertaken in error or
for fraudulent purposes by some third party, or when a transfer is not
undertaken as legitimately authorized/requested by the Registrant. Registrants
have been required to renew with a Registrar they wish to transfer away
from because they believe, or have been told that their registration may
lapse. This renewal then holds them captive, until some other date when
they may again be able to try to transfer. This may result in either loss
of choice to the Registrant, or actually cost them additional registration
fees when they renew, and then go ahead and transfer.
Registrants will benefit from a clear, transparent, documented approach
for transfers, which limits fraud, or abuse, and which provides clarity
about how they can pursue an authorized transfer. There are both “peace
of mind” issues, but more importantly, actual economic and social impacts
to a Registrant who is operating a web site for communicating with the
public, and fears or risks, losing their domain name or having their site
“go dark”, during a recovery period.
Registrants will need to be clearly informed, through communications
both from ICANN via its normal distribution processes, as well as Registrars,
of the changes in practices, based on policy changes.
Impact to Registrars
This report contemplates many new and/or modified obligations that may
or may not be fully understood by all Registrars. It will be important
to ensure that ICANN and the DNSO are prepared to undertake outreach and
education to ensure that all ICANN Accredited Registrars are aware of
and compliant with these new and modified obligations. Some of the obligations
contained in this report are more stringent than prior policies. This
will require that Registrars ensure that their internal systems and processes
are compliant with any policies enacted as a result of these recommendations.
Some of the recommendations contained in this report will require Registrars
to modify their internal technical systems in a manner that will support
any policies enacted as a result of this report. However, many Registrars
already employ systems which already can, or with minimal enhancement
could, comply with the recommendations made in this proposal. While the
degree of modification will vary from Registrar to Registrar, the Task
Force does not believe the costs incurred as a result of these modifications
will be substantial. Further, anecdotal evidence suggests that the long-term
benefits achieved through the implementation of standardized processes
in some areas of the transfer process will result in increased consumer
confidence and therefore outweigh any short-term costs involved.
Lastly, these recommendations do not attempt to provide specification
concerning the type of technology and level of automation required to
implement these recommendations. This is outside the responsibility of
this Task Force. The Task Force agrees, however, that such changes
may result in added costs to Registrars. During implementation discussions,
further identification of cost areas can be undertaken by a joint working
group of ICANN staff, Registrars, Registries and as needed, outside technical
experts. The Task Force agrees to provide liaison support to such an effort,
to represent the broader interests of users, as useful and appropriate.
Therefore, the Task Force believes that because; a) Registrars
retain the capability to exercise a high degree of control over any costs
that may arise as a result of these obligations and b) Registrars retain
their right to engage in cost recovery under the terms of their operating
agreements that the net total impact of these obligations is substantially
limited.
Impact to gTLD Registries
(Note: This section was added 12-12-02) This report contemplates
several new and/or modified obligations that will impact gTLD Registries
and, as is the case with the gTLD Registrars, it will be important to
ensure that ICANN and the DNSO are prepared to undertake outreach and
education to ensure that all Registries and Registrars are aware of and
compliant with these new and modified obligations.
Perhaps the recommendation with the most impact on the gTLD Registries
is the possibility that they might serve as a dispute resolution provider
in cases where Registrars either dispute a transfer or alternatively,
the NACK of a transfer by the Losing Registrar. This may require gTLD
Registries to supply new resources, including customer support and staff,
that they do not currently provide. In addition, it may require gTLD Registries
to engage in limited fact-finding investigations in an attempt to enforce
the recommendations set forth in this report. Undoubtedly this may end
up adding additional costs to the gTLD Registries which will be recoverable
under the existing gTLD Registry Agreements with ICANN.
The Task Force does not believe the costs incurred as a result of these
modifications will be substantial in light of the report's efforts to
standardize the transfer process, thereby creating increased certainty
for end users, and ultimately portability of domain names. During implementation
discussions, further identification of cost areas can be undertaken by
a joint working group of ICANN staff, Registrars, Registries and as needed,
outside technical experts.
General Risk and Cost Analysis
The risks and cost associated with this proposal are still to be fully
defined, and the Task Force acknowledges that. Since the implementation
period will develop further many aspects of “how” implementation may be
done, and there will be areas of flexibility to individual Registrars,
the Task Force believes that this step is more appropriately undertaken
during the Implementation Process. Accordingly, the Task Force did not
engage in an in depth analysis of the risks and costs associated with
these recommendations beyond what is included in the “Impact Analysis”
portion of this report.
While we feel that the Impact Analysis and Constituency Impact Reports
will provide a high level identification of the current risks and costs,
the Task Force believes that further risks or costs that have not yet
been identified or fully documented in scope will only manifest themselves
during the implementation and monitoring stages contemplated by the Consensus
Recommendations of the Task Force. During the implementation period, these
costs and risks should be documented and will need to be taken into account
in the implementation period itself. Again, the Task Force assumes
that costs may include both staff costs and systems costs.
There is likely to be additional ICANN staff demands, as well, and that
costs will actually be easier to document, by asking the ICANN management
to extrapolate from the time now spent by ICANN staff on addressing transfer
concerns. Once a new and different process in place, and “tested” through
actual practical use, it may be that demands on staff time will diminish.
The Task Force is not sure that will happen in any near term, however,
since there will undoubtedly be continued changes in the competitive Registrars
“market”, with the usual changes which take place in a market sector,
consolidation, expansion, mergers, growth of new Registrars, etc. Therefore,
additional ICANN staff time and resources should be planned for by ICANN
management.
Further, it is our opinion that once the initial costs are identified
during the implementation period, these areas should become part of the
periodic implementation reports that the Task Force recommends. These
reports should also include documentation, however, on numbers of incidents,
and impact on Registrants as well.
Constituency Impact (CI)
Reviews
The Task Force did not receive any CI Reviews prior to the publication
of this document. They will therefore be published as received and are
incorporated by reference at the following URL: http://www.byte.org/nc-transfers/ci/
(Note: As of 12-12-02, The Task Force did not receive any Constituency
Impact Reviews.)
(Note: On 12-14-02, The DNSO Names Council unanimously approved the
following resolution:
The Names Council accepts the policy recommendations that were in
the transfer Task Force Report of 30 November.
The Names Council will form an implementation analysis committee
which will comprise of the Registries and Registrars with ICANN staff
and user liaisons from the transfer task force.
That it will complete its analysis by 30 January 2003.
The Names Council will then meet to discuss the final ICANN Board
report in its meeting in February and the final Board report will be
forwarded with the aim to reach the ICANN Board 30 days prior to the
ICANN meeting in Rio de Janeiro.
The report from the implementation analysis committee will present
the findings on the feasibility of implementing the policy and it will
be suitable for inclusion in the report which will become theTransfers
Board report.)
[Note: The implementation Task Force's comments
are addressed immediately below].
Detailed
Implementation Analysis and Task Force Comments
On 01-31-2003, The
Transfers Implementation Committee filed its final report with the
GNSO Council pursuant to this resolution. This report can be found in
its entirety in Exhibit
D of this report.
The significant recommendations of this Implementation Commitee (Imp-Comm),
along with an analysis by this Task Force are as follows:
Rec. # |
Text of Task Force Recommendation & Suggested
Amendments of the Imp-Comm |
Task Force Comments & Recommendations |
1 |
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.. |
No change from existing Task Force recommendation. |
2 |
Implementation of these conclusions and recommendations should,
wherever possible, use existing protocols and standards. |
No change from existing Task Force recommendation. |
3 |
Existing Recommendation: 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. |
Accepted with modification. Specifically that;
- the time periods not specified in the suggest amendment be established
and agreed upon during the implementation process, prior to the
development of the relevant contractual amendments.
- We further note that the requirement to provide a "unique
and private email address" may be superfluous and
over prescriptive but request no amendment to this requirement.
|
Suggested Replacement text: Registrars should provide
a unique and private email address for use only by other registrars
and the registry:
1. This email is for transfer issues only.
2. The address should be managed to ensure messages are received
by someone who can respond to the transfer issue.
3. A timeframe should be required for responses such as this:
"commercially reasonable" but not to exceed XX time
period. XX time period will be determined within 3 months of implementation.
|
4 |
Inter-Registrar domain name transfer processes must be clear and
concise in order to avoid confusing Registrants or other stakeholders.
|
No change from existing Task Force recommendation. |
5 |
Current recommendation: The Registrant must be informed of
and have access to, the published documentation of the specific transfer
process of their current Registrar. The Task Force notes that it would
also be useful for Registrants to have access to the transfer process
documentation of Registrars that the Registrant is considering switching
to. |
Accepted with modifications. Specifically that the
first sentence of the amendment be modified for the sake of clarity
to read "Registrars should make reasonable efforts to
inform registrants of and provide access to, the published documentation
of the specific transfer process(es) employed by the Registrar." |
Suggested replacement text: Reasonable efforts
should be made to inform registrant of and have access to, the published
documentation of the specific transfer process of their current registrar.
The Task Force notes that it would also be useful for Registrants
to have access to the transfer process documentation of Registrars
that the Registrant is considering switching to. |
6 |
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.
The Task Force observes support that this reasonable time period is
72 hours or a similarly limited period of time. |
No change from existing Task Force recommendation. |
7 |
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. |
No change from existing Task Force recommendation. |
8 |
Current recommendation: The Gaining Registrar must verify
the intention of the Registrant or Administrative Contact of Record
to transfer their domain name registration by requiring that the Registrant
complete a valid Standardized Form of Authorization. |
Accepted. |
Suggested replacement text: The Gaining Registrar must
confirm a transfer request, by requiring that the Registrant or Administrative
Contact of Record as listed in the WHOIS complete a valid Standardized
Form of Authorization. A transfer must not be allowed to proceed if
no confirmation is received. |
9 |
Existing Recommendation: The Gaining Registrar is solely
responsible for validating Registrant requests to transfer domain
names between Registrars.
- 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.
|
Accepted. |
Proposed revised text: The Gaining Registrar is responsible
for validating Registrant requests to transfer domain names between
Registrars.
- 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.
|
10 |
Current recommendation: 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 that the Losing Registrar must allow the transfer to proceed. |
Accepted. |
Suggested replacement text: In the event that a Registrant
or Admin Contact listed in the WHOIS has not confirmed their request
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 that the Losing Registrar
must allow the transfer to proceed. |
11 |
Existing Recommendation: 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.
a. 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.
|
Accepted with modification. Specifically that;
- the "Suggested Additional Text" be clarified and made
consistent with existing definitions by rewording as follows (modifications
in italics):
"No Registrar shall add to the Standardized Form of Authorization
or any form or application used to obtain the consent of the Registrant
or Administrative Contact of Record, any additional information.
The Standardized Form of Authorization should be sent
as soon as operationally possible but must be sent not later than
24 hours after receiving the transfer request."
|
Suggested additional text:
b. Authentication communications with registrants regarding
the transfer process should not include any information other
than that contained in the standardized form.,
c. Authentication communications with registrants should be
sent as soon as operationally possible but must be sent not later
than 24 hours after receiving the transfer request.
|
12 |
The presumption in all cases will be that the Gaining Registrar
has received and authenticated the requisite request from the Registrant
or Administrative Contact. |
No change from existing Task Force recommendation. |
13 |
Existing Recommendation: 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 |
Accepted. |
Additional text: Either registrar should be able
to file a dispute |
14 |
Existing recommendation: 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.)
. |
Accepted. |
Additional text: Except for non-payment for previous registration
period if transfer is requested after the expiration date, or non-payment
of the current registration period, if transfer is requested before
the expiration date. |
15 |
In EPP-based TLDs, a Losing Registrar must not refuse to release
an "AuthInfo Codes" to the Registrant solely because there
is a dispute between a Registrant and the Registrar over payment.
|
No change from existing Task Force recommendation. |
16 |
Existing Recommendation: 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. |
Accepted. |
Suggested Replacement text: The Administrative Contact
and the Registrant, as outlined in the Losing Registrar's or Registry's
(where available) publicly accessible WHOIS service are the only parties
that have the authority to approve or deny a transfer request to the
Gaining Registrar. In the event of a dispute, the authority of the
Registrant in the authoritative Whois service supercedes that of the
Administrative Contact |
17 |
Existing Recommendation: The Gaining Registrar must use a
Standardized Form of Authorization to seek the approval of the Registrant
or Administrative Contact. |
Accepted with modification. Specifically that;
- the "Suggested replacement text" be clarified and
made consistent with existing definitions by rewording as follows
(modifications in italics):
"The Gaining or Losing Registrar must use a Standardized
Form of Authorization to seek the approval of the Registrant
or Administrative Contact. English shall be the primary and
default language for these communications. Additionally,
Registrars may communicate with registrants in other languages
provided that this principle of standardization this
principle is satisfied ."
|
Suggested replacement text: The Gaining or Losing Registrar
must use a Standardized Form of Authorization to seek the approval
of the Registrant or Administrative Contact. English is the mandatory
default language for all registrar, registry and registrant transfer
communications. Additionally, registrars may communicate with registrants
in other languages provided that the principle of standardization
this principle is satisfied |
18 |
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). |
No change from existing Task Force recommendation. |
19 |
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.
a. 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.
b. 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
c. 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.
|
No change from existing Task Force recommendation. |
20 |
Existing recommendation: 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. |
Accepted with modification. Specifically that:
- the existing Task Force Recommendation not be stricken.
- the "Suggested replacement text" be clarified and
made consistent with existing definitions by rewording as follows
(modifications in italics)":
"Each Registrars is responsible for
keeping copies of documentation that may be required
for filing and supporting a dispute resolution process."
Therefore, the actual text of the specific recommendation will
read as follows:
"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 existing contracts. Each Registrar is responsible for keeping
copies of documentation that may be required for filing and
supporting a dispute resolution process."
|
Suggested replacement text: Registrars are
responsible for keeping copies of documentation required for filing
and supporting a dispute resolution process |
21 |
Existing Recommendation: 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). |
Accepted with modification. Specifically that:
- the "Suggested replacement text" be clarified and
made consistent with existing definitions by rewording as follows
(modifications in italics):
"Gaining and losing registrars must allow inspection
by the other registrar who is party to the transfer transaction
(Gaining or Losing), 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)."
|
Suggested Replacement text: Gaining and losing registrars
must allow inspection by the matching 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). |
22 |
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 requirements.
|
No change from existing Task Force recommendation. |
23 |
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. |
No change from existing Task Force recommendation. |
24 |
Existing Recommendation: A Losing Registrar may deny
a transfer request only in the following instances:
a. Evidence of fraud
b. UDRP action
c. Court order
d. Reasonable dispute over the identity of the Registrant or
Administrative Contact
e. 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.
f. Express written objection from the Registrant or Administrative
contact. (e.g. – email, fax, paper document or other processes
by which the Registrant has expressly and voluntarily objected
through opt-in means)
|
Accepted on the conditions:
1. that the change process contemplated by the "Additional
text" be approved by ICANN staff, or another equally appropriate
body, and;
2. that in the event that the changes requested constitute new
policy, or are not otherwise authorized by ICANN staff or the
appropriate body, that the matter be referred to the GNSO Council
for consideration.
and that addition "i" be modified to read;
"A domain name is within 60 days (or a lesser period to
be determined) is after being transferred
(apart from a transfer back to the original registrar)."
|
Additional text:
g. domain name is in lock status provided that the registrar
provides a readily accessible and easy means for the registrant
to remove the lock status.
h. A domain name is in the first 60 days of an initial registration
period
i. A domain name is within 60 days (or a lesser period to
be determined) of being transferred (apart from a transfer back
to the original registrar)
There should be a finite list of allowable reasons for denying
a transfer request with the understanding that procedures should
be put into place to modify the list if registrars support any changes.
Upon denying a transfer request for any reason, registrars must
provide the registrant and the other registrar the reason for denial
|
25 |
Instances when the Losing Registrar may not deny a transfer
include, but are not limited to:
a. Nonpayment for a pending or future registration period
b. No response from the Registrant or Administrative contact
unless the Losing Registrar shows evidence of express written
objection from the Registrant or Administrative Contact. (eg –
email, fax, paper document or other processes by which the Registrant
has expressly and voluntarily objected through opt-in means)
c. 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.
d. Domain name registration period time constraints other than
during the first 60 days of initial registration.
e. General payment defaults between Registrar and business partners
/ affiliates in cases where the Registrant for the domain in question
has paid for the registration.
|
No change from existing Task Force recommendation. |
26 |
That Registrars have access to a suitable process(es) by which
they can dispute any specific transfers that they might object to
after the fact (i.e. – a dispute resolution processes as outlined
in the Reference Implementation described elsewhere in this report).
And that such processes specifically include provisions that fulfill
the following requirements;
a. Resolution of the disputes should be administered by a third
party or the pertinent Registry operator or both.
b. That the processes be limited in scope to issues arising
out of inter-Registrar domain name transfers
c. That the processes be solely initiated by a Registrar.
d. That appeal of rulings is allowed, but is limited in number.
e. That the policy include specific obligations for all parties
to the dispute to provide documentation to the dispute resolution
provider
f. That the Registrar filing a dispute pay the cost of filing
the dispute, that the party that “loses” the dispute pay the
cost of administering the dispute resolution and reimburse the
filing Registrar for the filing fees if applicable.
g. That the third party dispute resolution service or Registry
be able to direct the appropriate Registry or Registrar to return
a domain name to whatever state the dispute resolution provider
deems appropriate based on the facts presented during the proceeding.
If the gaining registrar is responsible for transfer authentication
and the losing registrar’s special Whois is not accessible for a
to-be-specified time; this can be grounds to allow the transfer
to occur in case of a dispute. |
No change from existing Task Force recommendation. |
27 |
Existing Recommendation: That Registries
implement a “Transfer Undo” command that will assist Registrants
and Registrars in resetting a domain name back to its original state
in the event that a transfer has occurred in contravention of the
recommendations of this document. |
Accepted. |
Suggested Replacement text: That Registries implement
a “Transfer Undo” mechanism that will assist Registrants and Registrars
in resetting a domain name back to its original state in the event
that a transfer has occurred in contravention of the recommendations
of this document. |
28 |
That the implementation and execution of these recommendations
be monitored by the DNSO. Specifically that:
a. ICANN Staff analyse and report to the Names Council at three,
six and twelve month intervals after implementation with the goal
of determining;
i. How effectively and to what extent the policies have been
implemented and adopted by Registrars, Registries and Registrants,
ii. Whether or not modifications to these policies should be
considered by the DNSO as a result of the experiences gained
during the implementation and monitoring stages,
iii. The effectiveness of the dispute resolution processes
and a summary of the filings that have been resolved through
the process.
b. Pursuant to which, the Names Council may instruct the staff
to;
i. Continue bi-annual reviews in a manner consistent with the
aforementioned requirements, or;
ii. Report again to the Names Council in an additional twelve
month time frame.
c. The purpose of these monitoring and reporting requirements
are to allow the Names Council to determine when, if ever, these
recommendations and any ensuing policy require additional clarification
or attention based on the results of the reports prepared by ICANN
Staff.
|
No change from existing Task Force recommendation. |
29 |
Guidance. The Task Force has completed three supplementary documents
("Exhibit A, Reference Implementation", "Exhibit
B, Proposed Dispute Resolution Model" and "Exhibit C, Standardized
Definitions") in support of these recommendations. These
exhibits are submitted as guidance to those that will be required
to craft and/or implement the policies adopted as a result of these
recommendations. |
No change from existing Task Force recommendation. |
Other
Observations & Considerations
In the course of its work, the Task Force concluded that there were many
generalized observations and considerations that, while not integral to
the specific policy recommendations, were highly valued by the community
and fully within the scope of the subject matter to be considered by the
Task Force.
Accordingly, we call to the attention of the Names Council the following
general principles. These principles are not formal policy recommendations
of the Task Force, and are presented solely with the intention of furthering
the understanding of the consideration undertaken by the Task Force and
the community. These are solely advisory in nature and no comment is made,
nor implied, as to whether or not these represent the formal consensus
of any portion of the community. Further, it is important to note that
these are not presented nor should be construed as alternative or competing
recommendations to the Consensus Policy Recommendations of the Task Force.
1. Registrars must not employ transfer processes that conflict with
ICANN or Registry contracts. If a conflict occurs, ICANN or Registry
contracts take precedent. Registrars (and their agents) may not place
additional restrictions upon a Registrant in the form of a service contract
in a manner contrary to ICANN or Registry policy and/or contract with
respect to inter-Registrar domain name transfer transactions.
2. Inter-Registrar domain name transfers should be conducted in a manner
that engenders Registrant confidence
3. Registrants, Registrars and Registries stressed the importance of
an inter-Registrar transfer process that enhances the security, stability,
transparency and portability found in the current policies.
4. Registrars should take into account the legal, linguistic and cultural
differences of the domain name registration market, Registrars, and
Registrants when implementing inter-Registrar domain name transfer processes.
5. Registrars and Registries should not develop inter-Registrar transfer
processes that place undue burden on the Registrant, Registrar or Registry.
6. Where possible, Registrars and Registries are encouraged to automate
inter-Registrar domain name transfer processes as much as possible.
7. Inter-Registrar domain name transfer policies and processes adopted
by Registries and Registrars should allow Registries and Registrars
as much flexibility as possible in determining the scale, scope and
technologies used with their own specific implementations in pursuit
of their specific business models.
8. Where possible, Registrars should only initiate Inter-Registrar
domain name transfers at the request of the Registrant or Administrative
Contact of record.(is this duplicative)
9. It is recommended that the Losing Registrar use the EPP or RRP command
set equivalent of “Registrar Hold” prior to receiving a transfer notification
from the Registry as a mechanism to secure payment from a Registrant
in the event of non-payment. The Losing Registrar should not use the
EPP or RRP command set equivalent of “Registrar Lock” for this same
purpose.
10. Inter-Registrar transfers should be conducted in a secure as possible
manner and not allow for undue influence or manipulation by the losing
Registrar or any other third party.
Terms
of Reference
The purpose of the Task Force on Transfers is to:
- develop broad understanding across the Names Council of the issues
underlying the disputed area of transfers of domain names between Registrars
- ensure understanding of the proposed approach as documented
in the Registrars’ procedural document, which has been voted on by the
Registrar
- identify any broad policy issues (separate from contract issues),
which are the responsibility of the DNSO
- Devise recommendations which have broad cross constituency support
to any identified problems arising from the language of the existing
agreements where policy needs to guide contractual changes.
- Undertake a "fast track" working effort, via a Task Force,
to present a proposal for NC consideration at Marina
Del Ray NC meeting and to recommend next steps, if any.
Background
In early 2001, complaints began to surface from a number of Registrars
regarding denials of requested transfers, including substantial delays
and confusing responses. May 25, 2001, Verisign Registrar contacted the other Registrars that
it was taking specific actions to address this situation and announced
a policy which seems to be in conflict with the default policy outlined
in Appendix B of the Verisign-Registrar Accreditation Agreement.
On July 16, 2001, Verisign Corporate
advised Stuart Lynn, President, ICANN, that they had adopted a default
non acknowledgement (n’ack) policy in order to protect their customers
from unauthorized transfers. On August
27, 2001, Stuart Lynn replied to the Registrar Constituency recommending
that a new policy be created to deal with the problem. Louis Touton, General
Counsel and Secretary, ICANN, replied to the Verisign request, indicating
that Registrars may not deny transfer requests that the gaining Registrar
has verified simply because the losing Registrar has not verified it.
Throughout July, August, and September, the Registrar Constituency developed
and approved, within the constituency, a protocol for handling transfers,
with the intent that this protocol would be followed by all accredited
Registrars, thus giving certainty to the Registrant of what happens when
they change Registrars, or when their designated agent changes Registrars
on their behalf. . After extensive drafting and discussion, a final document
with extensive guidance was produced, and put to a vote by the Registrars.
The outcome of the vote:
Of 40 registrars voting, 3 against, one abstention, and 36 supporting.
The Registrar Constituency provides further detail on this topic at
http://www.icann-registrars.org/.
The vote held supported the default “ack” policy, which essentially
means that the losing Registry transfers the Registrant, upon receipt
of the request from the “gaining” Registry. |
However, in spite of the vote, there was not complete acceptance within
the Registrars Constituency and at least one, and maybe more Registrars
are not yet in compliance with the recommended procedure, as defined in
the Registrar protocol for transfers.
When this situation came to the attention of other constituencies prior
to ICANN’s meeting in Montevideo in fall, 2001, it
became apparent that the other constituencies were not full aware of the
situation, or the proposed solution under development by the Registrars.
A briefing was held by three constituencies (IPC, ISPCP, BC) with the
Registrars Constituency representative. It became apparent that
the other constituencies believe that their members (users/Registrants)
are being affected by this situation and some questioned whether
there are policy as well as contract issues. It is also clear
that while the protocol is a first step, additional areas of work were
needed. This has been acknowledged by the Registrar Constituency.
The issue was brought to the attention of the Names Council on an ensuing
conference call (October 11,
2001) and a "fast track" Task Force created.
Record
of Outreach
I. Conference Calls & Meetings
Open to Non-Task Force Participants
Date |
Place |
Description |
Participants |
September 7, 2001 |
In-person, Montevideo, Uruguay |
Joint Constituency Briefing |
Task Force Rep., ISPC, BC, IPC |
September 7, 2001 |
In-person, Montevideo, Uruguay |
Registrar Constituency Briefing |
Task Force Rep., R’rarC |
November 6, 2001 |
Teleconference |
Cross-Constituency Briefing |
Task Force, Open |
November 12, 2001 |
In-person, Marina Del Rey, United States |
Registrar Constituency Briefing |
Task Force Rep., R’rarC |
February 1, 2002 |
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open |
February 16, 2002 |
In-person, Reston, United States |
Registrar Constituency Briefing |
Task Force Rep., R’rarC |
March 11, 2002 |
In-person, Accra, Ghana |
Registrar Constituency Briefing |
Task Force Rep., R’rarC |
March 12, 2002 |
In-person, Accra, Ghana |
DNSO Names Council Briefing |
Task Force Chair, Names Council |
March 12, 2002 |
In-person, Accra, Ghana |
DNSO General Assembly Open Briefing |
Task Force, Open |
May 21, 2002 |
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open |
May 22, 2002 |
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open |
June 18, 2002 |
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open |
June 24, 2002 |
In-person, Bucharest, Romania |
Registrar Constituency Briefing |
Task Force Rep., R’rarC |
August 15, 2002 |
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open |
September 11, 2002 |
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open |
September 11, 2002 |
Teleconference |
DNSO Names Council Briefing, |
Task Force Chair, Task Force Rep., Names Council |
September 21, 2002 |
In-person, Amsterdam, Netherlands |
Registrar Constituency Briefing |
Task Force Rep., R’rarC |
October 27, 2002 |
In-person, Shanghai, China |
Transfers Task Force Open Consultation |
Task Force, Open |
October 28, 2002 |
In-person, Shanghai, China |
Registrar Constituency Briefing |
Task Force Rep., R’rarC |
October 29, 2002 |
In-person, Shanghai, China |
DNSO Open-Forum |
Task Force, Open |
November 11, 2002 |
Teleconference |
Transfers Task Force Registrar Consultation |
Task Force Rep., R’rarC |
November 12, 2002 |
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open |
II. Public and Constituency Comments
Received by the Task Force
Public Comments on Task Force Interim Report, October 16 - 30, 2002 (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/)
Total number of posts as of 11-11-02: |
13 |
Total number of substantive comments to the report[1]: |
5 |
Substantive comments include:
1. General Counsel’s Briefing Concerning the Implementation of Policies
by Registrars and Registry Operators (http://www.icann.org/legal/briefing-on-implementation-20oct02.htm)
- Specific guidance to the Task Force in developing policies that
can be implemented under ICANN's agreements, so that the goals the
policies are intended to promote can be achieved.
2. From Tim Ruiz (et al) (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/doc00000.doc)
- fraudulent transfers are more of a problem than recognized
- proposal doesn’t protect from deceptive marketing
- auto-ack plays into fraudulently obtained apparent authority
- needs to be another Registrar constituency vote
- significant changes necessary to agreements
- significant changes to Registrar/Registry systems
3. From Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00006.html)
- A synopsis of various consumer complaints concerning transfers including:
- Registrars employing an “auto-n’ack” policy
- confusing emails attempting to authenticate Registrant wishes
- improper rejection of transfer requests by losing Registrars
- arduous processes imposed by losing Registrars
- poor customer support
- unclear and inconsistent rules regarding when a domain name
may be transferred
- deceptive or confusing marketing practices designed to retain
customers
- foreign language issues
- inaccurate Whois data complicating the transfer process
- inability to update Whois data
- “apparent authority” not properly defined
- unpaid status should not affect ability to transfer
- procedures should be uniform for all Registrars
- Registrars and their resellers should communicate policies
better
- Registrar failure to release auth codes
- inappropriate use of the Registrar Lock feature
- unauthorized transfers / “domain hijacking”
- transfer-away charges by losing Registrars
- failure to address complaints / poor contract enforcement
4. From Scott Hollenbeck (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00009.html)
- comments re: EPP operational models
5. From Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00011.html)
- a summary of duties imposed by the policy
6. From Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00013.html)
- Description of the Names Council Rules of Procedure, and how the
Interim Report doesn't follow same.
(Note: The following section was added 12-12-02 in order that the
Final Report included all comments received by the Task Force during its
final public comment period.) Public Comments on Task Force Final Report, November 30 - December
8, 2002 (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/)
Total number of posts as of 12-12-02 |
9 |
Total number of substantive comments to the report[7]: |
6 |
Substantive Comments include:
1. From Elana Broitman (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00001.html)
- questions concerning what constitutes a "Constituency Impact Statements"
and the inability of the Registrar Constituency to create and provide
one within the eight days allotted.
2. From Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00002.html)
- Comments concerning the perceived deficiencies of the process followed
by the Task Force and the data and analysis presented in the Final
Report of the Task Force.
3. From Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00003.html)
- concerned with the limited time during which the Final Report was
available for comment.
4. From Jeff Williams (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00004.html)
- concurs with Broitman's assessment (above)
- concurs with Youngers criticism (above)
- concerned with the lack of contact information in the Final Report
- concerned with the lack of choice and lack of diversity that ICANN's
accreditation regime creates.
5. From the Registry Constituency (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00005.html)
- requests formally that no action be taken on the Final Report at
the December 14, 2002 Names Council meeting;
- too little time to for the Internet community to analyse and
respond to,
- Final Report has sparked community discussion that needs to
be taken into account.
- Registry Constituency supports many of the recommendations of
the Final Report, but is reserving adopting a final position until
such time that the issue has been worked out in other Constituencies,
including the Registrar Constituency.
- Proposes deferring the issue for action until the January, 2003
Names Council meeting.
6. From Chuck Gomes (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00007.html)
- presents a list of sixteen principles that have been formally endorsed
by ten ICANN Accredited Registrars.
- Notes the critical nature of Registrar support for the proposed
policies and encourages other Registrars that also support the document
to also provide a formal indication of support.
Minority
Reports
The Names Council Rules of Procedure specifies that any Consensus Policy
Recommendations of a Task Force must include "a fair statement of
points in opposition and a substantive analysis of their merits and the
intensity of the opposition."
While the Task Force has not, to date, received any substantive submissions
that would qualify, classically, as a true "Minority Report",
the Task Force has received many inquiries and comments that would qualify
for inclusion in this section of the report as per the standards for a
“Minority Report” as set forth in the Names Council Rules of Procedure.
This portion of the Final Report is presented in "Questions &
Answer" format focusing on the inquiries and comments that the Task
Force received, informally and formally, throughout the term of the Task
Force. We believe that each of these implications is substantively addressed
by the Policy Recommendations of the Task Force and this report. Each
answer to these questions is accompanied by an analysis of the merit and
intensity of the objection presented.
1. "It appears that the Task Force only addressed the considerations
raised by one proposal that was put forward by the community and not
others that have been presented. Doesn’t the Task Force have a requirement
to deal with all substantive proposals put forward by the community?"
A. Throughout the evolution of this issue and the ensuing work of the
Task Force, a number of proposals have, and continue to, surface with
the intention of dealing with the concerns raised by the community.
After thorough examination of the issues and approaches, the Task
Force did not believe that any of these alternate proposals substantively
deal with the entire breadth and depth of the issues and therefore do
not represent complete or supportable (by consensus) solutions. In developing
the recommendations included in this Final Report, the Task Force analysed
as many of these proposals as possible, taking into account that there
were several periods during which substantive comments and proposals
could have been submitted notwithstanding, that some of the proposals
were received long after the close of public comment periods, (they
continue to surface including as recently as 11/27/02). Where supported
by community consensus, the principles and policies embodied in these
alternate propositions were included in this report to the maximum extent
possible.
Recognizing that the development of these policies has taken an inordinately
long period of time due to the complexity of the issues and that the
DNSO wishes to resolve these issues within a reasonable period of time,
the Task Force has explicitly recommended a framework for the review
of the implementation of any policy adopted as a result of this document
at various set time frames by the Names Council and its successor bodies.
These review requirements are intended to ensure that ICANN can continue
to refine the new consensus policies while learning from their implementation.
Analysis:This concern was raised on a very a limited basis.
Given the limited visibility that the Task Force has had to some
of these alternate proposals, and the limited involvement that the
broad community has had in developing or in any way participating
or commenting on these alternate proposals, the Task Force does
not feel that this comment can be considered a reasoned opposition
to the recommendations of the Task Force. |
2. "The policy recommendations that you have put forth don’t
seem to adequately set forth enough clarity to provide Registrants,
Registrars and registries with the necessary level of confidence. Shouldn’t
the Task Force deal with the issue of setting clear definition for all
aspects of the transfer process?"
A. There is a substantial difference between creating policy recommendations
that clearly outline a predictable process that engenders Registrant,
Registrar and Registry confidence and one that attempts to define all
aspects of the transfer process. In attempt to address this particular
concern, the Task Force primarily concentrated on fulfilling the requirements
imposed by the former. Recognizing that dealing in terms that are easily
understandable by the broad range of impacted parties, the Task Force
created a list of standardized definitions that should address this
concern. Further, the Task Force has also provided information
in several exhibits which we recommend to the Implementation Process.
These are presented as "informational" only, although they
represented extensive work by the Task Force and take into account many
hours of consultation.
Analysis: Crafting recommendations that not only dealt
with the substance of the policy, but the definable terms of the
industry were not within the scope of this Task Force. The Task
Force feels that the implied need for a high-degree of clarity with
these recommendations as raised by this type of inquiry was heard
by and dealt with by the Task Force. Concerns of this nature were
expressed on an extremely limited basis. Other concerns were heard
that the Task Force work may be too detailed. The Task Force has
attempted to balance what it sees as the scope of work of a Task
Force in recommending policy, has provided informational background
and other outputs of its work, but has limited the recommendations
to higher level statements. |
3. "Although it was raised numerous times, the Task Force does
not make any specific recommendations concerning the issue of 'Apparent
Authority' as it currently exists under the present policy. How does
this report deal with those issues?"
A. During the course of developing these recommendations, the Task
Force devoted significant time and attention to understanding not only
the notion of Apparent Authority as it is embodied under the existing
transfers related policies, but also in trying to understand the intent
of these policies. The Task Force took into account the comments, which
were from a limited number of submitters, regarding "apparent authority",
sought guidance from ICANN legal staff and engaged in extensive examinations
of its usefulness. As a result of this deliberation, the Task Force
came to the decision that the notion of "Apparent Authority"
was not sufficiently precise to provide Registrants, Registrars and
Registries with the transparency, security, reliability and predictability
in the transfer process that is necessary to satisfy the needs of the
broadest possible range of impacted parties. Accordingly, the concept
of "Apparent Authority" has been replaced by a much narrow
range of entities that are authorized to approve a transfer.
Analysis: The Task Force believes that the range of recommendations
intended to replace the notion of Apparent Authority are reasonably
exhaustive and directly address the requirements of the community.
Further, the Task Force did not receive substantial objection to
this range of recommendations outside of the concerns raised by
an individual several times in the process, and a minority number
of total accredited Registrars[2]
as a result of the public comment period following the publication
of the Draft Interim Report. Signatories to this document include
Register.com, Verisign and other "top 20" Registrars,
but did not include a majority of Registrars, or "top 20"
Registrars for that matter. The Task Force notes that this
group of Registrars raised concerns predicated on the concept that
some notion of "Apparent Authority" would continue to
exist within the policy going forward. Given that these recommendations
explicitly abandon all notions of "Apparent Authority"
and replace it with much more stringent "proofs of authorization"
the Task Force concluded that these concerns were addressed by the
Task Force recommendations. |
4. "Some parties like to 'create their own policies' and we
always therefore seem to end up with a system that can be easily gamed.
How does this report deal with this issue?"
A. The Task Force heard a broad range of concerns voiced by parties
across all stakeholder groups that indicated that insofar as “gaming”
was occurring in contravention of established policies, or where policy
did not exist, that the Task Force should attempt to address the implications
raised by this behavior in a pro-active manner. Accordingly, the Task
Force recommendations attempt to fill as many policy gaps as possible
whilst not unduly impacting any specific group in a negative manner.
Broadly speaking, the Task Force accomplished this through two means;
a) clarifying that it was the Gaining Registrar that is obligated to
verify the intent of the Registrant and b) limiting the range of reasons
why a transfer should not be approved. Given that the Task Force understood
from the user communities that it was these two areas that were most
affecting their capability to effectively transfer their domain names
under the current policy[3]
we have every reason to believe that the recommendations made in these
two areas will address the broadest possible range of issues while reserving
maximum flexibility of implementation for Registries and Registrars.
Analysis: It is impossible for any policy to be fool-proof,
i.e. – "non-gameable". Inappropriate implementation
of policy, or worse, abuse under a specific policy will only occur
insofar as the potential gain to be obtained by the abuse exceeds
any penalties that might be incurred as a result of being caught
as an abuser. The current policies governing transfers do not
contain any penalties, save loss of accreditation. Therefore,
in most cases, the gain to be had as a result of an infraction
often outweighs any possibility that single applicable penalty
could be applied.
While this concern is widely held in the community, the Task
Force believes that it is also the consensus of the community
that the measures taken under these recommendations will effectively
address these concerns. In the event that serious problems still
exist, the proposed evaluation process will identify those and
enable further work to be undertaken, as recommended by the Names
Council. |
5. "How can 'third parties' authenticate transfers under these
recommendations?"
A. The proposed policy limits the number and type of entities that
can verify the intention to transfer to the Administrative Contact or
the Registrant. Therefore, if the Registrant wishes to provide a third
party with the capability to acknowledge or deny transfer requests from
Gaining Registrars, the Registrant should designate this third party
as being the Administrative Contact of record. The Task Force heard
from a limited number of entities about their concerns, but also their
support for the need for an effective process. Such comments are part
of the record of consultation.
Analysis: This concern was raised by a limited number
of entities. However, those that did raise this concern would
be drastically affected by the impact of this report with the
absence of this capability. The Task Force considers these concerns
reasoned, and believes that the recommendations contained in this
document suitably address the needs of this group of stakeholders. |
6. "Sometimes resellers and ISPs represent the Registrant.
Without the notion of 'Apparent Authority' it will be impossible for
these parties to authenticate a transfer. How is this addressed in these
recommendations?"
This is essentially the same question as question 5. Registrants must
understand what they are delegating to a third party. We believe that
this question is a reasoned one, and that the solution proposed addresses
it. In addition, where the Registry uses auth-info codes, the
Registrant would be free to share that code with the entity they designate
to act on their behalf.
7. "Non-providers need to participate in the policy development
process. How did the task force address the requirements of 'users'
(i.e. – Registrants) during the formulation of these recommendations?"
A. Various classes of Registrants were consulted through during the
development of this report through the outreach marked in other portions
of this document. Further, most, if not all, classes of users were directly
represented through representative membership on the Task Force. Classes
of Registrants that were not directly represented were specifically
sought out by the Task Force to ensure that the recommendations were
appropriate for their needs. Because of our concerns about Registrants,
the Task Force held numerous outreach sessions. At some point, the Task
Force needed to determine that they had gathered sufficient input about
the impact on Registrants to make policy recommendations.
Analysis: The Task Force believes that all classes of
Registrants were adequately represented and consulted through
the development of the policy recommendations contained in this
report. |
8. "Even when the best policies are adhered to in the strictest
manner by all participants, sometimes things go wrong. With domain names,
this might mean that a Registrant is left without the use of their domain
name for a period of time. Under the current policy, this often means
that Registrants have to hope for the best and put their fate in the
hands of a Registrar who may or may not cooperate when it comes
to 'making things right'. Does this report deal with this dynamic in
a meaningful way?"
A. Specifically, yes. This dynamic is addressed in two ways. First,
the report recommends a dispute resolution process by which Registrants
can work with their Registrar to have their problems formally resolved
according to a predefined process. The Task Force envisions that this
process will be substantially similar to the current Uniform Dispute
Resolution Policy. Secondly, the Task Force also recommends that gTLD
Registry Providers augment their business capabilities with an “undo
function” that would return the domain registration to a previous state
that would be, in all respects, functionally identical to the state
that the domain name was in prior to any errors or meddling that may
have occurred.
Analysis:: This concern was raised by a number of Registrants
and Registrars. The Task Force finds this concern reasonable in
every regard and believes that the recommendations set forth fully
address these concerns and reflect the consensus of the community.
The Task Force did not specifically address how the Dispute Resolution
process would be finally developed, or who would offer it. The
Task Force does provide as an Appendix a possible "model",
based on the work of the Task Force to fully understand the issues
involved. This is presented as "informational" only. |
9. "Some Registrars liberally employ the 'Registrar lock' function
as it relates to the domain names they register for Registrants. This
often means that Registrant’s *can’t* transfer their domain name in
a predictable way. Do the Task Force recommendations consider this?"
A. Through extensive discussion within the Task Force
and further consultation with the community after the Interim Report,
the Task Force formed a minor series of amended recommendations that
simply requires Registrars to provide Registrants with simple and transparent
mechanisms by which Registrants can simply unlock or lock their domain
name using accessible processes established by the Registrar.
Analysis: The Task Force heard this concern from several
user groups. Earlier versions of this report contained substantially
more stringent recommendations, however further discussion within
the Task Force and outreach to various stakeholders within the
DNSO only drew the lack of consensus on the older recommendations
into focus. Accordingly the Task Force re-crafted its recommendations
in order to support the principles that were supported by consensus. |
10. "Shouldn't the documentation procured by the Gaining Registrar
be subject to some higher standard due to the influence they have over
the system? If the documents that they obtained were notarized or otherwise
authenticated, the process would be much more secure for Registrants."
A. While more stringent processes such as those described in this question
might arguably create a more secure environment for Registrants; overly
strict processes do not provide the requisite levels of portability
that Registrants have clearly voiced strong preference for. The key
to any successful transfer policy lies with striking a balance between
the security and stability requirements of Registrars, Registries and
Registrants with the transparency and portability requirements of these
same groups. Comments were heard by the Task Force in objection to the
cost and inconvenience of notarized statements, as well as expressions
by some Registrars about wanting to require such documents.
Some concerns were also raised about requiring individuals, even when
representing a company or organization, to fax in copies of personal
driver’s licenses, which may include social security numbers, etc.
Analysis: This concern was primarily raised by a minority
of larger Registrars. While the proposed recommendation may have
some benefits for Registrants, this was not been supported by
quantifiable data, or echoed in the requirements set forth by
Registrants. Accordingly, the Task Force opted instead to strike
an appropriate balance between security and portability rather
than moving too far in either direction. |
11. "How closely did the Task Force follow the discussions
that took place in various forums throughout the DNSO and the rest of
the community?"
A. The Task Force believes that the membership of the Task Force has
a thorough understanding of the broad range of issues raised by the
community in various forums. This was accomplished through the various
open briefings, mailing list participation, public consultations, teleconferences
and outreach sessions that the Task Force membership conducted and involved
themselves in throughout the DNSO. Several Task Force members are members
of the General Assembly, for instance. And, the General Assembly itself
is represented on the Task Force. As other discussions were made
public, the Task Force tried to avail itself of such information.
Analysis: The Task Force has considered whether or not
it has gathered and analysed sufficient input from the community
and feels that the understanding of the Task Force, augmented by
the extensive outreach and consultation undertaken is sufficiently
broad and representative as to ensure appropriately formed conclusions.
This concern was raised by a substantially limited number of parties. |
12. "Doesn't 'auto-ack' simply encourage fraudulent activity
to occur?"
A. The specific actions of "ack" or "n'ack" in
and of themselves neither encourage, nor discourage fraudulent activity
and the Task Force continues to question the basis for such conclusions.
The Task Force does however believe that the processes employed in conjunction
with default "ack" or "n'ack" processes by the various
parties involved in a transfer transaction may lead to higher or lower
incidences of fraud. Whether these processes lead to higher or lower
incidences of fraud are solely dependent on whether or not appropriate
behaviour is incented or discouraged. Given the overwhelming stated
need for portability coupled with balanced security, the Task Force
determined that there is consensus support for a default "ack"
policy coupled with strong authentication and enforcement measures.
Default "ack" was almost universally preferred over the alternatives
due to the enhanced portability and stability that it offered Registrants,
the similarity of the process to existing policy and the relatively
low complexity and impact that the processes posed in comparison to
the alternatives.
Analysis:: This argument was most often presented by proponents
of the default "n'ack" policy. The Task Force took into
account the concerns expressed that fraudulent transfers or "slamming"
were serious and substantial in number. The Task Force agrees that
fraudulent or slamming transfers are a serious concern. The research
presented by the proponents of "n'ack" and discussions
with ICANN staff did not bear out a concern that there are overriding
numbers of such occurrences. The Task Force still takes such complaints
and concerns seriously. Given that the behavior of the losing Registrar
is but one aspect to a comprehensive policy recommendation and that
users voiced a strong preference for an appropriate balance between
security, portability, transparency and stability the Task Force
chose to deal with the more holistic approach set forth in the Registrar
Constituency submission to the Task Force[4].
The Task Force also recommended a mechanism for a concerned losing
Registrar to contact the Registrant. The Task Force notes
that ICANN staff are in a good position to fully understand the
kinds of complaints which exists about transfers, and that the ongoing
review process should include periodic reports by ICANN staff to
the Names Council/its successor of the kinds of transfer problems
which are occurring. |
13. "Why don't these recommendations also address how to protect
Registrants from unscrupulous marketing practices?"
A. The Task Force was tasked to consider the very narrow issue of transfers.
Where possible, the Task Force attempted to craft recommendations which
addressed the complaints the Task Force received about how certain communications
led to an undesired transfer by the Registrant. Our recommendations
are targeted at transfer process, not marketing practices. Based on
substantial input from Registrars, Registries and Registrants, the Task
Force specifically recommended that standardized, transparent processes
and documents be employed where appropriate. The Task Force believes
that this strikes a reasonable balance between the concerns raised and
the scope of the mandate of the DNSO Policy Development process and
this Task Force. The Task Force notes that as usual, complaints about
deceptive marketing should be referred by ICANN staff, or the Registrant,
or even another Registrar or Registry who becomes concerned to the appropriate
legal authority, such in the U.S. the State Attorney General, or the
Federal Trade Commission. In other countries, similar authorities exist.
The Task Force did not address nor consider that the area of marketing
practices are within the scope of the Task Force.
Analysis: This concern was raised in a letter received
from a group of Registrars. The Task Force does not believe
that it is particularly well-founded given that it primarily questions
why the Task Force did not craft recommendations that were specifically
outside the mandate of the Names Council. Regardless, the Task Force
believes that where appropriate, it has dealt with the potential
that the transfer process can be abused using questionable marketing
tactics by requiring the implementation of several standardized
processes as set forth in the reasoned requirements of the Registrar,
Registry and Registrant groups. |
14. "Fraudulent transfers pose a far greater problem than does
'Registrar gaming' of the current policies. Why weren’t fraudulent transfers
more explicitly dealt with?"
A. The Task Force took this complaint seriously and tried to establish
some degree of quantification or documentation from the concerned entities
and the ICANN staff. In the end, the Task Force did not have any data
to support the stated conclusion. Despite repeated requests, this claim
was never quantified in any meaningful manner and was in fact specifically
countered by data provided by ICANN staff that indicated that the volume
of complaints concerning the inability of Registrants to transfer their
domain names in a timely manner vastly outweighed any complaints of
fraudulent activity.
Noting that the implications posed by the fraudulent transfer of domain
names (i.e.: slamming & hijacking), the Task Force concluded that
strong enforcement and remediation processes would be desirable. Consultation
with the community confirmed strong consensus support for this approach.
Analysis: This concern was repeatedly raised by the proponents
of the default n'ack policy. Given that the Interim Report as well
as the Final Recommendations of the Task Force has consistently
included strong remedial functions designed to ameliorate the effects
of fraudulent transfers, the Task Force concluded that this concern
was not sufficiently documented, and therefore not sufficiently
reasoned to substantially consider in this Final Report. See
other comments above in Question 12. |
15. "Major Registrars are auto-n'acking and they report that
this has substantially reduced fraudulent transfers. Wouldn’t allowing
the losing Registrar to 'auto-n'ack' have achieved the desired results?
What’s wrong with the current policy?"
As noted elsewhere in this analysis, default "n'ack" addresses
only one relatively uncomplicated aspect of the larger policy issue
and does not meet the broader needs stated by the larger community.
Further, existing policy, as has been continuously demonstrated throughout
this policy development effort, does not provide strict enough standards
or the requisite enforcement function to make the policy truly useful.
It must be acknowledged that there are high numbers of complaints about
the present 'auto –n'ack' practices, not only from Registrars, but from
Registrants. These complaints led to the creation of the Task
Force and efforts to understand how to revise policy in the first place.
Analysis: Again, this contention was put forward by the
Registrars that are "auto-n'acking". As noted elsewhere,
this contention that there are high numbers of fraudulent transfers
was not sufficiently supported in a quantifiable manner by its proponents
and the Task Force was therefore unable to consider it as a "reasoned"
proposition. The evaluation process should enable the ability to
determine what volume actually exists in terms of fraud, slamming,
etc. |
16. "The current proposal creates an incentive for gaining
Registrars to obtain the customer's "apparent authority" by more
avenues, possibly including deceptive marketing practices, since it
will allow for transfers without verification of the Registrant's objective
manifestation of intent to transfer. How does the proposal address
the situation where 'apparent authority' is obtained by fraud or deceptive
marketing?"
A. First, "apparent authority" is replaced by a better defined
process for determining who can authorize a legitimate transfer.
Secondly, where auth info codes are used by the Registry, these provide
additional safeguards. Finally, and very importantly, the recommendations
specifically describe a number of remedial procedures that will allow
a Registrant or Registrar to "right" any wrongs caused as
a result of any intentional or unintentional infractions of policies
implemented as a result of these obligations.
Analysis: While the recommendations presented in this report
do provide remedy for intentional or unintentional violations of
these recommendations, the Task Force does not adequately understand
all of the concerns raised by this objection, and, despite repeated
requests for clarification, was not provided with a clear understanding
of this objection. Specifically, The Task Force recommendations
eliminate the notion of Apparent Authority, restrict the number
of entities that can approve a transfer request, standardize the
process by which a Gaining Registrar verifies such a request and
specifically states that transfers may not occur without the express
consent of an authorized entity. The Task Force takes concerns of
this nature seriously, but did not receive clarification from those
raising the objection, and therefore, the Task Force is unable to
appropriately analyse these contentions or consider them in this
Final Report. |
17. "This proposal is based on old thinking by the Registrar
Constituency which no longer has the support of the community. Shouldn’t
the Task Force allow for more time to explore alternatives?"
A. As was explained in the Executive Summary, the Registrar Constituency
is but one stakeholder in this process. Further, the Task Force spent
more than a year in consultation with the community exploring the full
range of alternatives. While we cannot evaluate proposals that we have
not received, we strongly feel that the time to implement changes which
are supported broadly by the community is now and believe that these
recommendations are reflective of community support and consensus.
Analysis: This contention was raised by the opponents of
the Interim Report that were signatory to the Ruiz et al document.
The Task Force invested significant time and effort in seeking to
understand the concerns of these parties, in consulting with these
parties and others, and exploring the specific proposals that they
developed or participated in the development of. Perhaps most importantly,
the substantive recommendations that this group did put forward
are extensively dealt with by this report. The Task Force does not
therefore believe that further delay spent exploring further alternatives
in any way benefits the community. This does not appear, on its
face, to be a reasonable request requiring further consideration
by the Task Force. |
18. "Won't implementing these changes require significant alteration
to the existing contracts? Should impacted parties have an opportunity
to amend or negotiate these provisions before they are included in a
contract?"
A. New and amended policy usually requires the alteration of relevant
contracts in some manner. The Task Force does not have the legal expertise,
or the mandate to determine whether or not implementing these policy
recommendations would require "significant alterations" to
the existing contracts, nor even what contracts would need to be amended
in order to achieve these objectives. We benefited from guidance
from the General Counsel, and ICANN staff regarding some of the areas
where consensus policy could require contract or Registrar Accreditation
Agreement changes. However, again, the Task Force itself believes that
it should not be engaged in legal analysis to the extent that the question
implies. As to whether or not impacted (contracted) parties should have
the opportunity to amend or negotiate these provisions before they are
included in the contract, the Task Force notes that these recommendations
are the consensus position of the community and therefore should be
implemented as written with the exception of specific implementation
details which should be left for the ICANN Staff and contracted parties
to consider, document and implement. The Task Force also believes that
if significant changes are made to the consensus policy recommendations
during implementation, such changes should be reviewed with the Names
Council/its successor. Otherwise, affected parties who are users would
not be considered in such overriding changes, nor have a chance to comment.
The question as presented seemed to consider that only Registrars or
registries may be "affected parties". The Consensus process
of the DNSO and its successor requires that the input and concerns of
a broad range of stakeholders be taken into account.
Analysis: This contention was solely raised by the signatories
of the Ruiz et al document. Given the limited mandate of the Task
, the importance of relying upon ICANN staff for such analysis and
counsel, and overall the policy implications of this matter, the
Task Force does not find this to be a reasonable submission. |
19. "Won't implementing these changes require Registries and Registrars
to undertake significant changes to their systems and therefore incur
significant costs that Registrants would ultimately be forced to bear?"
A. The answer to this question is dependant on the definition of “significant”.
As cost and impact are relative considerations, there is no single answer
to this question. The answers depend on the size and capability of each
specific Registrar or Registry and the processes they currently employ.
The Task Force believes that:
- The technical or economic costs that may arise from the implications
of these recommendations would not be unreasonable.
- Any implementation of these recommendations would not create any
excessive or undue burden for any impacted party.
Further, the Task Force recognizes that Registrants, Registrars and
Registries will all be impacted by these recommendations but that over
the long term these will be largely social in nature (i.e. – education
as to the nature of the revised policies) and will be outweighed by
the economic effects created by predictable, stable, transparent and
secure policies that engender the confidence of Registrants, Registrars
and Registries.
Analysis: The Task Force notes that its consideration
of cost and impact on affected parties is limited by the Names
Council Rules of Procedure and but that its consensus policy recommendations
must ensure that "…the Registrar or Registry operator
has reasonable protections in its business from the effects of
having to implement the policy, such as a reasonable time to implement
the policy and a reasonable opportunity to pass on any costs of
implementing the policy to its customers."[5]
The Task Force is not aware of similar conditions that would provide
Registrars with a "last chance" opportunity to renegotiate
what the DNSO consensus recommendations mean. To the contrary,
Registrars have specific obligations to adopt consensus policies
ratified by ICANN and have every opportunity to participate in
the development of these recommendations.
Given that the "contracted parties" have full opportunity
to pass on any costs that may arise from the implementation of
these recommendations and that no specific "deadline for
implementation" is determined by these recommendations the
Task Force does not find that this concerned is reasoned. Further,
given that this concern was set forth by Registrars expressing
concern for Registrants, one should conceivably be able to uncover
parallel concerns voiced by the Registrant community. The Task
Force received substantial comment from the Registrant community
that indicated that the total cost of ownership of a domain name
was but one small component of their consideration. Understanding
that this concern was solely raised by a subset of Registrars,
the Task Force does not find sufficient support for this notion
to give it significant weight within the recommendations of this
report. |
Historical Proposals
Broitman, Elana. "[Registrars] Registrar transfers."
Online Posting. June 29, 2001. Registrar Constituency Mailing List.
November 27, 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/msg00776.html>
Cochetti, Roger. "Letter from Roger Cochetti to Stuart
Lynn." ICANN. July 16, 2001. Verisign, Inc. November 27, 2002.
<http://www.icann.org/correspondence/cochetti-to-lynn-16jul01.htm>
Rader, Ross. "Inter-Registrar Domain Name Transfers
Process Description & Overview." Proposal for Standardized
Inter-Registrar Domain Transfers. August 26, 2001. Tucows Inc. November
27, 2002. <http://www.byte.org/rc-transfers/>
Broitman, Elana, and Ross Wm. Rader. "Inter-Registrar
Domain Name Transfers; Principles & Processes for Gaining and Losing
Registrars." ICANN-Registrars. October 1, 2001. ICANN DNSO
Registrar Constituency. November 27, 2002. <http://www.icann-Registrars.org/pdfs/rc-irdx-091801-v1r0d8.PDF>
Gomes, Chuck, and Elliot Noss. "Mediated Authorization".
DNSO Registrar Constituency Mailing List Archives. November 6, 2002.
Verisign, Inc. & Tucows Inc. November 27, 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/doc00128.doc
>
Gomes, Chuck et al. "[Registrars] Fw: Principles."
Online Posting. November 27, 2002. Registrar Constituency Mailing List.
November 27, 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/msg03652.html>
Exhibits
Exhibit A: Reference
Application
Exhibit B: Proposed
Dispute Resolution Model
Exhibit C: Standardized
Definitions
Exhibit D: Transfers
Implementation Task Force Report
Exhibit E: End
Notes
Comments concerning
the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
17-Dec-2007
©2003 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.
|