dotShabaka Diary — Day 5

Today, the fifth installment of dotShabaka Registry’s journal, charting its progress towards becoming one of the first new gTLDs to go live, written by general manager Yasmin Omer.

Tuesday 20 August 2013
We thought it would be timely to offer a recap of our Pre-Delegation Testing (PDT) experience to date.
Prior to PDT
We entered the PDT process with confidence due to our positive experience during beta testing. While we had lots of questions and concerns before entering the PDT beta program, particularly with documentation and test cases, we remained positive because there was constant communication between ourselves and the PDT Service Provider (IIS).
Prior to entering the first production PDT, we found all issues were resolved efficiently. We were also able to speak with ICANN to clarify some of the more vexing issues we’d faced during the PDT Beta program. We were also thankful that Patrik Hildingsson, the Production Manager for PDT (at IIS), even reached out personally to warn us of some documentation issues they’d not yet had time to resolve.
Our experience with the PDT Helpdesk had improved significantly through the process, which is a credit to all those involved.
During PDT
When we finally entered the PDT testing window two weeks ago, there was a noticeable drop in dialogue between ourselves and the PDT Service Provider. This was not necessarily a concern as everything appeared to be going fine, although our technical logs were not showing a great deal of activity. We assume that no news is good news. However, one suggested area for improvement would be an increase in communication during the testing phase, even if it’s an email to say everything is fine and we have no concerns. The lack of communication had our technical team biting their nails everyday while they nervously watched the logs.
By the Wednesday of the second week, we sent an email to ask if there were any problems and if the third week of PDT (described by ICANN as the remedy period) would be required. The response was a little vague, but we think we’re in the clear and the testing is complete. While the system status has not changed, there has been no activity in our logs since last week, suggesting the third week is not required. Fingers crossed.
Overall, we are happy with the process and wish other applicants the best of luck with their PDT. One small tip we can offer is that the data submission window closes at 11:59 UTC on the Friday before your PDT appointment. Don’t mistake this as 23:59 UTC, or you’ll miss out. We uploaded our documents well in advance, but some of our staff almost got caught out when discussing when to hit the “submit” button. Luckily there were keen observers on our internal mailing list and no mistake was made.
Good luck!

Read previous and future diary entries here.

dotShabaka Diary — Day 4

Here’s the fourth installment of dotShabaka Registry’s journal, charting its progress towards becoming one of the first new gTLDs to go live, written by general manager Yasmin Omer.

Friday 16 August 2013
The IBM TMDB webinar was disappointing. We had hoped to gain some much needed insight into the TMDB system, but instead we left with more questions and concerns. Let’s hope IBM can lift their game for next week’s webinar and the integration and testing process is clarified.
In other news, it has been a week since the teleconference to discuss the URS Technical Requirements Document and we are still unclear on when the requirements will be finalised, posted and whether they stand on the critical path to our Sunrise. If the discussions during the teleconference are anything to go by, significant work is required by both parties to finalise the document. Implementing the requirements in the URS Technical Requirements Document isn’t as simple as flicking a switch – development efforts will be required. This work needs to start now.
Finally, there are now only a couple of days left in our Pre-Delegation Testing window and so far we have not heard anything; we hope that no news is good news. Following this we expect the PDT service provider will take a couple of weeks to review our results. Fingers crossed!
Still no welcome package.

Read previous and future diary entries here.

dotShabaka Diary — Day 3

Here’s the third installment of dotShabaka Registry’s journal, charting its progress towards becoming one of the first new gTLDs to go live, written by general manager Yasmin Omer.

Wednesday 14 August 2013
Our Pre-Delegation Testing (PDT) continues. The latest ICANN published timeframe shows 30 days duration to 30 August. Previous communications indicated it would take 14 days plus rectification (if required) and the PDT ‘clock’ is counting down 21 days. When will it end?
We now have access to the TMDB and have received the initial Registration Token. We have run some internal tests and it all looks OK. So what next? We will attend the TMDB webinar today and hopefully the TMDB integration and testing process will be defined. Stay tuned.
According to ICANN we will receive a ‘new Registry’ Welcome Pack soon. I suspect we are ‘ahead of the curve’ in terms of the timing of this pack and other applicants will receive this information once the Agreement is signed.
In other news, ICANN have published IOC, Red Cross and Red Crescent reserved lists in multiple languages, but the IGO list has not been defined. Is ICANN going to publish a list of countries (in six official United Nations languages) or is every Registry going to generate their own list with their own rules? I guess we’ll have to wait and see.

