Tuesday 5 November 2013
After four months of journal entries, the dotShabaka Registry Diary is wrapping up today following the delegation of شبكة. and official commencement of Sunrise.
The journey has been long and challenging at times. After all the blood, sweat and tears, I strongly believe our experience will be to the benefit of other applicants to follow.
Along the way we experienced the joys of passing pre-delegation testing and commencing Sunrise, but we also documented the lows of name collisions and difficulties in writing a Registry Registrar Agreement.
Throughout the journey it was helpful to receive feedback and comments from the community supporting our cause. This dialogue helped get us to where we are today and a special thank you must be made to IBM’s TMCH team, ICANN, the Pre-Delegation Testing team at IIS (and the PDT Helpdesk) and the many Registrars who have connected with us along the way. Also, a big thank you to Domain Incite and Kevin Murphy for making this journal series possible.
As our delegation journey comes to an end, our TLD launch strategy begins. We have strong ambitions for شبكة. to be the centre of all things Arabic online and we encourage you to continue to watch our progress via our website.
As a parting message, below are our top five tips for other applicants:
1. Communication
Communication is vitally important throughout the process. Be prepared for important emails at any time of the day. When in doubt, always clarify with ICANN and your advisors first. If you are not sure ask ICANN through the CSC portal and if you don’t get a good answer from ICANN ask again through the CSC portal.
2. Seamless integration with RSP
Ensure you have open lines of communication with your Registry Services provider to avoid hiccups and delays. We received technical communications that should have been intended for ARI Registry Services, but our close working relationship with them helped ensure a smooth process.
3. Sort out your product and strategy
Registrar community, potential Registrants, media and interest groups will want information about your TLD. Be ready to describe your TLD, the primary market, eligibility, the launch strategy and other key information.
4. Expect the unexpected
This goes without saying, especially in the ICANN ecosystem. Be flexible and prepare for the worst.
5. The ICANN interface is improving
We understand that many of the frustrations with ICANN occurred because we were the first, and we were pushing hard to go to market. However, it is improving. ICANN are now sending a media kit and hopefully one day someone will get a Welcome Pack.
Good luck to all the other applicants, we’ll be closely watching your progress through delegation.
Regards
Yasmin Omer
General Manager
dotShabaka Registry

Saturday 2 November 2013
It’s with great pleasure that I can finally say that we are the first new gTLD Registry Operator to commence its Sunrise Period! I’m truly excited about taking this TLD to the Arabic speaking world and revolutionising their Internet experience. So what’s happened since the last entry?
We received, and responded to, the TLD on-boarding Information Request from ICANN. New gTLD Registry Operators (and their Registry Services Providers) should be prepared to promptly provide ICANN with technical information regarding:

• The Registry Operator’s provision of the zone file access service;
• Bulk thin registration data access to ICANN;
• Data Escrow – Registry Reporting Interface;
• Implementation of the URS system;
• EPP extensions for the TLD; and
• EPP SLA Monitoring.

We requested the registration of our IDN Table on the IANA Repository of IDN Practices.
We obtained approval of our TLD Startup Information from ICANN. It’s certainly clear from our interactions with ICANN that the process of, and the requirements for, obtaining IBM’s acceptance of Sunrise dates and ICANN’s approval of TLD Startup Information, is yet to be defined. As a result, there was a delay in obtaining ICANN’s approval of our TLD Startup Information.
If you’re a new gTLD Registry Operator and you want your TLD Startup Information approved quickly, here are some tips:

• Once you have a fair idea of when your Sunrise will commence (could be before you’re delegated), reach out to IBM independently and request a number of potential dates. The team at IBM has been very responsive by promptly accepting our Sunrise dates.
• Include your eligibility policy for general registration with your TLD Startup Information. Yes, ICANN has explicitly stated that this is not a requirement they have imposed but it seems that they need it.
• Remember that ICANN’s review is a legal review. Ensure that your policies very clearly demonstrate your compliance with the relevant requirements. Use diagrams.
• Be prepared to respond to ICANN or IBM at any time – they’re both on opposite sides of the world to each other. ICANN thankfully ensure that the process is interactive, so be prepared to interact.

Good luck to everyone. We look forward to being joined by many more New gTLD Registry Operators in Sunrise.

