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.
|
||||
|
|
Monday, January 14
by
Bret Fausett
on Mon 14 Jan 2008 02:16 PM PST
Friday, January 11
by
Bret Fausett
on Fri 11 Jan 2008 01:39 PM PST
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.
Thursday, January 10
by
Bret Fausett
on Thu 10 Jan 2008 04:31 PM PST
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: It's a start. 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.
by
Bret Fausett
on Thu 10 Jan 2008 08:58 AM PST
by
Bret Fausett
on Thu 10 Jan 2008 08:32 AM PST
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. Wednesday, January 9
by
Bret Fausett
on Wed 09 Jan 2008 11:13 AM PST
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."
by
Bret Fausett
on Wed 09 Jan 2008 08:55 AM PST
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. Tuesday, January 8
by
Bret Fausett
on Tue 08 Jan 2008 07:40 PM PST
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.
Monday, January 7
by
Bret Fausett
on Mon 07 Jan 2008 02:18 PM PST
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. Friday, January 4
by
Bret Fausett
on Fri 04 Jan 2008 10:58 AM PST
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.
by
Bret Fausett
on Fri 04 Jan 2008 10:55 AM PST
Thursday, January 3
by
Bret Fausett
on Thu 03 Jan 2008 10:09 AM PST
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.
Wednesday, January 2
by
Bret Fausett
on Wed 02 Jan 2008 10:57 AM PST
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.
Happy New Year! 2008 promises to be an interesting journey. Tuesday, January 1
by
Bret Fausett
on Tue 01 Jan 2008 08:27 PM PST
Blog more in 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. 