<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Fw: Principles
Chuck,
We really appreciate the effort you've made to move this issue in a positive
direction. And we agree with these principles at this high level. Of course
the proof is in the pudding, or in this case the implementation. We will be
particularly interested in details regarding dispute resolution and
standardization of communications.
We also encourage a hard look at the use of auth-codes in some manner as the
best solution as you begin to hammer out the details. The use of auth-codes
may require some work on both of our parts, but we believe it is the best
long-term resolution.
Tim Ruiz
Go Daddy Software, Inc.
-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Ross Wm. Rader
Sent: Wednesday, November 27, 2002 4:14 PM
To: registrars@dnso.org
Cc: Gomes, Chuck
Subject: [registrars] Fw: Principles
Importance: High
Sent at the request of Chuck Gomes of Verisign.
Chuck has been cc'ed on this message, so if you "Reply to All" with any
questions, the list will allow him to respond publicly.
-rwr
----- Original Message -----
From: "Gomes, Chuck" <cgomes@verisign.com>
To: <ross@tucows.com>
Sent: Wednesday, November 27, 2002 3:39 PM
Subject: Principles
In discussions with several registrars over the last few months, I have come
to the conclusion that there appears to be good support for the following
principles with regard to the registrar transfer process. I have requested
that these principles be posted to the Registrars Constituency list to
encourage discussion on that list. Hopefully, agreement on basic transfer
principles by registrars will provide a foundation that can be used in
conjunction with the work of the DNSO Transfers Task Force to develop
revised transfer policies and procedures that will alleviate some of the
problems with the current process. The principles came from a variety of
sources including some from the work of the DNSO Transfers Task Force. It
should be noted that this list is by no means complete, rather it is a list
of principles for which I believe there is already strong support. I would
hope that additional principles would be added in coming weeks including
additional ones from the Task Force report.
It would be helpful to find out how many registrars support all 17 of the
principles at least at a high level, understanding that considerable
detailed work would need to be done to implement the principles. It would
also be helpful to find out if there are any registrars who oppose any of
the principles and if so, why? Please post your comments to the Registrars
List.
1. Registrars should provide a unique and private email
address for use only by other registrars and the registry.
2. Admin contact is the default authority.
3. Registrant may overrule admin contact authority.
4. All transfer process communications to registrants from
losing and gaining registrars should be standardized.
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.
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.
7. Minimum, standardized documentation should be required
of registrars for all transfer procedure steps for use in dispute
resolution.
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.
9. Only registrars may initiate disputes. If registrants
want to initiate a dispute, it must be done through a registrar.
10. The registry is responsible for first level dispute
resolution.
11. There will be a non-judicial second-level dispute
resolution process for appeals.
12. Losing and gaining registrars should be required to
complete specific transfer process steps within to-be-determined and
specifically defined time periods.
13. Only losing or gaining registrar should authenticate the
transfer request, not both.
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.
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).
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.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|