ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

[registrars] Fw: [nc-transfer] RE: Please review 'Proposed Changes to Transfer Obligations'


This will be used as a reference for the conference call that just started.
Please try and have it in front of you if you are on the call.


                       -rwr


----- Original Message -----
From: "Dan Halloran" <halloran@icann.org>
To: <mcade@att.com>
Cc: <nc-transfer@dnso.org>
Sent: Tuesday, November 12, 2002 12:24 PM
Subject: [nc-transfer] RE: Please review 'Proposed Changes to Transfer
Obligations'


Marilyn,

As requested in the previous Transfers Task Force call, attached here
(and pasted below in text format) is a slightly revised version of
Appendix 1 to the "General Counsel's Briefing Concerning Implementation
of Policies by Registrars and Registry Operators" (20 October 2002)
<http://www.icann.org/legal/briefing-on-implementation-20oct02.htm>.

As discussed, that Appendix was a rough stab at outlining the proposed
changes to registry/registrar transfer obligations that were discussed
in the Interim Transfers Task Force Report.  Based on further
discussions with Ross and others, items "B" and "T" have been modified
to reflect what I understand to be the intent of the interim
recommendations.

I hope this will be helpful.  Please let me know if you have any
questions or if I can be of any further assistance with this.

Thanks,
Dan


cc: nc-transfer@dnso.org


---------

(Revised) Summary of New or Changed Registry & Registrar Obligations
from the Interim Transfers Task Force Report

12 November 2002

The following is a summary of new or changed obligations that would be
binding on registries and/or registrars if the substance of the Interim
Transfers Task Force Report was adopted and implemented by ICANN.  (For
additional background, please refer to the General Counsel's Briefing
Concerning Implementation of Policies by Registrars and Registry
Operators, 20 October 2002.)

A. Instead of being required to obtain the "express
authorization from an individual who has the apparent authority to
legally bind the Registered Name holder", registrars could initiate
transfers based (only) on "express authorization by the Registrant or
Administrative Contact of record" (Transfers Task Force Report §§ 2.4,
2.14, 3.3).

B. Registrars would be obligated to implement transfer
procedures that "take into account" registrars' and registrants' "legal,
linguistic and cultural differences" (TTF §2.9).

C. Registrars would be obligated to implement transfer
procedures that are "as clear and concise as possible in order to avoid
confusing Registrants" (TTF §2.16).

D. Registrars would be obligated to issue "AuthInfo" codes
to registrants within 72 hours of a request, and subject to no more
authentication than required for contact or nameserver information
changes (TTF §2.18).

E. Registrars would be prohibited from denying transfers or
AuthInfo code release in an attempt to secure payment for services (TTF
§2.19).

F. Registrars would be prohibited from using "Registrar
Lock" in order to secure payment from registrants (TTF §2.20).

G. Gaining registrars would be required to use a "Standard
Form of Authorization" for obtaining the approval of the registrant or
admin contact (TTF §3.4).

H. Gaining registrars would be required to produce a copy
of the authorization to the losing registrar within 3 business days upon
request (TTF 3.4.iii).

I. Losing registrars would be limited to only seven
possible reasons for denying a transfer request - fraud, UDRP action,
court order, identity dispute, non-payment for current or previous
registration term with domain on "Registrar Hold," express objection
from the registrant or administrative contact, or failure of the gaining
registrar to follow the minimum required transfer procedures (TTF §§
3.5, 5.21).

J. Losing registrars would be expressly prohibited from
using the absence of a response from the registrant or administrative
contact to a request to verify the intent to transfer (or any other
factor not listed in §3.5) as a basis for denying a transfer request
(TTF §3.6.ii).

K. Losing registrars would be prohibited from preventing
transfers of names that are on "Registrar Lock" status (*Note: this
provision would appear to require modification of the registry software
and specifications since currently all transfer requests for domains on
registrar lock result in an error.) (TTF §3.6.iii).

L. Losing registrars could not use any verification of
intent to transfer for "marketing" to existing customers, but instead
such verification must be "substantially administrative and informative
in nature" and would have to provide "clear instructions for approving
or denying the request for authorization and a concise declaration
describing the impact" of the decision (losing registrars would not be
precluded from "marketing" to existing customers through "separate
communications") (TTF §§ 3.8, 3.9).

M. Gaining registrars would be required to "capture" the
losing registrar's Whois data prior to initiating a transfer request
(TTF § 5.2).

N. Gaining registrars would be required to use a "Form of
Authorization" that "provide[s] the Registrant with clear instructions
for approving or denying the request for authorization, the identity of
the Gaining Registrar (and other parties to the transaction - e.g.
resellers) and a concise statement describing the impact of the
Registrant's decision(s)." (TTF §5.6).

O. Gaining registrars would be required to maintain
specific detailed records and logs reflecting all steps of the transfer
process (TTF §5.11).

P. Registry operators would be responsible (possibly for a
fee) for completing reviews of individual transfer requests within 14
business days of any request by a registrar. The registry operator would
be obligated to request and review all applicable documentation from
both the gaining and losing registrars, and make a finding as to whether
the transfer was initiated or denied appropriately (TTF §8.3).

Q. A new Transfer Dispute Resolution Panel would hear
registrar appeals from enforcement decisions by registries or direct
complaints from registrars concerning inappropriate transfer requests or
denials (TTF §8.5).

R. Registry operators would be obligated to "provide
whatever data is needed by the Dispute Resolution Panel" (TTF §8.5.3).

S. The Transfer Dispute Resolution Panel could order
domains to be transferred to the sponsorship of the prevailing
registrar, and could impose sanctions or penalties (to be determined) on
registrars that bring complaints without merit or initiate transfers
without authorization (TTF §§ 8.5.vi, 8.5.vi.3).

T. A losing party to a Transfer Dispute Resolution Panel
case would be obligated to refund the prevailing registrar's initial
filing fee and pay for the cost of the proceeding (TTF §8.5.vi.2).

Proposed Changes to Transfer Obligations.doc



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