Monday 28 October 2013
It’s been five days since we were delegated and I thought it would be timely to provide readers with an update of what’s happened following this monumental occasion.
Tumbleweeds! As far as the program is concerned, we haven’t progressed one iota.
We submitted all the information necessary for Sunrise to ICANN and we still wait. We want to begin immediately and are currently in a holding pattern.
We’ve been doing significant media outreach over the past week and the number one question we keep getting asked is: what’s next and when can I register my شبكة. domain?

Friday 18 October 2013
Maybe we are starting to see some positive steps from ICANN towards delegation:
We received a revised Registry Agreement, Specification six that includes the requirements for Name Collision Occurrence Management and Report Handling.
ICANN made an announcement that included the statement that collision “…assessments and SLD lists will be posted to the specific TLD’s registry agreement page on the ICANN website. The first of these will be available before the end of this week.”
ICANN reached out this week and requested a detailed list of contacts for legal, media, financial, emergency, CZDS, TMDB, abuse, URS and compliance.
We are still waiting for ICANN to comment on the TMCH launch issues highlighted in our 12 October 12 journal.
Oh, and we are still waiting for the Welcome Pack!

Tuesday 15 October 2013
Still no advice from ICANN on transition to IANA. As we approach the transition to delegation and start launch processes, we remain concerned about the following process and schedule risks:
ICANN have made references to the TLD Startup information being submitted “…via the customer service portal or other mechanism” but have not provided details. We are concerned that the TLD Startup interface has not been provided. Why not allow TLDs to enter the information now and submit it to ICANN once delegated to the root zone?
The process to ‘Email ICANN CSC – Confirm Tests Completed’ is not documented. Without a process definition or certificate to confirm IBM’s email advice that شبكة. has “passed TMDB testing” we risk ICANN rejecting the launch submission and the Sunrise schedule being thrown out.
ICANN have stated the TLD Startup Information must include confirmation that the TMCH Sunrise and Claims Operator has accepted the start and end dates prior to the Registry Operator providing the TLD Startup Information. There is no process documented for submitting the start and end dates to the TMCH.
If we choose the ‘Alternate Path to Delegation’ as defined in the ‘New gTLD Collision Occurrence Management Plan’ we need to block all second-level labels that appear in DNS requests to the applied-for TLD in the DITL and other relevant dataset. ICANN have committed to developing the list of labels but have not defined a timeline or distribution process. Why not distribute the list now so we don’t have to manage Registry change after the transition process starts?

Friday 11 October 2013
We are not sure if anyone else has noticed, but there are differences between the published documentation for Rights Protection Mechanisms, Trademark Clearinghouse and the transition to delegation process. This has created confusion.
To seek clarification, we sent the following questions to ICANN for a response:
Issue 1
IBM confirmed in an email on the 4th of October that شبكة. has passed TMDB testing. The message was:
“…confirm that all tests are ok and have asked to forward your certification request to ICANN.”
Based on this correspondence, it is our understanding that we are at the “Email ICANN CSC – Confirm Tests Completed” stage of the process as outlined in IBM’s TMCH swim lane diagram (pdf).
The next action in the process is ICANN’s – “CSC Sends Request to Registry Services for Actual Sunrise and Claims Start/End Dates”. Our understanding is that the reference to Registry Services is the Registry Services department of ICANN. The CSC will not be able to complete the next action “CSC Updates Existing Line in .csv File with Actual S&C Start/End Dates” until the Registry Operator submits its notice to ICANN (after it is delegated).
Can you please confirm there is no formal step where ICANN (or IBM) provides the Registry Operator with a “pass” certificate or other formal confirmation.
Issue 2
Section 2.1.1 of the RPM Requirements Document (pdf) states that the Registry Operator must provide TLD Startup Information to ICANN and the TMCH Sunrise and Claims Operator. However, section 2.1.2 states that such information must be submitted through the customer service portal.
Can you confirm that submission of the TLD Startup Information through the portal serves to satisfy the requirement to provide TLD Startup Information to ICANN and the TMCH Sunrise and Claims Operator as specified in Section 2.1.1?
Issue 3
Section 2.1.1.1 states that the TLD Startup Information needs to include confirmation that the registry operator has completed testing.
Does this confirmation need to be in a specific form?
Will an email from IBM suffice? If so, who must the email be from i.e. project manager and what must it state specifically?
Issue 4
Section 2.1.1.2 states that the TLD Startup Information needs to include confirmation that the TMCH Sunrise and Claims Operator has accepted the start and end dates prior to the Registry Operator providing the TLD Startup Information. This step of the process is not described in the Process Document.
Does this confirmation need to be in a specific form?
Does IBM have a SLA with ICANN to ensure such confirmation is provided within a specific timeframe to ensure that a Registry Operator’s ability to submit its TLD Startup Information is not compromised by delays?
Issue 5
For clarity can you incorporate the requirements of section 2.1 of the RPM Requirements Document into the TMDB Registration and Access to Production Platform Process swim lane diagram?
Issue 6
Please outline the process for our back-end registry services provider to gain access to the TMCH production environment. 
If this process involves IBM or other external parties please also provide service level expectations so we can include allowance in scheduling of Sunrise and other launch periods
We will let you know when we get a response.

