ICANN 博文

敬请阅读 ICANN 的博文,了解最新政策制定活动和区域事务等等。

RegisterFly update: March 10, 2007

2007 年 03 月 10 日
作者: Paul Levins

本内容仅提供以下语言版本

  • English

ICANN spoke yesterday with Kevin Medina and Mark Klein of RegisterFly.

ICANN asked for greater clarity from RegisterFly about auth-info codes and draw attention to this link to the registerfly.com auth-info codes retrieval process.

RegisterFly indicated that auth-info codes are being distributed to customers via RegsiterFly.com and customer service channels and they claimed that the site is functioning as it should to allow names to be unlocked. ICANN told RegisterFly it will run a test so we can verify that these systems are indeed functioning as advised.

RegisterFly said they would have a developer research and correct the problem registrars and other users are experiencing with port 43 and web-based Whois services. Presently, the RegisterFly Whois server provides no registrant, administrative contact, technical contact, or other registrar-level Whois data, but instead reports only registry-level data. ICANN has told RegisterFly to correct this problem and report back. The failure by RegisterFly to provide Whois service effectively prohibits all registrants of .com and .net names from transferring out, so this needs to be RegisterFly’s highest priority in order to protect the interests of registrants. This must be corrected immediately.

Regarding names registered as a reseller for eNom, RegisterFly confirmed that an exchange of information will take place this Monday, 12 March that will result in access to eNom systems, and enable “automatic” transfer of eNom names.

ICANN insisted upon daily reports indicating the number of transfers. We intend to publish these.

Finally ICANN said it would be referring and monitoring the performance of RegisterFly on handling complaints referred to it and to ICANN about RegisterFly.

It was made clear that it is absolutely imperative that the causes of complaints regarding transfers and auth-codes have to cease immediately. If they do not they will be the subject of further breach notices.

Authors

Paul Levins