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

["Siegfried Langenbach" <svl@xxxxxxx>]

joker.com supports GMO

Respectfully
Siegfried Langenbach 
 
Computer Service Langenbach GmbH (CSL GmbH)
GERMANY
 


On 25 Jun 2004 at 11:36, Jean-Michel Becar wrote:

Date sent:      	Fri, 25 Jun 2004 11:36:21 +0900
From:           	Jean-Michel Becar <jmbecar@xxxxxx>
Organization:   	Global Media Online INC. Tokyo - Japan
To:             	registrars@xxxxxxxx
Subject:        	Re: [registrars] FW: Transfer Undo Mechanism - 10-11 a.m. EST ON
	TUESDAY JUNE 29

> Dear all,
> 
> As GMO definitly supports the new transfer pocily we do not support the 
> undo transfer mechanism as it is now.
> In order to go ahead I would agree to go ahead with it if we have the 
> insurance the undo mechanism would be improved in a short time after the 
> implementation.
> I still don't understand why it's so difficult for the registries to 
> remember the original dates of the domain and to put it back in the 
> previous state.
> This undo mechanism will let each registrar to implement it's own 
> rollback system which I see it as a real registry service instead.
> Regards,
> Jean-Michel
> 
> 
> 
> 
> Bruce Tonkin wrote:
> 
> >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
> >>
> >>
> >>
> >>
> >>    
> >>
>