Registrar Constituency Position on Inter-Registrar Transfer Policy Issues
October 3, 2008
Registrar Constituency Position on Inter-Registrar Transfer Policy Issues
BACKGROUND
In September 2008, the Registrar Constituency ("RC") was asked to provide
feedback regarding three Inter-Registrar Transfer Policy ("IRTP") issues. This
Position Paper captures the overall sentiment expressed by the RC Members who
provided feedback about this matter and seems to reflect the general sense of
the RC. Due to time constraints, however, no formal vote regarding this
Position Paper was taken.
RC POSITION
The RC's position regarding each of the three IRTP issues is as follows:
1. Is there a way for registrars to make Registrant E-mail Address data
available to one another?
No viable secure implementation of this proposal has been advanced that would
enable a policy to require registrars to make Registrant E-mail Address data
available to one another.
Additionally, the RC believes that regulatory intervention is not necessary to
address this issue. This issue is more appropriate for market based solutions
rather than regulatory intervention.
1. Whether there is need for other options for electronic authentication
(e.g., security token in the Form of Authorization (FOA)) due to security
concerns on use of email addresses (potential for hacking or spoofing).
The RC does not believe that a regulatory approach to authentication is
necessary. The RC recommends that the questions of whether additional
authentication technology is needed, and if so which technology to implement,
be decided based on market demands rather than regulation.
To that end, the RC cautions ICANN about the unintended consequences of
technology directives. Specifically, any mandated technology is guaranteed to
become the target of hackers who seek to circumvent its security. Having the
option of a variety of technologies which may be developed and implemented
based on market demands offers greater security in the long-run.
1. Whether the policy should incorporate provisions for handling "partial
bulk transfers" between registrars - that is, transfers involving a number of
names but not the entire group of names held by the losing registrar.
The RC believes that, properly defined, a "partial bulk transfer" option would
be a useful tool for registrars.
There are at least three scenarios in which this option may be helpful to
registrars, including:
* A private business transaction between registrars, in which a subset of
the domains / customers from one registrar are transferred to the other;
* A registrar's reseller becomes an accredited registrar, and seeks to
change the registrar of record at the registry; or
* A registrar discontinues retail registrations in a given TLD, or is
involuntarily de-accredited by ICANN.
However, many questions remain unanswered. For example, the RC questions how
many domain names would constitute a "bulk" transfer. Also, does the term
"partial" indicate that the losing registrar would maintain some remaining
registrations in the TLD? Furthermore, what is the method for assessing fees?
Should this be a flat fee, or sliding scale? Should an additional registration
year be included or omitted from the transfer?
Also, the RC opposes any recommendations or language that extends this option
to registrant-initiated transfers for large portfolio holders on the basis that
this is better characterized as product development, not policy development. A
consensus policy would not take into account the variety of registrar business
models, and would impose the same terms, restrictions and limitations on all
registrars regardless of its applicability to their customers. Additionally,
there are several services available now that address this need.
The RC suggests that ICANN continue to let market-driven innovation and
competition address the needs of registrants who manage large domain name
portfolios, and limit the discussion of partial bulk transfers to situations
arising "between registrars."
CONCLUSION
The opinions expressed by the RC in this Position Paper should not be
interpreted to reflect the individual opinion of any particular RC member.
Attachment:
RC Position re IRTP Issues v1-3.pdf |