RE: [registrars] Fw: Principles

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

Hello All:

See my comments below.

Best regards,

Mike




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

COMMENT: Sounds like a good idea.

2.                  Admin contact is the default authority.

COMMENT: OK. However, I have some concerns about the exact wording and the
potential legal implications. Under the old NSI agreement there was language
such that the Administrative contact acted on behalf of the registrant. I do
not know if other registrars have this language.

3.                  Registrant may overrule admin contact authority.

COMMENT: Agreed, however, see comments wrt to Comment #2.


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

COMMENT: Agreed.

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: Agreed, sounds reasonable.

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: Instead of focusing on how to allow the transfer, the focus should
be on getting the registrar special whois up and operational. In the case of
a special Whois failure I believe it would be most prudent to rely on Public
Whois before authorizing a transfer.

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

COMMENT: As I have previously stated I have significant reservations about
the potential expanse of ICANN powers into a regulatory environment to
empower registries or a third party to provide dispute resolution services.
Where does it stop. We now have third party trademark owners that can
initiate an administrative proceeding against a domain name registrant. We
would now expand that authority to include dispute mechanisms between
registrar contracting parties with a registry, in which there is no privity
of contract between registrars. I am afraid of the slippery slope where
registrants would be able to resort to an administrative mechanism, instead
of relying upon the choice of law provisions incorporated into the current
registrant agreement.

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.

COMMENT: I believe that the communication should be in the language of the
current registration agreement. This is the standard used in UDRP
proceedings. I believe that this requirement would potentially be volatile
of French law which requires a French contract. Based upon my consulting
work with Afilias, there are not that many different languages in which
Registrant agreements are provided the most common are: English, Spanish,
French, German, Korean, Chinese, Japanese, etc. I do not see why this
standard communication could not be translated for the benefit of
non-English speaking registrants.


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

COMMENT: Agreed if a dispute mechanism is required. However, as commented
above this potentially starts us down a slippery slope.  I am sure the users
will be looking to expand this potential administrative mechanism to resolve
disputes with registrars regarding potential registrar error or negligence.
In such a policy battle, I really do not see any potential allies that the
registrars could join to oppose this movement. The Registries will not care
because we teamed with the users to impose this upon them. The users will be
looking out for their best interest and will be unified to find a mechanism
to resolve registrar errors. Be careful what you ask for because you might
actually get it. Although I want contracting parties to honor the terms of
their contracts, courts of law are the preferred mechanism to resolve
disputes, not an increase in ICANN's power to become a regulator by
resolving a growing amount of disputes via contract imposed administrative
mechanisms. What about registrants that act as resellers for registrars.
Would they have a contractual right to enforce their registrar to initiate
these proceedings?

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

COMMENT: For all the above reasons involving the registry as a first level
dispute provider is a bad idea.

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

COMMENT: For all the above reasons involving this is a bad idea.

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

COMMENT: Agreed

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


COMMENT: I think I agree with the concept, but the wording is a little
confusing.


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: This does not make sense to me. Moreover, please refer to the
proposed PIR Registry-Registrar Contract that requires each registrar to
provide a unique auth code. See 3.7.1. Registrars shall not provide
identical Registrar-generated <authinfo> codes for domain names registered
by different registrants with the same Registrar.
http://www.icann.org/tlds/agreements/org/registry-agmt-appf-24oct02.htm

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: Agreed, and nothing should prohibit an EPP registry from moving to
a purely auth code based verification mechanism if they so desire.


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: Sounds reasonable