ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

RE: [ga] RE: WLS Input


Jeff,

Of course I'm in agreement that there is a significant security gap.  That's
why we introduced SnapBack 13 months ago as a safety countermeasure for
those who are concerned about such security risks.  While it's not my area
of expertise (we have other people here who are much more knowledgable than
I on the RRP/EPP/SRS et al) I'm pretty sure this issue is entirely outside
of the scope of the WLS.  

Thanks,
Ron

> -----Original Message-----
> From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] 
> Sent: Wednesday, January 16, 2002 6:45 PM
> To: Ron Wiener
> Cc: 'k@widgital.com'; Cameron Powell; ga@dnso.org
> Subject: Re: [ga] RE: WLS Input
> 
> 
> Ron and all assembly members,
> 
>   Ron, I think that one of the things or central area of 
> concern here that you are missing is that the problem is 
> really deeper than you seem to be articulating.  The RRP, SRS 
> and Whois DB's are not secure or secure enough to thwart 
> simple circumvention in the case of the RRP.  Hence, the 
> delete problem has legs for hackers (And not ever really 
> slick ones) to circumvent or otherwise compound the delete 
> issue, not to mention make record changes as to ownership of 
> Domain names in the RRP DB.  Same is true for SRS, but to a 
> lesser degree, and Whois as well.  GIve me a monkey and 
> enough bananas and I can do just about anything I want with 
> RRP data if a very short period of time.  Hence a more 
> complete solution for the delete problem is needed.
> 
> Ron Wiener wrote:
> 
> > K, good question.
> >
> > There appears to be some confusion between SnapBack - which is a 
> > monitoring AND waiting list service, and the proposed WLS - 
> which has 
> > no monitoring component.  We have many IP clients including 
> most major 
> > IP law firms, government agencies and many major corporations who 
> > employ SnapBack primarily for its monitoring capability and only 
> > secondarily as a double safety net in case their name accidentally 
> > deletes due to clerical error or registry/registrar error.  When we 
> > conduct CLE classes (continuing legal education courses, 
> for credits) 
> > we always educate attorneys that the best strategy is to 
> register for 
> > long periods of time.  Besides being far more economical, it's far 
> > more sensible.  Some companies, however, have so much at stake in a 
> > single domain name that they want the extra insurance of a 
> SnapBack.  
> > One reason is that it provides "early warning" of tampering 
> with the 
> > domain record, e.g. when a webmaster changes the admin 
> contact to his 
> > yahoo account before leaving the company.  Another reason 
> is that very 
> > often the billing and admin contacts will have left the 
> company in 5 
> > or 10 years when the registration renewal comes up again, 
> and they do 
> > not want to take the risk.  The protection against an 
> illegal transfer 
> > (cyber-jacking) or employee sabotage is far more important than 
> > accidental cancellation protection, when common sense is practiced 
> > (i.e. important names are registered for 5 to 10 years).
> >
> > Frankly, K, protective use of SnapBack represents low 
> single digits of 
> > the sales of the product.  We have some resellers, e.g. NameEngine, 
> > that provide domain name management services to very large 
> > corporations, and they have some protection products in which they 
> > bundle SnapBack.  There have been some very high-profile names that 
> > we've recovered for corporate clients using SnapBack, like 
> > entertainmenttonight.com and americanexpress.net, as a couple of 
> > examples that come to mind.
> >
> > As for what we will do in the future to help trademark holders: We 
> > will continue to offer some form of free monitoring service 
> as we do 
> > today with our SnapShot product, but we plan on introducing 
> a low-cost 
> > security monitoring product separate from SnapBack which 
> will provide 
> > the same security features, plus some new enhancements over the 
> > current SnapBack product, but without the waiting list 
> function.  This 
> > will be a product that all registrars will be able to offer 
> to their 
> > customers.  It should be ready by Q2.
> >
> > Hope that's helpful.  If you have any further questions 
> about how we 
> > can assist trademark holders please feel free to contact 
> our Customer 
> > Support department, and ask for one of the legal 
> professionals on the 
> > staff.
> >
> > Cheers,
> > Ron
> >
> > > -----Original Message-----
> > > From: k@widgital.com [mailto:k@widgital.com]
> > > Sent: Wednesday, January 16, 2002 7:29 AM
> > > To: Ron Wiener
> > > Cc: cameronp@snapnames.com; ga@dnso.org
> > > Subject: RE: WLS Input
> > >
> > >
> > > ><snip>  And many of these customers are trademark owners 
> > > >re-acquiring names in which they consider themselves to have 
> > > >intellectual property rights.  See 
> > > >http://www.snapnames.com/corporate_clients.html.
> > > >
> > > >(All contents of SnapNames' website are protected from direct 
> > > >copying by applicable copyright laws.)
> > > >
> > - snip -
> >
> > >
> > >
> > > What will you do to support the Trademark owners who already have 
> > > the domains that match their trademarks and do not wish to 
> > > discontinue use of them at any time?  None of your literature 
> > > permits these folks to opt-out of your automated re-registration 
> > > program.
> > >
> > > :)
> > >
> > > ~k
> >
> 
> Regards,
> --
> Jeffrey A. Williams
> Spokesman for INEGroup - (Over 121k members/stakeholdes 
> strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA 
> Development Eng. Information Network Eng. Group. INEG. INC. 
> E-Mail jwkckid1@ix.netcom.com Contact Number:  972-244-3801 
> or 214-244-4827
> Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
> 
> 
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



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