Here are the answers to the questions we’ve received so far:

Q. How is ICANN billing the 22 cent fee? Are refunds being issued?

A. ICANN didn’t invoice registrars until the fee schedule was approved by the registrars so the invoices registrars received reflect a per-transaction fee of 22 cents. Thus, we will not be issuing any refunds.

Q. What are the effective dates of the fee reduction?

A. All per-transaction fees billed during the current fiscal year (1 July 06 through 31 June 07) have been (or will be) billed at 22 cents.

Q. What should registrars do if they charged their customers a 25 cent “ICANN fee”?

A. Consult with your legal counsel. (Sorry, no free legal advice here.) Depending on the terms of your registration and reseller agreements, local law, etc., your registrar may or may not be obligated to act.

Q. When and how did this happen? The “adopted” budget says the fee is 25 cents.

A. After the budget (with a 25 cent transaction fee) was approved by ICANN’s Board of Directors, but before the fee schedule was approved by the registrars, the fee was reset to 22 cents and re-approved. We sent notice of the fee reduction to registrars’ primary contacts on 14 March 2007.

Attached file(s):

Revised data escrow specs (v0.3)

In the public forum, Elliot Noss of Tucows made the point that resellers serve an important function in that they are typically hosting companies and ISPs, and as such, they tend to have established relationships with the registrants of domain names they resell. Resellers can focus their efforts on creating value-added tools that allow less-sophisticated consumers and small businesses to easily set up a website or an email address, without the overhead of running a registrar at the same time (which obviously requires a significant volume of registration business to justify the expense).

No one disputes that resellers bring value to the marketplace. So when I ask “what’s wrong with resellers?” it should not be interpreted as “there’s nothing right about resellers.”

But I see genuine problems every day with resellers, and by problems with resellers, I suppose I really mean, problems with registrars who use resellers, since the registrar is ultimately responsible for the registrations it places on the registry.

So here’s a short list of common problems I frequently see with (registrars who use) resellers:

1. Because resellers often have relatively close relationships with their customers, their business operations sometimes suffer from what I’d call “trust me syndrome” (TMS).
   TMS can manifest itself in the form of inadequate or nonexistent registration agreements, use of whois privacy services without disclosure to the customer (or without disclosure of the implications of using a privacy service), and internal transfer-out policies that are inconsistent with the Inter-Registrar Transfer Policy.
2. Sometimes small resellers (e.g. where the customer service rep is also the president, CEO, treasurer, bookkeeper, janitor, etc.) take the business a little too personally.
   In the past, this has caused customers difficulty when they try to terminate the services of the reseller. We’ve seen situations where this allegedly caused transfers to be NACK’d without explanation and whois data to be altered without the customer’s consent. (While this is also a potential risk with registrars, it is less likely when the registrar actually values its continued accreditation. A small-time reseller can easily find a new host-registrar for whom it may resell names, so it may not place as much importance on the agreement it holds with its current host-registrar.)
3. While every registrar’s reseller model is different, there are some models that delegate substantial responsibility to resellers, but not all resellers take their responsbilities as seriously as they should.
   By way of example, we saw an enormous uptick in complaints about resellers following VeriSign’s migration to EPP in late 2006. In particular, customers complained that resellers wouldn’t or couldn’t provide auth-info codes for .com/.net names and that requests to the sponoring registrar were met with deflection of the matter to the unresponsive reseller. In some cases, even ICANN’s attempts at intervention were similarly deflected.

These broad points represent the majority of the reseller-related issues that we see. I welcome your thoughts about my thoughts and your suggestions for addressing the underlying problems. I’ll share my ideas next week.

The RAA at paragraph 3.4.1 describes a database containing, for each registered name under a registrar’s sponsorship:

• The name of the Registered Name;
• The names of the primary nameserver and secondary nameserver(s) for the Registered Name;
• The identity of Registrar (which may be provided through Registrar’s website);
• The original creation date of the registration;
• The expiration date of the registration;
• The name and postal address of the Registered Name Holder;
• The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and
• The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name;
• The name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact; and
• Any other Registry Data that Registrar has submitted to the Registry Operator or placed in the Registry Database under Subsection 3.2 of the RAA.