Thursday 10 October 2013
As regular readers of this journal will know, we have been frustrated by the lack of certainty surrounding the new gTLD program.
Other industries would have picketed the building of the regulator with suitably angry placards being waved and a catchy song. Unfortunately in the domain name industry, angry blogs serve as a replacement to chaining ourselves to Fadi’s swivel chair.
So as a compromise, I ask readers to hum their favourite protest tune while reading our latest tale of woe.
Flippant commentary aside, the document ICANN released on name collisions yesterday (New gTLD Collision Occurrence Management) is a perfect example of what many applicants find challenging about ICANN staff’s use of the public comment process.
Despite the many detailed studies undertaken by a number of applicants and reported through the public comment process, it would appear that many of the recommendations or proposed solutions have been ignored by ICANN staff and the NGPC in favour of something that resembles a ‘dog’s breakfast’.
You’ll recall that ICANN made some suggestions to mitigate the risk of name collisions. There were three categories: High (dead men walking), Uncategorised (deer in headlights) and Low (phew ).
There was going to be a study about something at sometime that would decide stuff and the aforementioned deer would roam free. There was going to be a TLD tasting period during which time registries got to play spammer to unsuspecting ISPs (I wonder if I can get a refund like domain tasters used to, if I don’t get enough traffic?).
A comment period was had and people duly commented. Neither the original suggestions nor the comments seem to have any connection with what appeared in the document we read yesterday. The actions and processes discussed in the document are completely new. Oh, and the Board approved them.
A thought for those in the industry: are we so inured to this kind of procedural disdain that one more example simply doesn’t make us angry anymore?
So what of the document? Is it good for us and the industry? Well there is no low or uncategorised risk grouping anymore. Everyone is in the same bucket of riskiness. Depending on who you are, that might be good for you.
The TLD tasting period, where a TLD was delegated and emails were sent to every poor soul who made the mistake of looking up a non-existing TLD, is gone. That is definitely good. An outreach program with network operators and ISPs seems like an eminently sensible idea. A spam campaign chasing random DNS queries seems like a mad idea.
Now to the grim news – there will be another study (isn’t there always) and another process (if it’s implementation can we just… oh never mind).
The study will tell us which strings from the DITL data set (and other unnamed sets) are risky and why and what we should do with them. Such risk will be contextual to the TLD in question. There’s no detail on how many strings we are talking about. There’s no criteria for the string’s presence in the list (number of queries, type of queries, known risks etc). That sounds like a large chunk of work. No matter how it is automated.
The process to be determined is how the strings and suggested mitigations are delivered to and managed by registries. There’s potentially a lot of future system development and labour costs on the horizon for TLD operators.
Many TLDs will not need to wait for this completed work to delegate. However they must accept from ICANN a list of names they can’t delegate until the process/study and their personalised list of names is completed.
Firstly ICANN has to decide if you can take this option up. How will they do that you ask? I would point you to the very clear decision tree located within the document, only it appears to have been left out. Coming soon.
Second, ICANN has to create and send you the standby extra cautious list. Now we are getting nervous. Just how many names will be on this list? Will there be any filtering or common sense applied? Is the extra cautious list subject to comment? Does it exist already?
There’s also a new process that allows someone who suffers harm from the delegation of a second level domain to have it blocked for a period of up to 2 years. When one thinks through such a process it seems most likely that this harm is only determined after the delegation, not prior. Therefore Registries may be in a position where they need to un-delegate a domain already in use by a registrant.
That could be a rude shock to some innocent registrants. The principle of doing this bothers us. The practical and legal implication of doing this bothers us. And the lack of any detail around how this process is managed, most definitely bothers us.
Whenever I hear process and study I also hear delay. In fact the modus operandi of those opposing the gTLD program has not been to fight it, but to suggest one more study and another process, knowing the effect such activities will have.
So here we are, certain in our uncertainty that one day – soon or not so soon – we will be delegated.
We can’t be the only ones who have internal jokes about the randomness of ICANN policy development. They help us make light of the otherwise business crippling proclamations we receive with no warning.
Don’t you wish, just for once, those jokes weren’t so true?

