Comments on the Proposal for a Specification 13 to the ICANN Registry Agreement to Contractually Reflect Certain Limited Aspects of “.Brand” New gTLDs

It’s been rather busy so not many updates lately.

ICANN 45 Toronto

ICANN 45 Toronto (Photo credit: veni markovski)

One I wanted to share is the one below regarding Registry agreements when it comes to the so-called bTLD’s (no I did not make the one up).

The statement is from the Registrar group, and I am one of the folks who signed it since I support the statement.

The statement can be viewed here: http://forum.icann.org/lists/comments-spec13-06dec13/msg00040.html

The statement in text format below:

 

Comments on the Proposal for a Specification 13

To the ICANN Registry Agreement to Contractually Reflect Certain Limited Aspects of “.Brand” New gTLDs

Date: 30th January 2014
Public Comment URL:!http://www.icann.org/en/news/public-comment/spec13-06dec13-en.htm
The undersigned registrars (“Registrars”), some of whom may also present individual comments, respectfully submit the attached comments on the Proposal for Specification 13 to the ICANN Registry Agreement to Contractually Reflect Certain Limited Aspects of “.Brand” New gTLDs and are available to engage with any questions or comments.
We thank the Brand Registry Group (BRG) for preparing this proposal and look forward to future collaborations with this new organization.
Registrars welcome the concept of a TLD operated by a brand owner for their exclusive use and recognize that these TLDs have distinct needs that may differ from those of general use TLDs. However, we cannot support several sections of the draft proposal as currently written, as we believe it creates the potential for abuse in the new gTLD program. Of particular concern are Section 3 and Section 5 of the Specification.
Regarding Section 3, while we do not object to the proposed language and recognize that it may not be appropriate for some TLDs to be re-delegated by ICANN following a termination of the registry agreement, we propose that the TLD operator should be obligated to take steps to notify affected third parties, such as operating system vendors, browser developers, SSL Certificate Authorities, major ISPs, and other relevant industries or organizations.
Our overall concern with the proposed language in Specification 13 is that if this proposal were adopted as written, it could re-introduce the concerns of equal registrar access and undermine the registry-registrar model for domain names. This could give rise to TLDs where the registry, registrar, and registrant (or a subset of those roles) are the same entity, and the beneficial user of the domain name lies with another party.
For example, a broad interpretation of 5.1(ii) and 5.2 would seem to imply that the TLD could offer a limited license to its trademark to unaffiliated parties, and then permit these licensees to register or use domain names in the TLD. These licensees would behave like registrants but without the rights or responsibilities currently provided for under the RAA and ICANN Consensus Policies. For this problem to be addressed in the current proposal, we recommend the phrase “Trademark Licensee, ” and the entirety of Section 5.2 be struck.

 

Finally, we would also like to note that there is a mechanism already in place to request and grant an exemption/waiver from the Registry Operator Code of Conduct (Specification 9). Knowing this, we respectfully request that the BRG outline its specific concerns with the existing process, and articulate why it would fail to provide for the needs of their TLD.
Thank you,

 

Luc Seufer, EuroDNS
James Bladel, GoDaddy
Bob Wiegand, Web.com
Jeff Eckhaus, enom / Name.com
Volker Greimann, Key Systems
Theo Geurts, Realtime Register
Chris Pelling, NetEarthOne
Oliver Hope, HostEurope Group
Rob Golding, Astutium Ltd
Benny Samuelsen, Nordreg AB
Michele Neylon, Blacknight Internet Solutions Ltd

 

Registrar Stakeholder Group (RrSG) Comment on GAC Beijing Communiqué

The GAC has been making some waves with their latest communiqué and it looks their main purpose is either to delay the gTLD program, or they just did an extremely poor job.

Anyways the Registrar group released this comment. And it is one I support.

In addition to this, you might want to read Philip S Corwin take on this. It’s a very very long read but also a very very good read.

