ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [registrars] DRAFT Standard form for use by losing registrar s after a transfer is initiated

  • To: "'Tim Ruiz'" <tim@xxxxxxxxxxx>, Bruce.Tonkin@xxxxxxxxxxxxxxxxxx
  • Subject: RE: [registrars] DRAFT Standard form for use by losing registrar s after a transfer is initiated
  • From: Paul Stahura <stahura@xxxxxxxx>
  • Date: Thu, 4 Sep 2003 22:11:07 -0700
  • Cc: registrars@xxxxxxxx, erlich@xxxxxxxxxxxxxxxxxx
  • Sender: owner-registrars@xxxxxxxxxxxxxx

Tim, if registrars allow registrants to put their names on lock, the process
as it stands can start at the current registrar
by the registrant going to the current registrar, the current registrar
validating their identity and remobing the lock.
 
Once all registries are switched to EPP then obviously it will always start
at the current registrar.
 
 
Paul
 
-----Original Message-----
From: Tim Ruiz [mailto:tim@xxxxxxxxxxx] 
Sent: Thursday, September 04, 2003 4:36 AM
To: Bruce.Tonkin@xxxxxxxxxxxxxxxxxx
Cc: registrars@xxxxxxxx; erlich@xxxxxxxxxxxxxxxxxx
Subject: RE: [registrars] DRAFT Standard form for use by losing registrars
after a transfer is initiated


>By far the most preferable approach is for industry to agree on best
>practice approaches.  It is only when there is market failure (partly
>due to the design of the registry transfer business processes that allow
>a losing registrar to deny a customers right to transfer) that
>regulation should be required.   I believe that the registrars
>constituency did attempt to resolve the issue internally but that
>failed, and domain name users have demanded a change (just look at the
>complaints received by ICANN and registrars on this issue).
 
Not allowing the losing registrar to deny would only create a new problem.
Currently, there is no way for the gaining registrar to be certain they have
received valid approval. It is only valid from a process point of view.
Given the international nature of this industry, the real solution is to
have the process start with the registrant's current registrar.

Tim
 



-------- Original Message --------
Subject: RE: [registrars] DRAFT Standard form  for use by losing
registrars after a transfer is initiated
From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
Date: Wed, September 03, 2003 8:09 pm
To: "Larry Erlich" <erlich@xxxxxxxxxxxxxxxxxx>
Cc: registrars@xxxxxxxx

Hello Larry,

> 
> If "must include" then gaming can still be done
> simply by adding other language to the message
> that includes the information specified.

The intent is that additional (often misleading) information cannot be
included in the standardised message.  Registrars are free to send
separate messages that contain any material they want, assuming they are
compliant with local trade practices laws.

> 
> It would probably be a good idea to 
> add some text stating what! it means
> to "change registrar" exactly and what
> the function of a registrar is. Customers often
> don't know what role
> the registrar plays.  

Please suggest some succinct wording.

> I have seen multiple
> cases of customers who are convinced by their
> web hosting company that they need to switch
> registrar in order to get hosting. 

Yes - I have come across this problem too.

A separate issue is probably producing a consumer guide to purchasing
domain names.
I am planning to have a go at producing one for use in Australia (on a
voluntary basis), with input from other registrars.

By far the most preferable approach is for industry to agree on best
practice approaches.  It is only when there is market failure (partly
due to the design of the registry transfer business processes that allow
a losing registrar to deny a customers right to transfer) that
regulation! should be required.   I believe that the registrars
constituency did attempt to resolve the issue internally but that
failed, and domain name users have demanded a change (just look at the
complaints received by ICANN and registrars on this issue).

Regards,
Bruce 



<<< Chronological Index >>>    <<< Thread Index >>>