Danny and all my friends, I for one cannot understand why ICANN has any problem what so ever getting NSOL or any other registry or registrar to comply with the RAA contract agreements which they signed. Either they comply fully and consistantly or they are dis-accredited. Simple as that! Of course this would in NSOL's case require .COM will need to be reassinged... So, perhaps ICANN is not prepaired to do that or NTIA is reluctant to go along with same. If so, than what are the RAA contracts really worth? From a registrant and user point of view, they are proving to be nearly worthless... Either the rule of law, in this case contract law applies, or it doesn't. Which is it? But let me also be very clear, the current RAA contracts our members have never agreed with and still do not. They need serious revisions which have already been discussed and at great length, elaborated upon, see: http://atlarge-lists.icann.org/mailman/private/raa-wg_atlarge-lists.icann.or... Danny Younger wrote:
Re: "Maybe ICANN's management will reconsider the issue of domain name frontrunning."
The issue of NetSol front-running was first raised by Jay Westerdal in his domaintools blog on 8 January -- see http://blog.domaintools.com/2008/01/network-solutions-steals-domain-ideas-co...
Discussion immediately ensued on the General Assembly discussion list, on the registrars list, on all the major DN forums and quickly spread to the tech media.
The ICANN Board reviewed the matter two weeks later at their 23 January board meeting:
Here are the relevant notes from that meeting:
"The Chair asked for further developments on the NSI situation.
Kurt Pritz advised that ICANN wrote to NSI to investigate the practice and determine if the practice is in violation of the RAA. NSI had already amended the practice prior to that writing to bring it into compliance with the RAA. These were essentially nuances to the initial version of the practices in essence, it has the same effect. There may be one more change to the practice to bring it into RAA compliance.
Steve Crocker advised that SSAC had spent a lot of time thinking about this and he made two observations. The AGP is the connective tissue between NSI's goals in the new service and their ability to offer the service, but it is not the right issue. Information supplied by the user when checking name availability disadvantages the user in an unexpected way and when exposed a registrant would not want the registrar to operate in this way. Raising the price on five-day registrations is a pragmatic approach but it does not get to the core value underlying this. We may feel good about the fee but it does not get to the core of what's going on. We should not casually drive by and address a serious underlying issue with the fee. Regarding other ways to eliminate tasting, removing the AGP as a registry contract requirement would not necessarily be effective because a registry might choose to offer some fee discount period for whatever reason that would effectively replicate the AGP. Therefore, although ICANN might remove the AGP as a requirement, it is not assured that this would remove this as an option. If the transaction fee is imposed on add-grace deletes ICANN could subsidize costs resulting from typos or fraud.
Steve continued that the dialogue we're having has been about imposing a fee during the AGP, another option is we simply stop defining AGP: taking away any recognition of it as a separate type of transaction. Everything gets simpler if we remove the AGP as having any special meaning or purpose. The NSI situation is distinct from other uses of the AGP and depends on the AGP for efficiency but that is not the only example of a registrar or entity taking advantage of information supplied by customer. Steve's perspective on AGP is that we should stop subsidizing the practice and the other issues will be resolved.
The Chair asked Steve his opinion of Susan's resolution. Steve Crocker responded that he is sympathetic to adopting the resolution, and also agreed with Bruce Tonkin that it would be very difficult to declare an emergency policy since AGP has been actively practiced for three years. He also pointed out that what NSI is doing is qualitatively different from what others have been doing.
The Chair considered that it might be, that tasters are prepared to pay the transaction fee, and, if that is the case, we may consider a resolution that addresses the issue of front running.
Harald Alvestrand noted that there are two different bad results that have been discussed here: front running or capturing names from registrants, and free registration using AGP. Action taken to fix one of them is a good thing, but we should not forget that both issues should be addressed."
http://www.icann.org/minutes/prelim-report-23jan08.htm
The issue of front-running was further discussed at the Security and Stability Committee Workshop at the ICANN Delhi session with NetSol's Jon Nevett being grilled by the SSAC's Steve Crocker -- details at https://delhi.icann.org/files/Delhi-WS-SSAC-13Feb08.txt
From the above it is clear that ICANN management is well aware of the issues. It should also be clear to most that ICANN's Supporting Organizations and other Advisory Bodies have yet to recommend policy to deal with this particular situation.
To start the ball rolling, I refer the community to an earlier consensus policy that made it possible to review proposed "registry" offerings that might impact the security/stability of the DNS before they were officially launched -- namely, the Registry Services Evaluation Process that was adopted by the ICANN Board on 8 November 2005. Perhaps one way forward would be to recommend a similar "quick look" process to consider new registrar services. This could be tackled by way of a GNSO PDP, and the ALAC could most certainly request that the GNSO consider this option.
Thoughts?
____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://www.alac.icann.org ALAC Independent: http://www.icannalac.org