ICANN at the Inflection Point: Implications and Effects Of the GAC Beijing Communique

Anyways here are the comments from the Registrar group.

 

 

Registrar Stakeholder Group (RrSG) Comment on GAC Beijing Communiqué
The Registrar Stakeholder Group (RrSG) welcomes the opportunity to comment on the
Governmental Advisory Committee (GAC) Communiqué from the recently concluded meeting in Beijing. We welcome the ICANN board’s decision to open up the advice to
comment, as the scope and breadth of the advice, merits consideration by the widerICANN Community.
Please note that this comment the views of participating RrSG members, but does not
Necessarily represent the views of any given registrar. Member organizations reserve the
individual right to alternative positions, which may change in the future.
gTLD “Safeguards” and “Categories.”
Section 1(b) and Annex I of the Beijing Communiqué details the GAC advice regarding
new operational requirements (“safeguards”) for all new gTLDs, and more stringent
eligibility restrictions and registry requirements for “Sensitive Strings” and “Regulated
Markets.”
For the reasons enumerated below, the RrSG opposes these measures and urges the ICANN Board to reject the GAC advice proposing “safeguards” and “categories.”

(1) The “safeguards” described in 6,7 and 8 (Annex I, p. 10) represent a fundamental change to the New gTLD program. The program was intended for Generic top-level domains, but the “safeguard” effectively converts the listed applications to Sponsored top-level domains (sTLDs). This is counter to the
original purpose and goals of the New gTLD program.
(2) Many (if not all) of the proposed “safeguards” were considered extensively during the development and implementation of the New gTLD program, as well
as negotiations that resulted in the Draft 2013 Registrar Accreditation Agreement (RAA), and several PDP efforts. These proposals were rejected by the ICANN Community due to questions regarding their effectiveness, and their far-reaching
impact on access and use of domain name registrations. The operational impact of implementing the suggested changes would be far reaching and would fundamentally change the relationship between registries, registrars and registrants. We feel that many of the GAC’s concerns are addressed via the
2013 RAA, which is based in no little part on input from the GAC.
(3) Similarly, the concept of gTLD “categories” and category-specific requirements
was extensively discussed and rejected during the deliberations that led to the
Applicant Guidebook, under the terms of which applicants developed their
business plans and submitted their TLD applications(4) Many of the strings identified in Annex I were not included in the “Early
Warnings” published in late 2012, which would have provided applicants an
opportunity to better understand and perhaps address these concerns.
(5) Many of the strings identified in Annex I represent generic terms. While they
may be considered “sensitive” or “regulated” in a single or few jurisdictions, it
is not appropriate to limit or restrict their use in other jurisdictions. Registries
and Registrars are currently, and will continue to be, obligated to comply
with appropriate local law and regulations.
(6) Many of the strings identified in Annex I represent generic terms that may be
considered a profession in some contexts, but not in others. For example,
.vet could mean “veterinarian”, or “veteran.” There are numerous examples
of these types of multiple meanings, and no compelling reason to justify use
of the narrowest possible interpretation.
(7) Many, if not all, of the proposed “safeguards” are related to the content of
websites (or other services) associated with a domain name registration.
This is outside the scope of ICANN’s remit as the organization charged with
the management of the DNS.
(8) Some applicants have indicated that they will employ specific criteria in how
they run their registry if awarded. This voluntary choice of registry policy is
more appropriate than a top-down decision by ICANN at this late stage in the
process

 

Other comments
Additionally, the GAC has noted that it needs more time to consider applications
identified in Section 1(c)(i), and has asked ICANN to place these applications “on hold.”
pending the outcome of Initial Evaluation, until the GAC meets again in Durban (JUL
2013). We would note that this (and any further) delay has the potential for significant
adverse impact on the affected applicants and that the GAC must issue its advice promptly. If the GAC is unable to do so at or before the Durban meeting, we recommend that ICANN allows these applications to proceed.