The attached document reflects an initial attempt to specify the schedule, terms, and format registrars must use to escrow data pursuant to RAA paragraph 3.6.

This document is offered as a “straw man” for further consideration and discussion by the Registrar Data Escrow working group and the larger registrar community. Please feel free to post comments here and I will undertake revisions as appropriate.

Attached file(s):

Draft RDE Specs (v0.1)

Within 20 minutes of my request (described by some observers as a tantrum), a Transfer-Questions-Triage (t-q-t) team was assembled and a ticketing system was activated.

So this means, for registrars, that you will now begin getting occasional emails from transfer-questions@icann.org in addition to those you receive directly from my address. Thanks in advance for giving these the same attention you give the rest of the emails we send you and for keeping the subject line intact when replying.

Please do share your experiences (whether positive or negative) about this change.

• Registerfly told us on 9 Mar 07 that customers with names on the Registerfly cred can now log into their control panels at registerfly.com to obtain auth-info codes and unlock their names. (Instructions for obtaining an auth code from Registerfly.) Please email me if your customers continue to have problems obtaining auth codes. Screenshots would be helpful.
• Registerfly customers with names on the eNom cred can contact eNom to obtain auth codes and disable transfer-locks. Customers with names at eNom who used Registerfly’s Whois privacy service should be able to get auth codes from either eNom or Registerfly early next week (possibly by 12 Mar 07).
• Registerfly’s port 43 and web-based Whois services are currently not functioning, preventing use of FOAs for .com and .net names. Registerfly has promised to fix this problem as quickly as possible.

I will update this space when there is more to report.

Yes, it has been a (loooong) while since the soft launch of regbits, and I wish I could tell you that our delayed return was caused by our mechanic incessantly tweaking the engine for a few more horsepower, or that we got snowed in by an unexpected blizzard, or that we just forgot to pay the internet bill, but I can’t. The truth is, we’ve just been really busy. And despite the best of intentions, regbits slipped into the black hole for a while.

But with all that’s going on, there is probably no better time to (re)open a new channel of communication to keep you informed. So that’s the plan.

And don’t worry, I’ve already hired a backup team of typing monkeys to keep you informed and entertained in the event regbits falls into the black hole again.

In response to feedback we received last year, this year we are making registrar participation a bit easier. If you participated in last year’s survey, you will notice that the questions have been clarified this year (and reduced from ten to nine). Also, if you are listed as primary contact for more than ten registrars, rather than sending you a notice for each registrar, we emailed you a spreadsheet to provide data for all associated registrars at once.

As noted in our cover letter, ICANN’s compliance staff followed up last year with nearly every non-responsive registrar to audit their compliance with the WDRP. While we plan to do so again this year, we hope you will help us out by submitting this data before the 28th October 2006 deadline.

As a reminder, please feel free to include a link to ICANN’s WDRP FAQ page (http://www.icann.org/whois/wdrp-registrant-faq.htm) in your WDRP notices. This page was created to answer the most commonly-asked registrant questions and hopefully minimize any registrant confusion that may arise.

And speaking of registrant confusion, in our 2005 Report on the Implementation of the Whois Data Reminder Policy, ICANN recommended that registrars and resellers not send WDRP notices from “icann@” email addresses. Although we appreciate the effort to explain to registrants that the WDRP is a mandatory ICANN policy, we have found that use of such addresses tends to create user confusion - particularly in relation to suspicion about phishing attacks.

As always, if you have questions about the WDRP, the survey/audit, or any other compliance matter, please feel free to contact ICANN’s registrar liaison team. We’re here for you!

Regbits is published by ICANN’s registrar liaison team to provide ICANN-accredited registrars with timely information of interest.

Here we plan to bring you information about upcoming events, answers to frequently asked questions, notes about trends in registrant complaints and compliance issues, updates on policy development, and an occassional glimpse behind the scenes at what’s going on in ICANN’s offices. We welcome your feedback and hope you will post comments on the topics discussed.