Read previous and future diary entries here.

Dotless domains “dangerous”, security study says

An independent security study has given ICANN a couple dozen very good reasons to continue outlaw “dotless” domain names, but stopped short of recommending an outright ban.
The study, conducted by boutique security outfit Carve Systems and published by ICANN this morning, confirms that dotless domains — as it sounds, a single TLD label with no second-level domain and no dot — are potentially “dangerous”.
If dotless domains were to be allowed by ICANN, internet users may unwittingly send their private data across the internet instead of a local network, Carve found.
That’s basically the same “internal name collision” problem outlined in a separate paper, also published today, by Interisle Consulting (more on that later).
But dotless domains would also open up networks to serious vulnerabilities such as cookie leakage and cross-site scripting attacks, according to the report.
“A bug in a dotless website could be used to target any website a user frequents,” it says.
Internet Explorer, one of the many applications tested by Carve, automatically assumes dotless domains are local network resources and gives them a higher degree of trust, it says.
Such domains also pose risks to users of standard local networking software and residential internet routers, the study found. It’s not just Windows boxes either — MacOS and Unix could also be affected.
These are just a few of the 25 distinct security risks Carve identified, 10 of which are considered serious.
ICANN has a default prohibition on dotless gTLDs in the new gTLD Applicant Guidebook, but it’s allowed would-be registries to specially request the ability to go dotless via Extended Evaluation and the Registry Services Evaluation Process (with no guarantee of success, of course).
So far, Google is the only high-profile new gTLD applicant to say it wants a dotless domain. It wants to turn .search into such a service and expects to make a request for it via RSEP.
Other portfolio applicants, such as Donuts and Uniregistry, have also said they’re in favor of dotless gTLDs.
Given the breadth of the potential problems identified by Carve, you might expect a recommendation that dotless domains should be banned outright. But that didn’t happen.
Instead, the company has recommended that only certain strings likely to have a huge impact on many internet users — such as “mail” and “local” — be permanently prohibited as dotless TLDs.
It also recommends lots of ways ICANN could allow dotless domains and mitigate the risk. For example, it suggests massive educational outreach to hardware and software vendors and to end users.

Establish guidelines for software and hardware manufacturers to follow when selecting default dotless names for use on private networks. These organizations should use names from a restricted set of dotless domain names that will never be allowed on the public Internet.

Given that most people have never heard of ICANN, that internet standards generally take a long time to adopt, and allowing for regular hardware upgrade cycles, I couldn’t see ICANN pulling off such a feat for at least five to 10 years.
I can’t see ICANN approving any dotless domains any time soon, but it does appear to have wiggle-room in future. ICANN said:

The ICANN Board New gTLD Program Committee (NGPC) will consider dotless domain names and an appropriate risk mitigation approach at its upcoming meeting in August.

NTIA alarmed as Verisign hints that it will not delegate new gTLDs

Verisign has escalated its war against competition by telling its government masters that it is not ready to add new gTLDs to the DNS root, raising eyebrows at NTIA.
The company told the US National Telecommunications and Information Administration in late May that the lack of uniform monitoring across the 13 root servers means it would put internet security and stability at risk to start delegating new gTLDs now.
In response, the NTIA told Verisign that its recent position on DNS security is “troubling”. It demanded confirmation that Verisign is not planning to block new gTLDs from being delegated.
The letters (pdf and pdf) were published by ICANN over the weekend, over two months after the first was sent.
Verisign senior VP Pat Kane wrote in the May letter:

we strongly believe certain issues have not been addressed and must be addressed before any root zone managers, including Verisign, are ready to implement the new gTLD Program.
We want to be clearly on record as reporting out this critical information to NTIA unequivocally as we believe a complete assessment of the critical issues remain unaddressed which left unremediated could jeopardize the security and stability of the DNS.
…
we strongly recommend that the previous advice related to this topic be implemented and the capability for root server system monitoring, instrumentation, and management capabilities be developed and operationalized prior to beginning delegations.

Kane’s concerns were first outlined by Verisign in its March 2013 open letter to ICANN, which also expressed serious worries about issues such as internal name collisions.
Verisign is so far the only root server operator to publicly express concerns about the lacking of coordinated monitoring, and many people believe that the company is simply desperately trying to delay competition for its $800 million .com business for as long as possible.
These people note that in early November 2012, Verisign signed a joint letter with ICANN and NTIA that said:

the Root Zone Partners are able to process at least 100 new TLDs per week and will commit the necessary resources to meet all root zone management volume increases associated with the new gTLD program

That letter was signed before NTIA stripped Verisign of its right to increase .com prices every year, depriving it of tens or hundreds of millions of dollars of additional revenue.
Some say that Verisign is raising spurious security concerns now purely because it’s worried about its bottom line.
NTIA is beginning to sound like one of these critics. In its response to the May 30 letter, sent by NTIA and published by ICANN on Saturday, deputy associate administrator Vernita Harris wrote:

NTIA and VeriSign have historically had a strong working relationship, but inconsistencies in VeriSign’s position in recent months are troubling… NTIA fully expects VeriSign to process change requests when it receives an authorization to delegate a new gTLD. So that there will be no doubt on this point, please provide me a written confirmation no later than August 16, 2013 that VeriSign will process change requests for the new gTLD program when authorized to delegate a new gTLD.

Harris said that a system is already in place that would allow the emergency rollback of the root zone, basically ‘un-delegating’ any gTLD that proves to cause a security or stability problem.
This would be “sufficient for the delegation of new gTLDs”, she wrote.
Could Verisign block new gTLDs?
It’s worth a reminder at this point that ICANN’s power over the DNS root is something of a facade.
Verisign, as operator of the master A root server, holds the technical keys to the kingdom. Under its NTIA contract, it only processes changes to the root — such as adding a TLD — when NTIA tells it to.
NTIA in practice merely passes on the recommendations of IANA, the department within ICANN that has the power to ask for changes to the root zone, also under contract with NTIA.
Verisign or NTIA in theory could refuse to delegate new gTLDs — recall that when .xxx was heading to the root the European Union asked NTIA to delay the delegation.
In practice, it seems unlikely that either party would stand in the way of new gTLDs at the root, but the Verisign rhetoric in recent months suggests that it is in no mood to play nicely.
To refuse to delegate gTLDs out of commercial best interests would be seen as irresponsible, however, and would likely put its role as custodian of the root at risk.
That said, if Verisign turns out to be the lone voice of sanity when it comes to DNS security, it is ICANN and NTIA that will ultimately look like they’re the irresponsible parties.
What’s next?
Verisign now has until August 16 to confirm that it will not make trouble. I expect it to do so under protest.
According to the NTIA, ICANN’s Root Server Stability Advisory Committee is currently working on two documents — RSSAC001 and RSSAC002 — that will outline “the parameters of the basis of an early warning system” that will address Verisign’s concerns about root server management.
These documents are likely to be published within weeks, according to the NTIA letter.
Meanwhile, we’re also waiting for the publication of Interisle Consulting’s independent report into the internal name collision issue, which is expected to recommend that gTLDs such as .corp and .home are put on hold. I’m expecting this to be published any day now.

Afilias wants registrar ownership ban lifted on .mobi and .pro

Afilias has applied to ICANN to have its ban on owning registrars in two of its own gTLDs, .mobi and .pro, lifted.
With requests to ICANN a few days ago (here and here), the company said it wants to be able to own more than 15% of an ICANN-accredited registrar that sells both TLDs, which is currently forbidden by the two Registry Agreements in question.
Afilias’ proposed new .info contract, which was renegotiated this year (because it expired) and closed for public comment last week, would also enable the company to vertically integrate with a .info registrar.
A process for relaxing the cross-ownership rules on a per-TLD basis was approved by ICANN’s board of directors last October.
The only registry so far to have its contractual ban lifted is puntCat, the .cat registry operator.
When an ICANN working group was discussing the vertical integration issue a couple of years ago, Afilias was one of the participants that held fast against any relaxation of the 15% ownership cap, eventually driving the working group into stalemate and forcing the ICANN board’s hand.