Conclusions
Governments play an important role in the multi-stakeholder model of Internet
Governance, but the implications of the GAC Beijing Communiqué represents a
fundamental re-write of the New gTLD Program by a single stakeholder at the very end
of a multi-year process.
The mandatory adoption of new “safeguards” and “categories” would have an adverse
impact on the industry, particularly for investors and innovators in the commercial
sector. Non-commercial users would also be affected, as the adoption of “safeguards.” and “categories” could represent prior restraint and significantly impact access and
expression on the Internet. Also, we note that there is nothing particularly novel about
the proposals in Annex I, as they are familiar topics and ideas to veterans of the New
gTLD process. Finally, these changes represent sweeping and fundamental
changes at a this very late phase of the program. We urge the ICANN Board to
reject the GAC advice regarding “safeguards” and “categories.”

ICANN’s WHOIS ACCURACY PROGRAM SPECIFICATION, a closer look.

Dissecting the Registrar Accreditation Agreement 2013 part 1

Now that the RAA 2013 is up for public comments on ICANN’s website I decided to zoom in on some parts of this new agreement.

It’s a been long road, 18 months of negotiations between the domain name Registrars and ICANN is now over. As written many times before on this site, one of the most controversial and debated part of the entire RAA.

What the FBI and other law enforcement agencies wanted

Under ideal circumstances the law enforcement agencies would have loved a domain name registration system, where you as the domain name registrant would have to visit the domain name Registrars office, and after handing over a boatload of documentation you wouldbe on your way home while your domain name Registrar would run several background checks, and perhaps in a month or two your domain name would be registered or perhaps if the background check did not produce enough information. you would have to visit the Registrar again so the Registrar could take some DNA samples CSI style.

What the rest of world wanted

The Registrars and other stake holders didn’t embrace the above vision and wanted less intrusive methods of registrant verification. So after 18 months we have something called :”WHOIS ACCURACY PROGRAM SPECIFICATION”. An end result that did not make the LEA‘s jump for joy.

Let’s zoom in on this verification system and theorise about the implementation and the implications for you as a registrant.

Registrar shall validate:

  • Validate the presence of data for all fields required under Subsection 3.3.1 of the Agreement in a proper format for the applicable country or territory.
  • Validate that all email addresses are in the proper format according to RFC 5322 (or its successors).
  • Validate that telephone numbers are in the proper format according to the ITU-T E.164 notation for international telephone numbers (or its equivalents or successors).
  • Validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they may be updated) or other standard formats.
  • Validate that all postal address fields are consistent across fields (for example: street exists in city, city exists in state/province, city matches postal code) where such information is made available to Registrars.
  • With the above in mind we can conclude that the WHOIS will have less odd elements as we know it today. Telephone numbers will have one and the same format. The last validation bullet (matching data) is one that is very intresting Not all countries use postal codes and that is just for starters.

Registrar shall verify :

  • The email address of the Registered Name Holder (and, if different, the account holder paying for the Registered Name) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar, or
  • The telephone number of the Registered Name Holder (and, if different, the account holder paying for the Registered Name) by either (A) calling or sending an SMS to the Registered Name Holder’s telephone number providing a unique code that must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder’s telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the Registered Name Holder via web, email or postal mail.

What the Registrar has to verify is pretty straight forward, and as you can read no DNA samples require verification to have your domain name registered, just your email address.

Return to sender.

What if the verification does not happen ? A registry like DK Hostmaster has an email verification system in place for many years now. One is an email that contains your login to activate the domain name and if your email is down for some reason you will receive a letter from the registry that also contains your login details. If you do not activate your domain name the domain name will simply not resolve and stays reserved for 30 days and then the registration will be undone.
A simple system, yet 10% of all the registrations fail when it comes to the ccTLD .DK. That is a massive amount of domain names when you would apply such a system for .com or .net. However ICANN has come up with a different solution.

In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the account holder paying for the Registered Name (when that information is different from the Registered Name Holder), Registrar shall verify the applicable contact information manually, but is not required to suspend any registration.

