<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] Joker.com's unique transfer requirements
Nikolaj Nyholm wrote:
>
> 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.
The joker.com situation is a real problem.
It would be easy to get a local government
here (or in other places) to pass a law to the
benefit a particular registrar's business practices.
Larry Erlich
>
> 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
>>>
|