ICANN/GNSO GNSO Email List Archives

[registrars]


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

Re: [registrars] FW: Transfer Undo Mechanism - 10-11 a.m. EST ON TUESDAY JUNE 29

  • To: Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Subject: Re: [registrars] FW: Transfer Undo Mechanism - 10-11 a.m. EST ON TUESDAY JUNE 29
  • From: Thomas Keller <tom@xxxxxxxxxx>
  • Date: Fri, 25 Jun 2004 10:26:25 +0200
  • Cc: registrars@xxxxxxxx, cgomes@xxxxxxxxxxxx, dam@xxxxxxxxx
  • In-reply-to: <AFEF39657AEEC34193C494DBD7179222020EF5AB@phoenix.mit>
  • Mail-followup-to: Thomas Keller <tom@xxxxxxxxxx>, Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>, registrars@xxxxxxxx, cgomes@xxxxxxxxxxxx, dam@xxxxxxxxx
  • Organization: Schlund + Partner AG
  • References: <AFEF39657AEEC34193C494DBD7179222020EF5AB@phoenix.mit>
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • User-agent: Mutt/1.5.5.1i

Hello,

since I will definitely not be able to join the call next week I take my
shot now.

I agree with Bruce that the proposed undo policy is a good first step 
and that this issue should not delay the overall implementatin of the
new transfer policy. I nevertheless have to disagree regarding the 
over-engineering part. Even thought that this situation is unlikely
to occur (and this needs to be proofen in the future) the technical 
implementation should be as clean and customer friendly as possible.
After all would you burden your customer with such an process I really
doubt it. Don't you think that we can expect the same amount of service
from our suppliers as our customers expect from us?

Best,

tom