Six more LROs kicked out, most for “front-running”

Six more new gTLD Legal Rights Objections, six more rejected objections.
The World Intellectual Property Organization is chewing through its caseload of LROs at a regular pace now, made all the more easier by the fact that a body of precedent is being accumulated.
Objections rejected in decisions published last week cover the gTLDs .home, .song, .yellowpages, .gmbh and .cam.
All but one were thrown out, with slightly different panelist reasoning, because they had engaged in some measure of “front-running” — applying for a trademark just in order to protect a gTLD application.
Here’s a quick summary of each decision, starting with what looks to be the most interesting:
.yellowpages (hibu (UK) v. Telstra)
Last week somebody asked me on Twitter which LROs I thought might actually succeed. I replied:

@ManagingIP Just based on the list of strings and objectors, only .delmonte, .merck and .yellowpages jump out at me.

— Kevin Murphy (@DomainIncite) July 23, 2013

Well, my initial hunch on .yellowpages was wrong, and I think I’m very likely to have been wrong about the other two also.
This case is interesting because it specifically addresses the issue of two matching trademarks happily living side-by-side in the trademark world but clashing horribly in the unique gTLD space.
The objector in this case, hibu, publishes the Yellow Pages phone book in the UK and has a big portfolio of trademarks and case law protecting its brand. If anyone has rights, it’s these guys.
But the “Yellow Pages” brand is used in several countries by several companies. In the US, there’s some case law suggesting that the term is now generic, but that’s not the case in the UK or Australia.
On the receiving end of the objection was the Australian telecoms firm Telstra, which is the publisher of the Aussie version of the Yellow Pages and, luckily for it, the only applicant for .yellowpages.
The British company argued that “no party should be entitled to register the Applied-for gTLD”, due to the potential for confusion between the same brand being owned by different companies in different countries.
The panel concluded that brands will clash in the new gTLD space, and that that’s okay:

It is inherent in the nature of the gTLD regime that those applicants who are granted gTLDs will have first-level power extending throughout the Internet and across jurisdictions. The prospect of coincidence of brand names and a likelihood of confusion exists.
…
The critical issue in this LRO proceeding is whether the Objector’s territorial rights in the term “YELLOW PAGES” (and the prospect of other non-objecting third parties’ territorial right) means that the applicant (or anyone else for that matter) should not be entitled to the Applied-for gTLD.

The panelist uses the eight-criteria test in the Applicant Guidebook to make his decision, but he chose to highlight two words:

the Panel finds that the Objector has failed to establish, as it alleges, that the potential use of the Applied-for gTLD by the applicant… unjustifiably impairs the distinctive character or the reputation of the objector’s mark… or creates an impermissible likelihood of confusion between the applied for gTLD and the Objector’s mark.

Because Telstra has rights to “Yellow Pages” too, and because it’s promising to respect trademark rights at the second level, the panelist concluded that its application should be allowed to proceed.
It’s the third instance of a clash between rights holders in the LRO process and the third time that the WIPO panelist has adopted a laissez faire approach to new gTLDs.
And as I’ve said twice before, if this type of decision becomes the norm — and I think it will — we’re likely to see many more defensive applications for brand names in future new gTLD rounds.
The LRO is not shaping up to be an alternative to applying for a gTLD as a means to defend a legitimate brand. Applying for a gTLD matching your trademark and then fighting through the application process may turn out to be the only way to make sure nobody else gets that gTLD.
.cam (AC Webconnecting Holding v. United TLD Holdco)
Both sides of this case are applicants for .cam. United TLD is a Demand Media subsidiary while AC Webconnecting is a Netherlands-based operator of several webcam-based porn sites.
Like so many other applicants, AC Webconnecting applied for its European trademark registration for “.cam” and a matching logo in December 2011, just before the ICANN application window opened.
The panelist decided that its trademark was acquired in a bona fide fashion, he also decided that the company had not had enough time to build up a “distinctive character” or “reputation” of its marks.
That meant the Demand Media application could not be said to take “unfair advantage” of the marks. The panelist wrote:

