<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Joker.com's unique transfer requirements
tim,
i couldn't agree more with you - i think i was trying to say the same thing.
the elements of implementation that are, however, unmanageble are:
1) hazardous (to the registrant) implementation.
2) registrars who do implementations based on local law rather than
icann/registry policy.
in any case, the registrant loses.
/n
> -----Original Message-----
> From: Tim Ruiz [mailto:tim@godaddy.com]
> Sent: 28. februar 2003 13:55
> To: nikolajn@ascio.com
> Cc: rconnell@psi-japan.com; Registrars@dnso.org
> Subject: RE: [registrars] Joker.com's unique transfer requirements
> Importance: Low
>
>
> 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
>>>
|