[registrars] .US Transfer Proposal

["Michael D. Palage" <michael@palage.com>]

Hello All:

Attached please find a proposal that I will be submitting to the .US Policy
Council in advance of our next call on December 10th. I would appreciate any
comments that people could provide to enhance this proposal. Although I
respect the work of ICANN Transfer Task Force, I believe that the technical
mechanism associated with the EPP Registry Protocol can resolve the
ambiguities currently associated with the RRP Registry Protocol. By
advancing an industry lead, market driven, non-regulatory solution to the
transfer problem, I believe that this will help expediate the adoption of
this solution by ICANN sanctioned TLDs. Moreover, implementing an acceptable
EPP based solution today will help provide a level of stability should
VeriSign decide to transition toward an EPP Registry Protocol.

To illustrate the benefits of this proposal versus the considerations
currently being discussed in connection with the VRSN Registry proposal,
please look at how this proposal related to the 16 principles previously
advanced by VRSN Registry.

Best regards,

Mike

P.S. The designated representative for Registrar on the .US Policy Council
is Tom Cunningham from Bulk Register.






1. Registrars should provide a unique and private emailaddress for use only
by other registrars and the registry.

Comment: Not required under .US Proposal.

2. Admin contact is the default authority.

Comment: Under the .US Proposal Admin contact and Registrant share equal
power and either can authorize a transfer provided that they have the auth
code.

3. Registrant may overrule admin contact authority.

Comment: Under the .US Proposal Admin contact and Registrant share equal
power and either can authorize a transfer provided that they have the auth
code.

4. All transfer process communications to registrants from losing and
gaining registrars should be standardized.

Comment: No need for standardization of communication, provision of the auth
code by either admin contract or registrant is sufficient.


5. Registrars should provide special, standardized Whois access, which may
be separate from public Whois access, to other registrars and the registry
solely for the purpose of transacting transfers.

Comment: Not necessary


6. 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.

Comment: Not applicable, since there is no need for a special Whois.


7. Minimum, standardized documentation should be required of registrars for
all transfer procedure steps for use in dispute
resolution.

Comment: Agreed that this is a good idea. However, since the registrant will
have to contact his registrar of record to obtain the Auth Info Code, there
is an adequate safegaurd for the losing registrar to notify the registrant
in their native language of the significance of requesting the Auth Info
Code.

8. 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 in principle 5 above is satisfied.

Comments: Since the registrant will have to contact his registrar of record
to obtain the Auth Info Code, there is an adequate safegaurd for the losing
registrar to notify the registrant in their native language of the
significance of requesting the Auth Info Code.

9. Only registrars may initiate disputes.  If registrants want to initiate a
dispute, it must be done through a registrar.

Comment: The reliance on the Auth Info Code removes the need for a dispute
mechanism.

10. The registry is responsible for first level dispute resolution.

Comment: The reliance on the Auth Info Code removes the need for a dispute
mechanism.

11. There will be a non-judicial second-level dispute resolution process for
appeals.

Comment: The reliance on the Auth Info Code removes the need for a dispute
mechanism.

12. Losing and gaining registrars should be required to complete specific
transfer process steps within to-be-determined and
specifically defined time periods.

Comment: Good idea. This proposal requires no alteration of the .US Transfer
proposal.

13. Only losing or gaining registrar should authenticate the transfer
request, not both.

Comment: Under the .US Transfer proposal the registrant must interact with
both registrar to verify the process, i.e. obtain Auth Info Code from losing
registrar and provide it to the gaining registrar. Because registrar must
provide registrant with access to the Auth Info Code, there is no mechanism
by which a losing registrar could hijack or stall the process.

14. If some form of auth code is used, the same auth code must be used for
the same domain name and the same gaining registrar.

Comment: Still confused over this wording. The Auth Info Code stored at the
Registry and available to the Losing Registrar and Registrant is the only
Auth Info Code used in the transfer process.


15. If a new transfer process is adopted, the new process replaces the old
process (i.e., a registrar can't use the new process and the old process as
a follow up to restrict a transfer).

Comment: No objection.

16. Reasons for a losing registrar to deny a transfer: Evidence of fraud;
UDRP action; Court order; Non-payment for previous registration period if
transfer is requested after the expiration date or non-payment for the
current registration period if transfer is requested before the expiration
date.

Comment: No objection.

Transfer-Proposal.doc