<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Joker.com's unique transfer requirements
It is also worth noting that despite numerous (at least six) requests to
cite the specific German legislation that this position related to we have
had no response. We have no idea if this claim is even the case and these
requests go back well over a year.
Elliot Noss
Tucows inc.
416-538-5494
> -----Original Message-----
> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Larry Erlich
> Sent: Friday, February 28, 2003 11:57 AM
> To: Nikolaj Nyholm
> Cc: Registrars@dnso.org
> Subject: 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
>>>
|