Home / Blogs

Donuts and TAS: What We Really Care About

Like everyone else applying for new gTLDs, the Donuts team thought it would now be poring over a list of applicant names and strings, nodding heads and at times raising eyebrows.

The timing didn’t work out that way. ICANN did the right thing by closing TAS temporarily in order to understand what it was dealing with. It’s easy enough for applicants to get rattled by what they think may have happened—but while Donuts obviously cares about the integrity of TAS, we’re less concerned about who saw what and more concerned with moving forward.

Saw our file names? Not a huge deal.

It’s not critical if someone saw a Donuts file name or user name. Or even if someone saw ALL our file names and user names. (Naturally, if it turned out to be more than that, like actual content… not ok.) It’s extremely unlikely applicants would have the time to change the business plans behind their applications to a degree significant enough to impact Donuts’ plans.

We saw one file name.

Donuts saw the same non-Donuts file name (for what appeared to be another applicant’s attachment) on two separate occasions while examining our own application. We don’t know whose file it is, as the file name had no applicant - or string-specific information. We reported this to ICANN on April 11, the day we encountered it.

We confirm that we could not see the content of the attachment (i.e., the TAS behavior we saw was exactly as ICANN has described it). If ICANN so requests, we are prepared to certify to ICANN that we will not act on what we saw, harmless as it was. We also point out, however, that file name information has no value to us, even if it contained a TLD string. Why? Because Donuts was meticulous in its own string selection—adopting another string at this late date would deviate us from our own plans. Its impracticable to change horses that quickly even if knowledge of some other string were greatly beneficial to us.

Program changes mid-stream would be very disruptive.

Falling into the trap of using this delay to consider Guidebook changes now would be disruptive to everyone—not merely applicants. It’s far better to maintain predictability and stability so everyone can correctly plan.

This includes two critical areas: new applications in the re-opening, and Batching/ Digital Archery.

Allowing new application creation when the window reopens = bad idea.

While Donuts does not think file name or user name data is fully actionable by existing applicants, an applicant sharing news about what it did see could invite new applicants. This would obviously be unfair to existing applicants.

When TAS closed there were (i) just 12 hours to go in the process; and (ii) the March 29 $5,000 slot payment deadline had passed. To minimize any exacerbating shenanigans due to this accidental disclosure, ICANN should clearly confirm that no new applications will be allowed. To support this ICANN should also publish the maximum number of possible existing applications as soon as possible (as they have known this information since March 29).

Donuts opinion on Batching and Digital Archery

Digital Archery is a skill test. Creative as it is, and though it will require some up-front learning and testing, it’s better than other alternatives. Donuts supports Digital Archery as it is currently described. Attempts to change Digital Archery or any other aspect of batching at this very late stage would create more harm than benefit.

Time is the more critical metric now.

Though we believe file name and user names aren’t particularly actionable by current applicants, given the timelines, there IS an issue that risk could be magnified by the passage of time. Any benefit from the information that may have been derived becomes useless once the application window closes.

The better option is to close the window as soon as possible. This minimizes exposure to inappropriate activity and moves the process ahead. Also, all applicants are paying for the current delay with the ramped-up costs of operating their businesses.

Time is a critical element for ICANN as well.

We don’t agree that ICANN’s reputation has been especially damaged by the TAS situation. Staff took prudent steps to deal with a technical issue, which we all know arise from time to time.

However, open-ended or extensive delays do cause real harm to ICANN’s reputation. Donuts is confident in ICANN, but overanalysis and delay degrade confidence in the organization, especially when, at this point, further delay results in only a little reduction in legal liability to ICANN, at best.

ICANN: stand by your commitment to the community. Disclose whatever results of the forensics you’ve gathered by this Tuesday, May 8. Delay no further. Open and close the five-day window, confirm no new application creations, and conduct the reveal as soon as possible.

Paul Stahura is CEO and co-founder of Donuts Inc., a gTLD applicant.

By Paul Stahura, Founder and CEO Donuts Inc.

Filed Under

Comments

I'm not a fan of the digital Antony Van Couvering  –  May 4, 2012 2:53 AM

I’m not a fan of the digital archery system but I agree with Paul. I’m glad ICANN took the time to find out what’s going on, but they need to build trust and confidence by executing crisply and professionally.

URS Reconfiguration Could Cause Delay Philip S Corwin  –  May 4, 2012 4:14 PM

Paul, in regard to your correct observation that time is a critical element for ICANN as well, and that open-ended or extensive delays may degrade confidence in it—ICANN’s draft budget (http://www.icann.org/en/news/public-comment/op-budget-fy13-01may12-en.htm) states that it intends to hold two URS “summits” (whatever that may be) over the coming months, and then engage in further consultations with the community and current UDRP providers, before issuing an RFP soliciting URS providers. That is a big change from what ICANN staff said in San Jose, where they indicated that the RFP for URS providers would be issued within a month; I have written in detail on this at http://internetcommerce.org/URS-Summits . ICANN has also yet to set up an implementation group on the URS, while the one on the Trademark Clearinghouse has nearly wrapped up.

What they now contemplate appears to go beyond technical implementation into a complete reopening of the URS policy elements to meet their promise of a very (probably unrealistically) low-price RPM. They further state that their “goal” is to have the URS program in place and providers selected by June 2013—but we know that ICANN does not always meet its timetable goals, and we also know that the prior debate on the elements of the URS was divisive and extended.

My understanding is that URS is required to be in place by the time that new gTLDs begin offering domains to general public registrants, or at least very shortly thereafter. So keep your eyes on this because if ICANN overshoots its June 2013 “goal” it could become another cause of delay.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

IPv4 Markets

Sponsored byIPv4.Global

Cybersecurity

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC

DNS

Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix