Chuck, The problem with abandoning the auth_code bit is because EPP is built around that contact/object/auth_code model (which .biz is built around, and .info as well). It would require a re-write of many functions at the registry level, which (if I were in anyone's shoes) I'd definitely NOT want to do.
We do offer assistance for registrants for .info (with some backup from Afilias), which I'm hoping Neulevel is looking into (I'm not dealing with them directly, Rick Baraniuk's the .biz-guy). Still - you can see the text we offer to registrants here: http://rr-n1-tor.opensrs.net/transfers/info_authinfo.html Effectively it's a matter of education, which will take time (as it took time for many registrants to realize there was more of a choice than just network solutions). Charles Daminato TUCOWS Product Manager [EMAIL PROTECTED] On Mon, 21 Jan 2002, Chuck Hatcher wrote: > I appreciate you taking the time to address the concerns of the members of > this list. I'm not aware of any insider/outsider distinctions here. > > I think the auth info concept could theoretically work, but it is currently > broken in a major way. Most registrants did not assign and do not have the > auth info codes for their domain names, and most registrars have no > procedure in place to provide the codes to them (Tucows/OpenSRS is a notable > exception). Expecting a registrant to prove ownership or transfer authority > by producing information they don't have is bound to cause frustration, as > is forcing them to engage in further dealings with a registrar they are > trying to leave. > > The goal should be to make it easy for registrants to do what they want to > do. Unauthorized transfers are repairable. Rather than punish the vast > majority of registrants by making legitimate transfer requests difficult or > impossible, why not abandon the auth info code requirement for the time > being, let the acquiring registrar verify transfer authority (via admin > contact email address as is currently done for com/net/org), and deal with > the few cases of so-called slamming as (or if) they occur? > > Chuck Hatcher > > ----- Original Message ----- > From: "Tindal, Richard" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, January 20, 2002 11:23 PM > Subject: RE: Re[2]: .biz Transfer Policy > > > > > > > > I'm reluctant to jump in here as I've never seen an outsider join the > > OpenSRS List without having his ass handed back to him. This topic is > > important though, so I'll try to clarify the NeuLevel position: > > > > 1. The Current Problem is Not Due to Slamming > > > > NeuLevel understands very well that the overwhelming majority of current > > transfer requests are Registrant approved. As I read-back our open letter > I > > realize I may have implied that slamming is more common. This is not what > I > > meant. The language I used was unfortunate and Elliot has already rapped > my > > knuckles for it. We'll clarify to Registrars. > > > > I'd like to make clear to everyone on this list that NeuLevel has been the > > most supportive of all the Registries regarding the Transfers issue. > We've > > endorsed the majority Registrar (TUCOWS and many others) position on many > > occasions including public support during Registry Constituency and Names > > Council meetings at the last two ICANNs. We've also been in dialogue with > > the Chairperson of the DNSO Transfers Task Force regarding this issue - > > again supporting the majority Registrar position. > > > > 2. Codes of Conduct Don't Work Well When There is Bad Conduct > > > > Having supported this position, we're sufficiently realist to know that > > codes of conduct are only as good as their participants allow them to be. > > We've seen this issue discussed for almost 12 months. A solution has been > > defined but it relies on the good will of all parties for effective > > implementation. Given the tight margins on domains, we think it would be > > quite easy for a losing Registrar to challenge transfers and create a > > burden-of-proof cost that exceeds a gaining Registrar's margin on incoming > > customers. We think "AuthInfo" could be an effective and automated > > technology solution to this problem. No-one makes money on domains > without > > automated processes. It won't solve every transfer, but it should put the > > dispute ratio back where it belongs - a very small percentage of all > > transfer requests. AuthInfo was built into the EPP for a reason. We > > simply haven't educated and institutionalized the technology within the > > industry. It's our fault, we've been busy with lawsuits. > > > > 3. NeuLevel Could Easily Establish a Secure Transfer System Using Admin > > Contact Emails (William's note). > > > > Yes we could (although NSI could not as they don't have this data at the > > Registry level). I think Registrars would rightly have a cow if we did it > > though. All contact data is Registrar/Reseller data, and it can only be > > used by us with their permission. Even with permission this would be > moving > > control of transfers from the Registrars to the Registry. This would be > in > > contravention of the responsibility split between Registries and > Registrars > > and would breach our own business model. We think "AuthInfo" achieves the > > same goal but keeps customer ownership and control where it belongs - with > > Registrars and resellers. > > > > 4. TUCOWS Has Been a Leading Registrar in Getting This Fixed > > > > TUCOWS has been one of, if not the, leading Registrar in trying to get > this > > problem fixed. We'll work with them to derive a solution that works for > you > > and your customers. > > > > > > Richard Tindal > > NeuLevel Inc. > > > > > > > > -----Original Message----- > > From: William X Walsh [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 17, 2002 8:44 PM > > To: Chuck Hatcher > > Cc: [EMAIL PROTECTED] > > Subject: Re[2]: .biz Transfer Policy > > > > > > Thursday, Thursday, January 17, 2002, 12:14:56 PM, Chuck Hatcher wrote: > > > > > Not to excuse the fact that this should have been anticipated and dealt > > with by Neulevel before now, they DO have a point. > > > > > I have been unable to get the auth_code/auth info code/auth info > > token/secret decoder ring for .info domain names I have registered at > Enom, > > NameScout, and Bulkregister. > > > > > It used to bother me a lot, until I discovered that even with the code > > (RegistrationTek provides codes on request), my attempted .info transfers > > time out (Afilias whois says transfer pending, but > > > the OpenSRS order times out after about a week.) > > > > What really stinks about this is that they are using a piss poor > > justification for the entire process. > > > > Nuelevel could EASILY establish a system for secure transfer > > authentication, since, unlike the com/net/org registry, they have the > > email information for the admin contact in their own database, and > > could create their own email authorization system for transfers. > > > > Yet they use Verisign's fictional "rampant domain slamming" argument > > to extend the no transfer period. > > > > I sometimes wonder how much common sense some of these companies have. > > > > -- > > Best regards, > > William X Walsh <[EMAIL PROTECTED]> > > -- > > > > "There is no better way to exercise the imagination than the study of > > the law. No artist ever interpreted nature as freely as a lawyer > > interprets the truth." > > -- Jean Giradoux > > > > At 1/17/02 5:43 PM, William X Walsh wrote: > > > > >Nuelevel could EASILY establish a system for secure transfer > > >authentication, since, unlike the com/net/org registry, they have the > > >email information for the admin contact in their own database, and > > >could create their own email authorization system for transfers. > > > > Agreed. In fact, there's no reason Verisign registry couldn't do the same > > thing; it's a trivial requirement to have the registrar provide the > > current e-mail address, either each time it's updated or on demand. > > > > The whole problem is a non-issue if someone would just address it; it's a > > trivial problem to solve. This nonsense with approval keys is just > > foolish. > > > > > > >Yet they use Verisign's fictional "rampant domain slamming" argument > > >to extend the no transfer period. > > > > Yes; Rick, whatever else you do, I'd disabuse them of that notion really > > quickly. That whole idea is complete BS, but they're treating it as if > > it's a given. > > > > -- > > Robert L Mathews, Tiger Technologies > >