Given the relatively short existence of these trademarks, it is unlikely that either [trademark] has developed a reputation.
…
In the Panel’s opinion, replication of a trademark does not, of itself, amount to taking unfair advantage of the trademark – something more is required.
…
the Panel considers that this something more in the present context needs to be along the lines of an act that has a commercial effect on a trademark which is undertaken in bad faith – such as free riding on the goodwill of the trademark, for commercial benefit, in a manner that is contrary to honest commercial practices.

What we’re seeing here is another example of a trademark front-runner losing, and of a panelist indicating that applicants need some kind of bad faith in order to lose and LRO.
.home (Defender Security Company v. DotHome Inc.)
Kicked out for the same reasons as the other Defender objections to rival .home — it was a transparent gaming attempt based on a flimsy, recently acquired trademark. See here and here.
DotHome Inc is the subsidiary Directi/Radix is using to apply for .home.
The decision (pdf) goes into a bit more detail than the other .home decisions we’ve seen to date, including information about how much Defender paid to acquire its trademarks ($75,000) and how many domains its bogus Go Daddy reseller site has sold (three).
.home (Defender Security Company v. Baxter Pike)
Ditto. This time the applicant was a Donuts subsidiary.
.song (DotMusic Limited v. Amazon)
Like the failed .home objections, the .song objection was based on a trademark acquired tactically in late 2012 by Constantine Roussos, whose company, CGR E-Commerce, is applying for .music.
This objection failed (pdf) for the same reasons as the same company’s objection to Amazon’s .tunes application failed last week — a trademark for “.SONG” is simply too generic and descriptive to give DotMusic exclusive rights to the matching gTLD.
Roussos has also filed seven LROs against his competitors for .music, none of which have yet been decided.
.gmbh (TLDDOT GmbH v. InterNetWire Web-Development)
Both objector and respondent here are applicants for .gmbh, which indicates limited liability companies in German-speaking countries.
TLDDOT registered its European trademark in “.gmbh” a few years ago.
Despite the fact that it was obviously acquired purely in order to secure the matching gTLD, the panelist in this case ruled that it was bona fide.
Despite this, the panelist concluded that for InternetWire to operate .gmbh in the generic, dictionary-word sense outlined in its application would not infringe these trademark rights.

ICANN says Article 29 letter does not give EU registrars privacy opt-out

Registrars based in the European Union won’t immediately be able to opt out of “illegal” data retention provisions in the new 2013 Registrar Accreditation Agreement, according to ICANN.
ICANN VP Cyrus Namazi on Saturday told the Governmental Advisory Committee that a recent letter from the Article 29 Working Party, which comprises the data protection authorities of EU member states, is “not a legal authority”.
Article 29 told ICANN last month that the RAA’s provisions requiring registrars to hold registrant data for two years after the domain expires were “illegal”.
While the RAA allows registrars to opt out of clauses that would be illegal for them to comply with, they can only do so with the confirmation of an adequate legal opinion.
The Article 29 letter was designed to give EU registrars that legal opinion across the board.
But according to Namazi, the letter does not meet the test. In response to a question from the Netherlands, he told the GAC:

We accept it from being an authority, but it’s not a legal authority, is our interpretation of it. That it actually has not been adopted into legislation by the EU. When and if it becomes adopted then of course there are certain steps to ensure that our contracted parties are in line with — in compliance with it. But we look at them as an authority but not a legal authority at this stage.

It seems that when the privacy watchdogs of the entire European Union tell ICANN that it is in violation of EU privacy law, that’s not taken as an indication that it is in fact in violation of EU privacy law.
The European Commission representative on the GAC expressed concern about this development during Saturday’s session, which took place at ICANN 47 in Durban, South Africa.

