ICANN/GNSO GNSO Email List Archives

[registrars]


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

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

  • To: Bruce.Tonkin@xxxxxxxxxxxxxxxxxx
  • Subject: RE: [registrars] DRAFT Standard form for use by losing registrars after a transfer is initiated
  • From: Tim Ruiz <tim@xxxxxxxxxxx>
  • Date: Thu, 4 Sep 2003 04:35:55 -0700
  • Cc: registrars@xxxxxxxx, erlich@xxxxxxxxxxxxxxxxxx
  • Reply-to: Tim Ruiz <tim@xxxxxxxxxxx>
  • Sender: owner-registrars@xxxxxxxxxxxxxx

&gt;By far the most preferable approach is for industry to agree on best<BR>&gt;practice approaches. &nbsp;It is only when there is market failure (partly<BR>&gt;due to the design of the registry transfer business processes that allow<BR>&gt;a losing registrar to deny a customers right to transfer) that<BR>&gt;regulation should be required. &nbsp; I believe that the registrars<BR>&gt;constituency did attempt to resolve the issue internally but that<BR>&gt;failed, and domain name users have demanded a change (just look at the<BR>&gt;complaints received by ICANN and registrars on this issue).<br>
&nbsp;<br>
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&nbsp;is only&nbsp;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&nbsp;registrant's current&nbsp;registrar.<BR><br>
Tim<br>
&nbsp;<br>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid"><BR>-------- Original Message --------<BR>Subject: RE: [registrars] DRAFT Standard form &nbsp;for use by losing<BR>registrars after a transfer is initiated<BR>From: "Bruce Tonkin" &lt;Bruce.Tonkin@xxxxxxxxxxxxxxxxxx&gt;<BR>Date: Wed, September 03, 2003 8:09 pm<BR>To: "Larry Erlich" &lt;erlich@xxxxxxxxxxxxxxxxxx&gt;<BR>Cc: registrars@xxxxxxxx<BR><BR>Hello Larry,<BR><BR>&gt; <BR>&gt; If "must include" then gaming can still be done<BR>&gt; simply by adding other language to the message<BR>&gt; that includes the information specified.<BR><BR>The intent is that additional (often misleading) information cannot be<BR>included in the standardised message. &nbsp;Registrars are free to send<BR>separate messages that contain any material they want, assuming they are<BR>compliant with local trade practices laws.<BR><BR>&gt; <BR>&gt; It would probably be a good idea to <BR>&gt; add some text stating what!
 it means<BR>&gt; to "change registrar" exactly and what<BR>&gt; the function of a registrar is. Customers often<BR>&gt; don't know what role<BR>&gt; the registrar plays. &nbsp;<BR><BR>Please suggest some succinct wording.<BR><BR>&gt; I have seen multiple<BR>&gt; cases of customers who are convinced by their<BR>&gt; web hosting company that they need to switch<BR>&gt; registrar in order to get hosting. <BR><BR>Yes - I have come across this problem too.<BR><BR>A separate issue is probably producing a consumer guide to purchasing<BR>domain names.<BR>I am planning to have a go at producing one for use in Australia (on a<BR>voluntary basis), with input from other registrars.<BR><BR>By far the most preferable approach is for industry to agree on best<BR>practice approaches. &nbsp;It is only when there is market failure (partly<BR>due to the design of the registry transfer business processes that allow<BR>a losing registrar to deny a customers right to transfer) that<BR>regulation!
 should be required. &nbsp; I believe that the registrars<BR>constituency did attempt to resolve the issue internally but that<BR>failed, and domain name users have demanded a change (just look at the<BR>complaints received by ICANN and registrars on this issue).<BR><BR>Regards,<BR>Bruce </BLOCKQUOTE>



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