So here we have it and let’s see how that one works in the real world.
Lets assume the Registrar works with a reseller model, the flow would go like this:

Domain name gets registered and an email is send to the registrant and the reseller.
Registrant does the verification and also the Reseller and both have been verified.
Much rejoicement and happy people everywhere.

In the scenario where the registered domain name holder/registrant does not go through the verification process the domain name gets suspended after 15 days. If the reseller does not respond the Registrar will verify the data manually, but the domain names does not get suspended.

More fun.

If the Registrar discovers that the information is incorrect then the Registrar is required to re-verify the data.
Sounds simple, in reallity however this is going to be alot of fun. Registrars currently need to send a so called WDRP email to either the registrant or the admin contact. Currently it is only required to send the email regardless if the email bounces back or not. With this provision if it bounces back or the email does not get delivered the re-verification process kicks in. The ICANN text is as follows :

Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If, within fifteen (15) calendar days after receiving any such information, Registrar does not receive an affirmative response from the customer paying for the Registered Name, if applicable, providing the required verification, Registrar shall verify the applicable contact information manually, but is not required to suspend any registration.

Here it says the Registrar does not have to suspend the domain name. However the next section says :

Upon the occurrence of a Registered Name Holder’s willful provision of inaccurate or unreliable WHOIS information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder’s registration, Registrar shall either terminate or suspend the Registered Name Holder’s Registered Name or place such registration on clientHold and clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder.

Willful, what can be considered willful and not willful ? There is the obvious part where a registrant tells the Registrar to take a hike, and then there is the not so obvious part when you have to deal with a company with multiple departments and decision makers. Needless to say this could use some clarification.

So it is time to get your email addresses up to date, together with your other information and check for yourself if you would pass the verification. Afterall it would be a shame if one or perhaps all of your domain names will get suspended due to a bounced email.

All Registrars who wish to sell all the new gTLD domain names are required to sign the RAA 2013 and i expect the new RAA 2013 to go live within a few months from now if not earlier.

First post and all that.

China's FIRST McDonald's

China’s FIRST McDonald’s

Domain names, the fuel of the internet. I like short and brandable domain names. They are easy to remember and that is actually the purpose of a domain name right ? We have domain names so we don’t have to type in IP addresses like 212.45.84.25.

And TG.NU is short and brandable and unique, residing in a ccTLD space that currently have over 250.000 registrations and very soon 1 million for sure.

Updates will follow shortly as i intend to use this domain name for my personal and business use.

 

.NU is the Internet country code top-level domain (ccTLD) assigned to the island state of Niue. It was one of the first ccTLDs to be marketed to the Internet at large as an alternative to the gTLDs .com, .net, and .org. Playing on the phonetic similarity between nu and new, it was promoted as a “new” TLD in which there was an abundance of good domain names available.
The IUSN Foundation (formerly ‘Internet Users Society – Niue’) administers the TLD in order to provide a number of local services for Niue itself. IUSN funds Internet Niue[2] which provides the island’s internet connection; complimentary PCs and internet connectivity for all residents; and in 2003 established free use WiFi hotspots at various locations throughout the country, claiming to be the “first WiFi nation”.

The .nu domain is particularly popular in Sweden, Denmark, the Netherlands and Belgium, as nu is the word for “now” in Swedish, Danish and Dutch – an example of a domain hack. Partially owing to restrictive domain rules for the ccTLD assigned to Sweden, .se, .nu was used for creative marketing of websites such as www.tv.nu.

At september 2 2012, the Swedish Registry will take over the technical infrastructure for .NU and with renewed marketing effort the Swedish Registry will enlarge the user base for .NU.
The prices will be lower, transfers and domain name ownership changes are free of charge. Premium domain names willbe a thing of the past and no longer cost between 250-500 USD a year. TG.NU is currently considered by the current Registry as a premium domain name.