create a reader account | log in
icann.Blog
Bret Fausett's ICANN Blog
Main Page  »  ICANN
View Article  Dispute Resolution and ICANN
On Friday, ICANN posted a discussion document about dispute resolution between the ICANN community and the ICANN Board. It's a short but heady piece that you really ought to read and consider. Here's a provocative sentence from the paper to get you reading: "There may be circumstances where it is appropriate for the ICANN community to be able to move for an extraordinary dissolution of the Board and its consequent reconstitution." Wow.

Who knows what the triggering event might be, but the trigger could be pulled by super-majority votes from all of the Supporting Organizations and Advisory Councils.
View Article  Domainfest 2008
The schedule for Domainfest Hollywood is up. I'll be speaking at the lunch session on Wednesday, January 23rd on "Domainer Worst Practices." It's a subject I know well.
View Article  ICANN Investigates, NSI Responds
Computerworld and eWeek are both reporting that ICANN is investigating the Network Solutions front-running scheme.

Meanwhile, on the GNSO's General Assembly list, Network Solution's Jonathan Nevett reports:

I also want to mention that we have made some enhancements to our approach in response to many of the comments we have received. We still are evaluating some others internally. Here is what we have done so far:

1. All new reserved names will not resolve to any page at all.

2. We have addressed the concerns related to disclosure of zone file and DNS server information of the reserved names. This information will no longer be available to anyone.

3. We have removed our customer protection measure from our WHOIS search page, so that no domains searched on this page will be reserved.

4. We are providing additional customer notification of our protection measure on our home and search web pages.

It's a start.
View Article  ICANN-F Root Agreement Posted
ICANN has published its proposed agreement with ISC for management of the F Root Server. Thanks!
View Article  Why NSI's Front-Running Hurts Consumers
In a nutshell, Network Solutions is preventing consumers from shopping on price.

Try this yourself. Go to http://www.networksolutions.com. Do you see the price of a one-year registration anywhere? (No. All you see are some prices for package deals and hosting contracts.) Enter a name you know doesn't exist into the lookup box, and see how many pages of upsells you have to wade through before you get to the price. (I counted five.) On the fifth page, assuming you haven't purchased any upsells along the way, the check out cart finally shows you the cost of a five-year registration for $99.95. Change that default selection to one year, and you see the price is $34.99.

Too much? Yes, I agree. (In fact, I would have gone to another registrar one or two pages into that awful customer experience.)

So now let's jump over to a registrar with a better price. You can pretty much pick any registrar in the world, as NSI is at the top rung of the price ladder.

The name you want isn't available. It's now exclusively available through NSI at that wonderful price of $34.99/year.

As soon as the lookup occurred on the Network Solutions website, NSI reserved the name under its own registration. They hadn't told you the price before you looked it up, but now you can only get the name you wanted from NSI at the above-market price set by NSI.

Don't accept the line about this being a new service for the protection of consumers. This service is meant to capture consumers who are shopping around.
View Article  A Better Mousetrap
So if you start from the premise that NSI has described a real problem, in which registrar queries to the registry are sniffed and sold by the registries themselves, is there a better way to solve the problem than with what NSI has done? I think so.

To stop the sniffing, you'd do the first availability lookup in your own walled garden. I expect many registrars already are getting daily dumps of the TLD zone files. You'd simply take the zone file data, which is always less than 24 hours old, and do your first lookup against your own database. This is going to give you an answer on the name's availability that is 99.9% accurate. This ensures that no queries are passed to the registry. When you have the result, tell the registrant that the name is likely available and that you'll do one final lookup after the credit card information is submitted. Then, simply go to the registry when you're sure the customer is ready to purchase the name. Seems simple enough. What am I missing?