IAB gives dotless domains the thumbs down

The Internet Architecture Board believes dotless domain names would be “inherently harmful to Internet security.”
The IAB, the oversight committee which is to internet technical standards what ICANN is to domain names, weighed into the debate with an article apparently published yesterday.
In it, the committee states that over time dotless domains have evolved to be used only on local networks, rather than the internet, and that to start delegating them at the top level of the DNS would be dangerous:

most users entering single-label names want them to be resolved in a local context, and they do not expect a single name to refer to a TLD. The behavior is specified within a succession of standards track documents developed over several decades, and is now implemented by hundreds of millions of Internet hosts.
…
By attempting to change expected behavior, dotless domains introduce potential security vulnerabilities. These include causing traffic intended for local services to be directed onto the global Internet (and vice-versa), which can enable a number of attacks, including theft of credentials and cookies, cross-site scripting attacks, etc. As a result, the deployment of dotless domains has the potential to cause significant harm to the security of the Internet

The article also says (if I understand correctly) that it’s okay for browsers to interpret words entered into address bars without dots as local resources and/or search terms rather than domain names.
It’s pretty unequivocal that dotless domains would be Bad.
The article was written because there’s currently a lot of talk about new gTLD applicants — such as Google, Donuts and Uniregistry — asking ICANN to allow them to run their TLDs without dots.
There’s a ban in the Applicant Guidebook on the “apex A records” that would be required to make dotless TLDs work, but it’s been suggested that applicants could apply to have the ban lifted on a case by case basis.
More recently, ICANN’s Security and Stability Advisory Committee has stated almost as unequivocally as the IAB that dotless domains should not be allowed.
But for some reason ICANN recently commissioned a security company to look into the issue.
This seems to have made some people, such as the At Large Advisory Committee, worried that ICANN is looking for some wiggle room to give its new gTLD paymasters what they want.
Alternatively, ICANN may just be looking for a second opinion to wave in the faces of new gTLD registries when it tells them to take a hike. It was quite vague about its motives.
It’s not just a technical issue, of course. Dotless TLDs would shake up the web search market in a big way, and not necessarily for the better.
Donuts CEO Paul Stahura today published an article on CircleID that makes the case that it is the browser makers, specifically Microsoft, that are implementing DNS all wrong, and that they’re objecting to dotless domains for competitive reasons. The IAB apparently disagrees, but it’s an interesting counterpoint nevertheless.

ICANN offers to split the cost of GAC “safeguards” with new gTLD registries

All new gTLD applicants will have to abide by stricter rules on security and Whois accuracy under government-mandated changes to their contracts approved by the ICANN board.
At least one of the new obligations is likely to laden new gTLDs registries with additional ongoing costs. In another case, ICANN appears ready to shoulder the financial burden instead.
The changes are coming as a result of ICANN’s New gTLD Program Committee, which on on Tuesday voted to adopt six more pieces of the Governmental Advisory Committee’s advice from March.
This chunk of advice, which deals exclusively with security-related issues, was found in the GAC’s Beijing communique (pdf) under the heading “Safeguards Applicable to all New gTLDs”.
Here’s what ICANN has decided to do about it.
Mandatory Whois checks
The GAC wanted all registries to conduct mandatory checks of Whois data at least twice a year, notifying registrars about any “inaccurate or incomplete records” found.
Many new gTLD applicants already offered to do something similar in their applications.
But ICANN, in response to the GAC advice, has volunteered to do these checks itself. The NGPC said:

ICANN is concluding its development of a WHOIS tool that gives it the ability to check false, incomplete or inaccurate WHOIS data
…
Given these ongoing activities, ICANN (instead of Registry Operators) is well positioned to implement the GAC’s advice that checks identifying registrations in a gTLD with deliberately false, inaccurate or incomplete WHOIS data be conducted at least twice a year. To achieve this, ICANN will perform a periodic sampling of WHOIS data across registries in an effort to identify potentially inaccurate records.

