<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Joker.com's unique transfer requirements
RE: Locking domains and auth info codes.
Nikolaj,
The primary problem with either of these practices is poor implementation
by registrars.
If the lock is under the control of the registrant, where is the problem?
The Transfer TF recommendations covers this.
The biggest problems we see with auth info codes is that either the
registrar hasn't implemented any reasonable way for the registrant to get
them, or they just screwed it up in the first place by assigning the same
code to all names. It's not the concept that's flawed. The Transfer TF
recommendations covers much of this also.
Tim
-------- Original Message --------
Subject: RE: [registrars] Joker.com's unique transfer requirements
From: Nikolaj Nyholm <nikolajn@ascio.com>
Date: Fri, February 28, 2003 2:22 am
To: "'Robert F. Connelly'" <rconnell@psi-japan.com>,
"'Registrars List'" <Registrars@dnso.org>
Bob, et.al,
I agree. The policy belongs nowhere in a competitive environment.
Joker/CSL hides behind consumer protection laws in Germany, but, in
our legal council's opinion, violates EU competition laws.
Fact is that the registrant is the loser, here, as your example also
demonstrates.
Likewise, we see several CORE members practicing consumer unfriendly
behaviour like requiring registrants to 'open' a transfer slot by
faxing in an undefined template.
It strikes me that CORE (the accredited registrar) is unable to act
upon this, as administration is fully delegated to members (who are
not accredited).
Another transfer policy that I would deam anti-competitive, is the
practice of placing names on REGISTRAR-LOCK, requiring registrants to
unlock names before initiating transfers.
Finally, the challenges that registrants face across the line in
obtaining auth info codes, is simply killing.
This will become even more evident around the time of the first
renewals in the fall, when registrants will want to transfer.
The likely loser here will be the registries, as the registrant will
consider him-/herself locked down, ultimately deeming it worthless to
even renew.
/n
-----Original Message-----
From: Robert F. Connelly [mailto:rconnell@psi-japan.com]
Sent: 27. februar 2003 22:04
To: Registrar Constituency
Cc: Duane Connelly; Mieko Umezu; Naoko Orishige
Subject: [registrars] Joker.com's unique transfer requirements
Dear Colleagues: We have documents authorizing transfer of a domain
from Joker.com.
Though not required to, after the first Nack, we submitted these
documents, with the corporate seal, division seal and analysts's seal
to Joker.com. They refused to permit the transfer.
Their reason is that they do not accept *any* request for transfer
unless the *registrant* first open a ten day transfer window prior to
the issuance of a Transfer RRP request by the gaining *registrar*.
Did the reason for the denial fall within the allowable reasons for
denying a transfer under the Policy
<http://www.icann.org/tlds/agreements/verisign/registry-agmt-appf-com-
16apr0
1.htm#ExhibitB> as discussed in Louis Touton's letter to VGRS dated 27
August 2001
<http://www.icann.org/correspondence/touton-to-russo-27aug01.htm>?
Let's look at the provisions of Exhibit B:
Registrar Requirements.
The registration agreement between each Registrar and its
Registered
Name holder shall include a provision explaining that a Registered
Name holder will be prohibited from changing its Registrar during the
first 60 days after initial registration of the domain name with the
Registrar. Beginning on the 61st day after the initial registration
with the Registrar, the procedures for change in sponsoring registrar
set forth in this policy shall apply. Enforcement shall be the
responsibility of the Registrar sponsoring the domain name
registration.
[I don't see that the above applies to the present case.]
For each instance where an Registered Name holder wants to
change its
Registrar for an existing domain name (i.e., a domain name that
appears in a particular top-level domain zone file), the gaining
Registrar shall:
1) Obtain express authorization from an individual who has
the
apparent authority to legally bind the Registered Name holder (as
reflected in the database of the losing Registrar).
[We have that with the official, registered seal of the corporation.]
a) The form of the authorization is at the discretion
of each
gaining Registrar.
[Yes, it is in the form we accept.]
b) The gaining Registrar shall retain a record of
reliable
evidence of the authorization.
[Yes, we retain them.]
2) In those instances when the Registrar of record is being
changed simultaneously with a transfer of a domain name
from one party to another, the gaining Registrar shall also
obtain appropriate authorization for the transfer. Such authorization
shall include, but not be limited to, one of the following:
[There is to be no change of registrant rights. a, b and c do not
apply.]
a) A bilateral agreement between the parties.
b) The final determination of a binding dispute
resolution
body.
c) A court order.
3) Request, by the transmission of a "transfer" command as
specified in the Registry Registrar Protocol, that the
Registry database be changed to reflect the new Registrar.
a) Transmission of a "transfer" command constitutes a
representation on the part of the gaining Registrar
that:
(1) the requisite authorization has been obtained
from
the Registered Name holder listed in the database
of the losing Registrar, and
[Yes, we certify that we have done all that is required prior to
sending the RRP transfer request.]
(2) the losing Registrar will be provided with a
copy of
the authorization if and when requested.
[Though Joker.com did not request it, but we have given Joker.com a
copy of the authorization.]
In those instances when the Registrar of record denies the
requested
change of Registrar, the Registrar of record shall notify the
prospective gaining Registrar that the request was denied and the
reason for the denial.
[The reason put forth by Joker.com is that Joker.com will not accept
*any* request for transfer in which the Transfer command is issued
*prior_to* a communication initiated by the *registrant*, not the
*registrar*.]
Instances when the requested change of sponsoring Registrar may
be
denied include, but are not limited to:
1) Situations described in the Domain Name Dispute
Resolution
Policy
2) A pending bankruptcy of the Registered Name holder
3) Dispute over the identity of the Registered Name holder
4) Request to transfer sponsorship occurs within the first
60
days after the initial registration with the Registrar
[None of the above four cases apply to these cases.]
In all cases, the losing Registrar shall respond to the e-mail
notice
regarding the "transfer"request within five (5) days. Failure to
respond will result in a default "approval" of the "transfer."
[Joker.com always sends a nack within 24 hours of the request for
transfer.]
end quote and comments on Exhibit B:
Now, let's look at the procedure that Joker.com demands. These
demands are on the *registrant*, not the *registrar*:
How to Change from joker.com to
another Registrar
Please go to Servicezone to
transfer
domains from joker to another registrar.
New procedure for transfers of
domains
from joker.com to another ICANN accredited registrar
Law in Germany is oriented to
protect the
consumer. Joker.com is obligated to ask the owner and/or the admin-c
for explicit agreement in the case a domain should be transferred from
joker.com to another ICANN accredited registrar. Starting 24.04.2002
joker.com introduced a new process for those requests:
[There is no argument about the applicability of German law. They
could satisfy German law by sending an Email to the registrant or
admin contact after receiving the request for transfer from NSI.
While we would be annoyed if they sent a complex message to our
Japanese customers and then nacked the request because they did *not*
receive an affirmative reply, such is not the case. The nack is
issued if the registrant has not gone to "servicezone" (what ever that
may be) and opened a ten day window.]
Step 1: Opening a time slot of
10
calender days for transfers of domains at joker.com
1a. Joker.com will only
accept
transfer-request from other registrars if advised before such request
arrives at joker.com .
[Emphasis added by BobC]
1b. Advising joker.com can
be
done by the owner or admin-c or billing-c of the domain by opening a
time slot for transfer of the domain. Please go to
Servicezone to initiate the opening.
1c. As soon as joker.com
gets the
demand to open the time slot the owner and the admin-c are notified by
email.
1d. If none of them
objects, but
at least one of them agrees explicitly within 5 calendar days, an
additional time slot of 10 calender days is opened
during which joker.com accepts transfer-request from other registrars.
1e. The owner and the
admin-c
will be notified of the result of that first step, i.e. after 5 days.
If. If the time slot was opened, the owner and admin-c will be
informed at the end of the time slot if no transfer-request was
received by joker.com .
1g. If the TLD is .info or
.biz
you need a so called auth-id from joker.com. That auth-id must be
submitted to the registry by the new registrar. If the 10
days time slot is opened you will be able to get the auth-id by using
the status request of transfer at the servicezone.
[The above section does not apply to .com.]
1h. During the whole time
(5+10
days), but only if the domains is not already transferred, the owner
and/or admin-c has the possibility to reject
the transfer.
Step 2: Initiating the
transfer-request at another registrar
2a. In addition and after
getting
the notification from joker.com that the time slot of 10 days is
open, the new registrar has to initiate the transfer-request
at the registry.
2c. Owner and admin-c will be
notified of
the result.
2d. Transfer-request
arriving
outside the time slot will be refused.
[Too arbitrary.]
2e. Transfer-request
arriving
when a domain is expired will be refused. Be aware that the registry
for com - net - org has a process of auto-renew, i.e. the domain is
temporarily prolonged at the cost of joker.com even if it was not paid
by the customer. That domain is considered as expired and will be
deleted if the customer does not pay.
[The above does not apply to these cases, though these delays *could*
cause the registrant to miss its chance to transfer.]
Example:
Day
01 Demanding the opening of the
time slot
from owner/admin-c/billing-c
02 email from joker.com to owner
and
admin-c asking for agreement
03
04
05
06 email from joker.com announcing
the
result of the 1. step, start of time slot
07
08
09
10 possibly email to owner and
admin-c
announcing that transfer is enabled because a transfer-request arrived
at joker.com.
....
16 if no transfer-request arrived
at
joker.com, email to owner and admin-c stating that time slot is now
closed without transfer enabled.
end quote and comments:
I see no relationship between the procedures set forth in Exhibit B
and the process demanded by Joker.com. The are simply making it
extremely difficult for any registrant to transfer its domain to
another ICANN accredited registrar.
The *portability* of domains is denied if Joker.com is the registrar
of record.
My posting on the Registrar Constituency mailing list brought forth
comments from other exasperated registrars who have been stymied by
the Joker.com system.
Remember, we are talking about registrants in Japan where English is
not their primary language. In fact, they may not be sufficiently
capable of handling such complex requirements in English.
Add to it the fact that English is not the mother tongue of whoever
translated the Germany description of the Joker.com rules into
English. I have difficulty being sure I understand what they are
requiring. For example, the first and second ten day "windows" add up
to fifteen days;-(
I have not considered any further implications of Louis' letter. I
think it is adequate to consider Exhibit B.
I suspect that Joker.com will ignore the TF report.
Regards, BobC
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|