Latest news of the domain name industry

Recent Posts

dotShabaka Diary — Day 14, Writing an RRA

Kevin Murphy, September 24, 2013, 08:29:36 (UTC), Domain Registries

The fourteenth 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 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?

Read previous and future diary entries here.

Tagged:

Comments (9)

  1. tom barrett says:

    There is another option that you don’t mention.

    Get the Registry Stakeholder Group to merge their respective draft RAA’s and publish just one for all Registrars.

    Afilias, Neustar and Verisign have all no doubt already revised their existing RAA’s for the new gTLD’s.

    A common template needs to be driven by the Registries.

  2. Michele says:

    I’d agree with Tom. The registries can lead this and come up with a baseline draft. And then let the RrSG review it.

    Each registry coming up with their own is going to be incredibly messy and slowdown adoption by registrars.

  3. Rubens Kuhl says:

    And the text needs to be expandable enough to account for new ICANN requirements, like this from URS “technical” requirements:

    4. Registry-­‐Registrar Agreement:
    • The Registry Operator MUST specify in the Registry-­‐Registrar Agreement for the Registry Operator’s TLD that the Registrar MUST accept and process payments for the renewal of a domain name by a URS Complainant in cases where the URS Complainant prevailed.
    • The Registry Operator MUST specify in the Registry-­‐Registrar Agreement for the Registry Operator’s TLD that the Registrar MUST NOT renew a domain name to a URS Complainant who prevailed for longer than one year (if allowed by the maximum validity period of the TLD).

  4. Thanks Rubens – are you aware of any other of these requirements floating around?

    In theory, I see some big advantages to the idea of a standard contract as proposed by Michele and Tom, but there are also some real impediments to it:

    1. It will take forever. I don’t see much appetite for this among our larger competitors, who haven’t even shared their agreements (as we have not), let alone expressed any interest in coming up with a standard one. Add to that the time it will take to negotiate with the registrars, and I see this as at least a six-month process *if* everyone was willing. Some TLDs will be ready to launch well before that, and I don’t see many registries being willing to wait. A standard contract would not be possible without near unanimous consensus among all the parties (registry and registrar), which will be very hard to come by.

    2. It’s an invitation for ICANN to interfere in the one area where their bureaucratic fingers are not already third-knuckle deep. I can foresee calls for ICANN to stage-manage any “standard contract” process, and I there are those among us, M+M included, who think that this is a Bad Idea. Add to that the necessary heavy involvement of ICANN’s legal department, which is already way behind schedule on the contracting process, and you end up with an even longer delay.

    Of the options presented by ARI in this blog post, we lean heavily to coming up with our best contract (after having run it by some friendly registrars first), then asking for comments from the registrar stakeholder group. I think that dialog will be very fruitful, and may go some way to building, if not a standard contract, then at least a common set of assumptions about what should be in a contract.

    While it’s true that there are a lot of applications out there, there are many fewer applicants. The portfolio applicants will have a mostly standard contract from one TLD to another, and those smaller applicants are going to be working from a contract that (I hope) will have been presented to them by their Registry Service Provider. Hopefully that dynamic will help minimize the confusion.

    I’m open to any good ideas, but I fear that the idea of a standard contract may be a non-starter. The dialog, however, is very useful.

    Antony

    • Rubens Kuhl says:

      So far the only ones I’m aware are the ones from URS and the one from GAC Advice:
      “2. 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.”

      But considering the broad scope of the current supplement to the contract, anything can still be mandated until the supplement expires, so any RRA signed while the supplement is still valid need to address this possibility as well.

  5. Yasmin Omer says:

    Thank you all for your contributions, this discussion has been helpful in gaining greater clarity on this important issue.

    We’re also keeping a close eye on the discussions in the RySG and RrSG mailing lists. Hopefully the community can come to an agreement soon on how to finalise a RRA that favours all parties.

Add Your Comment