While the resolution is light on detail, it appears that new gTLD registries may well be taken out of the loop completely, with ICANN notifying their registrars instead about inaccurate Whois records.
It’s not the first time ICANN has offered to shoulder potentially costly burdens that would otherwise encumber registry operators. It doesn’t get nearly enough credit from new gTLD applicants for this.
Contractually banning abuse
The GAC wanted new gTLD registrants contractually forbidden from doing bad stuff like phishing, pharming, operating botnets, distributing malware and from infringing intellectual property rights.
These obligations should be passed to the registrants by the registries via their contracts with registrars, the GAC said.
ICANN’s NGPC has agreed with this bit of advice entirely. The base new gTLD Registry Agreement is therefore going to be amended to include a new mandatory Public Interest Commitment reading:

Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.

The decision to include it as a Public Interest Commitment, rather than building it into the contract proper, is noteworthy.
PICs will be subject to a Public Interest Commitment Dispute Resolution Process (PICDRP) which allows basically anyone to file a complaint about a registry suspected of breaking its commitments.
ICANN would act as the enforcer of the ruling, rather than the complainant. Registries that lose PICDRP cases face consequences up to an including the termination of their contracts.
In theory, by including the GAC’s advice as a PIC, ICANN is handing a loaded gun to anyone who might want to shoot down a new gTLD registry in future.
However, the proposed PIC language seems to be worded in such a way that the registry would only have to include the anti-abuse provisions in its contract in order to be in compliance.
Right now, the way the PIC is worded, I can’t see a registry getting terminated or otherwise sanctioned due to a dispute about an instance of copyright infringement by a registrant, for example.
I don’t think there’s much else to get excited about here. Every registry or registrar worth a damn already prohibits its customers from doing bad stuff, if only to cover their own asses legally and keep their networks clean; ICANN merely wants to formalize these provisions in its chain of contracts.
Actually fighting abuse
The third through sixth pieces of GAC advice approved by ICANN this week are the ones that will almost certainly add to the cost of running a new gTLD registry.
The GAC wants registries to “periodically conduct a technical analysis to assess whether domains in its gTLD are being used to perpetrate security threats such as pharming, phishing, malware, and botnets.”
It also wants registries to keep records of what they find in these analyses, to maintain a complaints mechanism, and to shut down any domains found to be perpetrating abusive behavior.
ICANN has again gone the route of adding a new mandatory PIC to the base Registry Agreement. It reads:

Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

You’ll notice that the language is purposefully vague on how registries should carry out these checks.
ICANN said it will convene a task force or GNSO policy development process to figure out the precise details, enabling new gTLD applicants to enter into contracts as soon as possible.
It means, of course, that applicants could wind up signing contracts without being fully apprised of the cost implications. Fighting abuse costs money.
There are dozens of ways to scan TLDs for abusive behavior, but the most comprehensive ones are commercial services.
ICM Registry, for example, decided to pay Intel/McAfee millions of dollars — a dollar or two per domain, I believe — for it to run daily malware scans of the entire .xxx zone.
More recently, Directi’s .PW Registry chose to sign up to Architelos’ NameSentry service to monitor abuse in its newly relaunched ccTLD.
There’s going to be a fight about the implementation details, but one way or the other the PIC would make registries scan their zones for abuse.
What the PIC does not state, and where it may face queries from the GAC as a result, is what registries must do when they find abusive behavior in their gTLDs. There’s no mention of mandatory domain name suspension, for example.
But in an annex to Tuesday’s resolution, ICANN’s NGPC said the “consequences” part of the GAC advice would be addressed as part of the same future technical implementation discussions.
In summary, the NGPC wants registries to be contractually obliged to contractually oblige their registrars to contractually oblige their registrants to not do bad stuff, but there are not yet any obligations relating to the consequences, to registrants, of ignoring these rules.
This week’s resolutions are the second big batch of decisions ICANN has taken regarding the GAC’s Beijing communique.
Earlier this month, it accepted some of the GAC’s direct advice related to certain specific gTLDs it has a problem with, the RAA and intergovernmental organizations and pretended to accept other advice related to community objections.
The NGPC has yet to address the egregiously incompetent “Category 1” GAC advice, which was the subject of a public comment period.