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.