Tuesday 8 October 2013
We are pleased to report that IBM notified us on Friday 4 October that TMDB testing is complete. The exact wording of the email is:
“I confirm that all tests are ok and have asked to forward your certification request to ICANN.”
We understand that IBM will now send an email notifying ICANN of successful test completion. The process moving forward isn’t entirely clear and we’re hoping to get some answers from ICANN. In the meantime we continue to wait for the delegation process to commence.
We have not had any ‘next step’ communication from ICANN since PDT was completed on 24 August. Further, we have still not received the Welcome Pack, nor have we received the Media Kit.

Thursday 3 October 2013
At a time when ICANN has hit the ‘pause’ button on the new gTLD program in order to assess the impact of “name collisions” on the security and stability of the DNS, we were surprised to see the ICANN Board approve the delegation of ایران., the IDN ccTLD for the Islamic Republic of Iran. While we understand the many distinctions between a ccTLD and a gTLD, the DNS does not make any such distinction.
As we’ve heard from Paul Mockapetris and John Crain recently in their interviews posted on the ICANN website, name collisions (or, more accurately, NX Domain responses) is not a new phenomenon; they have been evident with the introduction of any TLD and with existing TLDs in the root. Experience has shown that steps have been taken to successfully resolve the issues. We understand that ICANN is concerned that the use of NX Domain responses has the potential to create confusion with the introduction of new TLDs into the DNS.
As a contracted party with ICANN, شبكة. (an IDN gTLD) is unable to be delegated as we wait the outcomes of ICANN’s deliberations on name collisions. We have paid our $185,000 application fee, we have undertaken a very resource intensive exercise to ensure a compliant application, we have passed Initial Evaluation, we have signed a registry agreement with ICANN, we have passed pre-delegation testing and yet we sit and wait.
Our understanding of the IDN ccTLD fast track process is that it is much less rigorous, the application fee is voluntary, there is no requirement to enter into a contract with ICANN, the TLD can develop a launch strategy that is not restricted by ICANN mandated rights protection mechanisms, and any contribution to ICANN’s budget is voluntary. But because this is a ccTLD and not a new gTLD, the Board has seen fit to approve this delegation request at this time despite the serious conversation going on in the community about name collisions.
As we said previously, the DNS does not distinguish between a ccTLD or a gTLD, or for that matter an IDN ccTLD or an IDN gTLD. We would appreciate an explanation as to why we sit and wait for delegation while the IDN ccTLD is approved.

Tuesday 24 September 2013
We are trying to determine the best process to finalise a Registry Registrar Agreement (RRA) that is satisfactory to both dotShabaka Registry and our registrars.
According to our agreement with ICANN, we must use a uniform non-discriminatory RRA with all registrars. This makes it challenging in the new gTLD landscape; we have to get it right the first time or we face being bogged down in a clunky amendment procedure.
This is not an easy concept to implement, but dotShabaka Registry and other early launchers must address this soon. It seems there are at least four ways dotShabaka Registry could do this:
1. Wait for ICANN to develop a boilerplate RRA that incorporates the various new gTLD requirements.
2. Negotiate an agreement with the biggest registrar/s and expect that all other registrars will be happy with the result.
3. Put an Agreement out for public comment and request that the Registrars come together with a consensus view.
4. Wait for the Registrar community to generate an agreement for Registries to use.
We don’t expect ICANN’s Automated Registrar Onboarding System (AROS) to be ready for the launch of our TLD.
We would love to hear your thoughts here. Can you think of another pathway to finalise a RRA for the first new gTLDs launched?