ICANN/GNSO GNSO Email List Archives

[registrars]


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

RE: [registrars] unsanctioned whois concepts (long)

  • To: "'elliot noss'" <enoss@xxxxxxxxxx>
  • Subject: RE: [registrars] unsanctioned whois concepts (long)
  • From: "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Date: Tue, 4 Nov 2003 14:21:02 -0600
  • Cc: "'Bruce Tonkin'" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>, <registrars@xxxxxxxx>
  • Importance: Normal
  • In-reply-to: <3FA7F23C.5090801@tucows.com>
  • Sender: owner-registrars@xxxxxxxxxxxxxx

Elliot,

I'm surprised it has taken this long for that argument to surface in this
discussion. But I'm not trying to avoid it, I just think that overall it's a
moot issue. There are incentives for the gaining registrar to also NOT act
diligently, as we've seen with some recent renewal scams, and as other
industries have experienced. Bottom line is enforcement one way or the
other.

Tim


-----Original Message-----
From: elliot noss [mailto:enoss@xxxxxxxxxx] 
Sent: Tuesday, November 04, 2003 12:39 PM
To: Tim Ruiz
Cc: 'Bruce Tonkin'; registrars@xxxxxxxx
Subject: Re: [registrars] unsanctioned whois concepts (long)

Tim:

This discussion avoids what is (for me) the biggest problem with losing 
registrar having primary responsibility. That is that the gaining 
registrar is the one with the incentive to act diligently and 
responsibly with respect to the end user while the losing registrar is 
actually incented not to.

We have, for years now, seen exactly this behaviour manifest itself in 
our industry for, IMHO, exactly these reasons. All other industries that 
deal with this issue (cellco, LNP, etc.) put the burden on the gaining 
registrar because of this.

Regards

Tim Ruiz wrote:

> Bruce,
> 
> 
>>Not sure about that.  I think in most cases the gaining registrar
> 
> would
> 
>>be well advised to get confirmation of authorisation to transfer.  The
>>"key" is only a mechanism of authentication rather than authorisation.
> 
> 
> The key is not an auth code. It is only provided after the losing
> registrar has confirmed with the registrant. The gaining registrar does
> not need to confirm because a valid key (matches the registry) is
> evidence of the confirmation. So in this case it IS authorization.
> 
> 
>>The gaining registrar must still obtain acceptance of the new terms
> 
> and
> 
>>conditions of the new registration agreement.
> 
> 
> Agreed.
> 
> 
>>If the losing registrar chooses to trust the gaining registrar and
>>enforcement is available againstbad gaining registrars, the losing
>>registrar could explicitly confirm all transfers.
>>
>>Thus not sure that your proposed process in the ideal case is better
>>than the new transfers policy in the ideal case.  In the worst cases
>>they are also probably equivalent.
> 
> 
> That's a pretty big IF Bruce. Losing registrars are never going to
> completely trust gaining registrars, they're competitors. And in some
> cases local law may not even allow them to. 
> 
> When there's an unauthorized transfer the damage is done long before it
> gets back to where it belongs. I'm still convinced that the losing
> registrar is in the best position to accurately confirm, reducing
> disputes and reversals.
> 
> With the current process you have difficult enforcement and dispute
> resolution issues on both ends of the process. With the key system it is
> focused on the losing registrar.
> 
> 
>>You need to look at the transfer process from the time the registrant
>>desires to transfer until the transfer is complete.  I would assume
> 
> that
> 
>>some losing registrars may not provide a key on a timely basis (after
>>first trying to convince the customer to stay).
> 
> 
> I was considering that, and it will still be faster in the majority of
> the cases. Right now querying registrars' whois, parsing out the admin
> contact, dealing with parse errors, rotating formats, out of date data,
> etc. is not an efficient process. Just getting to the point of being
> able to actually submit the transfer request takes days and often even
> weeks.
> 
> After the request is submitted there is most often another 5 days before
> the transfer is completed, that's if it isn't denied by the losing
> registrar and it starts all over again.
> 
> These are process flaws that are not easily solvable in the near future.
> The problem with a losing registrar being slow to respond to a key
> request is an enforcement issue that is at least as addressable as the
> gaining registrar getting proper confirmation.
> 
> 
>>I am not aware of too
>>many other cases where a customer must seek some sort of permission
> 
> (e.g
> 
>>transfer code) to move to a competitor.
> 
> 
> Interesting spin, but what we're really talking about is the safe and
> secure transfer of a service that is often associated with an entity's
> livelihood.
> 
> As far as whether thick registries are better than thin, I'll leave that
> for another discussion, transfers are just the tip of that iceberg. But
> it looks like we'll have thin COM/NET for some time to come.
> 
> Tim
> 
> 
> -----Original Message-----
> From: owner-registrars@xxxxxxxxxxxxxx
> [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Bruce Tonkin
> Sent: Sunday, November 02, 2003 9:18 AM
> To: registrars@xxxxxxxx
> Subject: RE: [registrars] unsanctioned whois concepts (long)
> 
> Hello Tim,
> 
> 
>>If you were referring to the transfer key system I was 
>>proselytizing about, I see some of the benefits as follows:
>>
>>Eliminates the attempt to double confirm and reduces confusion.
> 
> 
> Not sure about that.  I think in most cases the gaining registrar would
> be well advised to get confirmation of authorisation to transfer.  The
> "key" is only a mechanism of authentication rather than authorisation.
> The gaining registrar must still obtain acceptance of the new terms and
> conditions of the new registration agreement.
> 
> 
>>More reliable and quicker confirmation resulting in fewer 
>>disputes. The losing registrar is in the best position to confirm.
> 
> 
> If the losing registrar chooses to trust the gaining registrar and
> enforcement is available againstbad gaining registrars, the losing
> registrar could explicitly confirm all transfers.
> 
> Thus not sure that your proposed process in the ideal case is better
> than the new transfers policy in the ideal case.  In the worst cases
> they are also probably equivalent.
> 
> 
>>Faster, almost immediate completion of the transfer.
> 
> 
> You need to look at the transfer process from the time the registrant
> desires to transfer until the transfer is complete.  I would assume that
> some losing registrars may not provide a key on a timely basis (after
> first trying to convince the customer to stay).  I am not aware of too
> many other cases where a customer must seek some sort of permission (e.g
> transfer code) to move to a competitor.
> 
> 
>>Whois data accuracy improved as it can be collected directly 
>>from the registrant by the gaining registrar. The key 
>>confirms the validity of the transfer so why force the import 
>>of potentially outdated or poorly parsed data?
> 
> 
> The problem of the WHOIS data in different formats in a significant one.
> I prefer the thick registry model for this reason (although this does
> not mean that the data should be made available to the public as is
> presently the case).
> 
> I prefer centralised WHOIS for the formatting etc reasons - but also
> prefer that the data only be made available under specific circumstances
> - preferably under the control of the registrant.
> 
> 
>>A dynamically generated, one use key is more secure than a 
>>static auth code for transfers.
> 
> 
> True.  Although this code could be generated automatically by a registry
> and sent only to the contact stored in the registry.  This would remove
> gaming from the losing registrar.
> 
> 
> Regards,
> Bruce
> 
> 
> 


-- 
Elliot Noss
Tucows Inc.
416-538-5494
enoss.blogware.com






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