ADD: Here's an even better mousetrap, courtesy of John Levine, writing on the At Large mailing list: "I entirely agree that NSI's four-day hold is anticompetitive, particularly in view of their above-market prices. But what if they held it for four minutes? I still think that the world would be better with no AGP at all, but it seems one could make a plausible argument for holding a domain for the length of time it takes to run a shopping cart through a checkout."
View Article  A 'Reasonable' Explanation?
All the news of the day continues to be about NSI's front running-domain tasting service. Yesterday, I said the explanation didn't hold water. A second explanation from NSI (on the GNSO's General Assembly mailing list) starts to sound more reasonable. NSI claims that gTLD registries ("or ISPs") are selling registrar lookup data to third-party domain tasters, who then taste a domain before the customer can register it. If true, that's a real concern that needs to be addressed. I'm not sure NSI has hit on the right solution because this "solution" has the potential to cause just as much consumer confusion as the practice the company is trying to prevent.

If a registry leak is causing front-running, however, it's a hole that needs to be patched, preferably by ICANN.
View Article  Front-Running and Domain Tasting Together At Last
I was really surprised by the news today that Network Solutions has launched a new "service" that combines front-running with domain tasting. Since separating from Verisign, I had the distinct impression that the new management team was trying hard to separate the Network Solutions brand from some of the company's past evil practices. As noted by ICANNWatch, Network Solutions says the new practice "protects" consumers, but the explanation makes no sense. The only protection runs to Network Solutions, which has an exclusive on any name looked up through its web site for a four day period. It's a clever exploit of the add grace period, but a step backward in the effort to rehabilitate the NSI brand.
View Article  ICANN and the Root Server Operators
On Friday, ICANN announced that it had reached an agreement for the management of the F Root Server with the Internet Software Consortium. It might have been a bigger deal had they actually linked a copy of the agreement. I've asked for a copy, and ICANN's press point person on this announcement, Jason Keenan, has kindly offered to hunt it down.

What will be interesting to see when the agreement is posted is what it actually obligates the parties to do, if anything. Keep in mind that reaching agreements with the root server operators is one of the final tasks for ICANN to complete under ICANN's own agreements with the United States. Up until this time, very little progress has been made. The root server operators had little to no incentive to sign up to an agreement with anyone. Because they mirror and publish a copy of contents of the A root server, they need nothing from ICANN to continue doing what they've always done. The only leverage ICANN has over the root server operators is the weight of ICANN's own moral authority, tenuous as that may be, to prevail on the root server operators to do something for the 'good of the Internet.' From the root server operators' perspective, they were here doing their job before ICANN was created and will be around long after ICANN has been dismantled, so why enter an agreement with ICANN? (They might have been far more likely to enter agreements first with each other.)

The first thing I want to see when the agreement is published is whether it actually obligates the parties to do anything. Is this agreement just fancy window-dressing for the U.S. Department of Commerce, so ICANN can report that it is making progress in this area where so little progress has been made in the last 10 years? Or does this agreement actually advance the case of improved service, reliability and security for the root servers? How close is the agreement negotiated to the model root server agreement ICANN published back in 2002? Interesting questions that have to await the actual release of the agreement for answers.
View Article  What To Say on the JPA
Ugh. I wrote a really long post here and it was eaten by Blogware. No time to rewrite it now. Here's what I wrote about. Comments due on February 15th.
View Article  What To Say on the JPA

View Article  Kenya and ICANN's 2008 Annual Meeting
The news from Kenya is troubling enough by itself, but it also may have an impact on ICANN's choice of location for its annual meeting, now scheduled for November 2nd-7th, 2008. Before the election fraud and the post-election violence, Kenya was the front-runner among the African bids to host ICANN's 10th Annual Meeting (at which new ICANN Board Chair Peter Dengate-Thrush promises a "special celebration"). With only 10 months until the meeting and the pressing need to decide on a meeting venue promptly, expect the violence and political volatility in Kenya to give alternative venues a second chance.
View Article  ICANN Predictions for 2008
Although the blog has developed a few cobwebs here and there over the last year, it hasn't been because I've stopped following ICANN daily or participating in its policy processes. Far from it. But with the spirit of yesterday's 'more blogging' resolution fresh in mind, here are my predictions for 2008.
  • The new TLD testbed evaluation process that ICANN launched in November, 2000 will come to a welcome end. By the end of June, 2008, ICANN will have a Request for Proposals published. ICANN will begin to receive and evaluate applications for new top-level domains in Q4, 2008;

  • Before accepting new applications, ICANN will clear the queue of its forty-or-so legacy applications. Only a handful of new TLD proponents from 2000 will remain interested in pursuing their old applications. (Predictions: .WEB, .HEALTH, .UNION, .GEO and .III);

  • ICANN will expect to receive 50-60 new TLD applications in the first wave but will receive twice that many. Two-thirds of the new TLD applications will be for IDN top-level domains;

  • Of the 100 or so new TLD applications received in the first wave, at least 60 will have Verisign, Neustar, or Afilias as the proposed "back-end" registry provider. DENIC and the DotAsia group will account for another 10% of the applications;

  • The Whois National Law Procedure will create a new market for privacy services, and registrars will race to incorporate private registration subsidiaries in the countries with the strongest privacy laws;

  • The GAC and the ccTLDs will chase themselves in circles trying to create a policy for the creation and allocation of IDN ccTLDs; and

  • The JPA discussions between ICANN and the Department of Commerce will produce yet another list of things ICANN should concentrate on in the new year (and a new round of Congressional hearings) but the new list will finally put the lie to the expectation that the U.S. has any intention of freeing ICANN from its U.S. contractual ties....especially in an election year.
Contrary thoughts or other predictions welcome.

Happy New Year! 2008 promises to be an interesting journey.
View Article  Resolution No. 9
Blog more in 2008.