Am 25.06.2004 schrieb Bruce Tonkin:
> Hello Elana,
> 
> In case I can't make the call.
> 
> Just a note that I support the current implementation by the registries
> as a good first stage.
> 
> The new transfers policy is a vast improvement on what we have now.
> 
> Currently there is no mechanism of redress when a registrar behaves
> inappropriately.
> 
> Under the new policy we have:
> (1) a clearly defined process that is enforceable
> (2) a dispute resolution mechanism
> (3) a mechanism to restore the domain to the rightful registrar in the
> case of an unauthorised transfer
> (4) a process for regular review of the implementation of the policy
> 
> I expect that as (1) becomes effective that (3) will hardly ever by
> needed.   It is not economic to over-engineer an exception process (3)
> that if the system is working should never happen.   
> 
> I welcome the day when steps (2) and (3) can be used to correct
> in-appropriate behaviour.  I welcome even more ICANN taking enforcement
> action against those registrars that are found in breach of the
> registrar agreement ie (1).   
> 
> The cost of dealing with the current system (in terms of the constant
> stream of registrant and reseller complaints) far outweighs any costs
> associated with a less than perfect (3), given that we will at least
> have (1) and (2).
> 
> 
> Regards,
> Bruce Tonkin
> 
>  
> 
> > -----Original Message-----
> > From: Elana Broitman [mailto:ebroitman@xxxxxxxxxxxx] 
> > Sent: Friday, 25 June 2004 12:25 AM
> > To: registrars@xxxxxxxx
> > Cc: cgomes@xxxxxxxxxxxx; dam@xxxxxxxxx
> > Subject: FW: [registrars] FW: Transfer Undo Mechanism - 10-11 
> > a.m. EST ON TUESDAY JUNE 29
> > Importance: High
> > 
> > Dear all- as you will recall, on June 9th, I had sent a note 
> > about the registries' proposed undo mechanism.  Below is my 
> > note, which outlined some of the concerns with the proposal.  
> > The registries state that this is the a reasonable proposal 
> > to enable them to launch an undo mechanism in the near term, 
> > so that further work on it does not stall a transfer policy 
> > change.  They have requested our comments prior sending their 
> > final proposal to ICANN.
> > 
> > A number of you have raised concerns.  The upcoming call is 
> > with registry representatives to the Transfer Advisory Group. 
> >  ICANN is also invited.  The call is an opportunity to 
> > directly ask the registries about this mechanism, express any 
> > concerns or suggestions, and/or signify agreement.
> > 
> > Given the length of time already spent on this issue, the 
> > registries would like to move this proposal (with any 
> > potential amendments that may come out of this call) forward 
> > to ICANN without any further vote or additional process after 
> > this call.  
> > 
> > So, it is important for you to please join the call. 
> > 
> > I apologize in advance to anyone for whom the time is 
> > inconvenient, but our last constituency call was in the 
> > evening in order to accommodate Asia, so this one is meant to 
> > be more friendly to Europe and W. U.S.  If you cannot be on 
> > the call, but have comments, please send them ahead of time 
> > and we will raise them for you.
> > 
> > Thank you.
> > 
> > Elana Broitman
> > 
> > P.S.  Bob - should we start with 30 lines?
> > 
> > -----Original Message-----
> > From: owner-registrars@xxxxxxxxxxxxxx
> > [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Elana Broitman
> > Sent: Wednesday, June 09, 2004 6:57 PM
> > To: registrars@xxxxxxxx
> > Subject: [registrars] FW: Transfer Undo Mechanism
> > Importance: High
> > 
> > 
> > Dear all - one of the last remaining issues before ICANN can 
> > publish the changed transfers policy is how the registries 
> > will address the transfer undo mechanism.  Attached is their 
> > proposal.  Let's see if we can discuss it by email, and if 
> > need be, we can also hold a conference call.
> > 
> > As you will see, the registries have indicated that this is 
> > the least costly alternative for them to implement. It should 
> > be noted, however, that the proposed implementation of the 
> > "undo" transfer command may cause the following problems for 
> > registrars:
> >  
> > 1.  An undo transfer command that does not restore the domain 
> > record to its 'original state' will place the registrar that 
> > re-gains the name (Registrar A) in the position of having to 
> > support a registration for one or multiple years (depending 
> > on the number of years activated per
> > transfer) without realizing revenue from the registrant.  
> > There may be added costs associated with maintaining the 
> > additional year(s) for such registrar - customer service, 
> > technology, etc.
> > 
> > 2. This may also result in anniversary dates among domain 
> > names and related products that do not match.  For example, 
> > email or hosting products that must be renewed prior to 
> > domain expiration, causing concerns and customer confusion.  
> > This may lead to unnecessary, customer unfriendly and costly 
> > "clean up" issues.
> >  
> > 3. In effect, the innocent registrant may be prejudiced by 
> > the bad acts of the wrongful registrar.  Yet, the "bad" actor 
> > does not bear the costs of restitution.
> > 
> > 4. The registrant is forced to take on additional years even 
> > if he/she is not interested in doing so.  The registrant will 
> > have paid a fee for the transfer to the gaining 
> > (unauthorized) registrar and perhaps unwittingly paid for 
> > additional years.
> > 
> > 5. The registry is paid $6 for an unauthorized and unwanted transfer.
> > 
> > 6. Maintaining additional years when the registrant does not 
> > want them would have the effect of artificially keeping a 
> > domain name out of the pool for other prospective registrants.
> > 
> > Your comments would be appreciated.  Elana 
> > 
> > -----Original Message-----
> > From: Gomes, Chuck [mailto:cgomes@xxxxxxxxxxxx]
> > Sent: Thursday, June 03, 2004 12:53 PM
> > To: Elana Broitman
> > Cc: gTLD RC Planning Committee (GTLD-PLANNING@xxxxxxxxxxxx); 
> > 'dam@xxxxxxxxx'
> > Subject: Transfer Undo Mechanism
> > Importance: High
> > 
> > 
> > Elana,
> > 
> > The gTLD Registry Constituency unanimously supports the attached
> > approach to providing a transfer undo mechanism in support of the new
> > transfer policy. I would like your advice with regard to how 
> > it might be
> > best to discuss this with registrars.  Some of us in the gTLD Registry
> > Constituency had some telephone conversations with a few 
> > registrars with
> > somewhat mixed results. A main issue of controversy among those we
> > talked to was whether or not there should be a means of compensating a
> > registrar for lost revenue opportunity.  Because that is 
> > really an issue
> > between registrars, it seemed best to suggest that registrars 
> > work that
> > out among themselves as suggested in the proposed approach. To try to
> > resolve that before moving forward with implementation of the new
> > transfer policy would add significant additional delays that seem very
> > undesirable.
> > 
> > Chuck Gomes
> > VeriSign Com Net Registry
> > 
> > 
> > 
> > 
> 
> 

Gruss,

tom

(__)        
(OO)_____  
(oo)    /|\	A cow is not entirely full of
  | |--/ | *    milk some of it is hamburger!
  w w w  w  



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