ICANN’s contract with the USA Expires.

https://www.icann.org/news/blog/cheers-to-the-multistakeholder-community

So it has been done and we are on our way. Years of discussions come to an end? Not likely but we have a significant milestone here.

The ICANN board is more accountable now and can be replaced.

The GAC aka governments can no longer take over the interwebz.

The USA demonstrated to the world that it takes the multi-stakeholder model serious and as such it is out of the grasp of the UN or the ITU. Imagine the UN run the internet 😉 Ted Cruz and some other idiots who demonstrated clearly

Ted Cruz and some other idiots who demonstrated clearly that they have no idea how the internet runs can pack it in. The internet will keep on working as it is. Beside ICANN only has a clerical function when it comes to the internet and is not the content policy or has any mandate when it comes to content. ICANN can only create policies through the stakeholder model wich is a bottom-up process and not a top-down process.

Theo Geurts ICANN community member.

Thick WHOIS Migration Part two, The Draft V5

As I am on a roll this morning lets’ zoom in the Thick WG latest draft and provide it with some early comments and background detail. thick-transition-policy-draft-v5-20160929-clean-with-comment

Redline version in full:

Thick Whois Transition Policy for .COM, .NET and .JOBS

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, and “MAY” in this document are to be interpreted as described in RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt.

Scope:

This Policy SHALL apply to the Registry Operators for the .COM, .NET and .JOBS gTLDs, as well as all Registrars sponsoring domain name registrations in the .COM, .NET and .JOBS gTLDs.

Definitions:

  • Thin (Registration): domain name for which the Registry Operator maintains and provides only technical information (e.g., name servers, statuses, creation date) and the Sponsoring Registrar associated with the domain name. Contact information for these domain names is maintained only by the sponsoring Registrar.
  • Thick (Registration): domain name for which the sponsoring Registrar provides a copy of the associated contact information to the Registry Operator. Registry Operator maintains the technical information (e.g., name servers, statuses, creation date) and the sponsoring Registrar associated with the domain name. Contact information for the domain name is maintained by the sponsoring Registrar.
  • Existing Domain Name: domain name created, or in pendingCreate status, before 1 May 2018.
  • Transition Progress Metrics: metrics created by Registry Operator and communicated regularly to Registrars and ICANN to allow measurement of progress of the transition from Thin to Thick, including at least the total number of domains managed by Registrar, number and percentage of domain with contact objects attached
  1. Effective Dates:
    1. All new domain name registrations MUST be submitted as Thick starting on 1 May 2018 at the latest.
    2. All registration data for Existing Domain Names MUST have been migrated from Thin to Thick by 1 February 2019.
  2. The following requirements apply to Registry Operators only:
    1. Registry Operator MUST deploy an EPP mechanism by 1 August 2017 for registrars to migrate registration data for Existing Domain Names (i.e., the transition from Thin to Thick).
    2. Registry Operator MUST upon request provide an alternative bulk transfer mechanism by 1 February 2018 for registrars to migrate data for Existing Domain Names (i.e., the transition from Thin to Thick). The request MUST be made by 1 August 2017.
    3. By 1 May 2017, Registry Operator MUST provide to applicable Registrars and ICANN, documentation reflecting the system changes necessary to support the requirements of Sections 2.1 concerning relevant Operating Test Environments (OT&E) available to Registrars and by 1 August 2017 for Section 2.2.
    4. Starting 1 August 2017, Registry Operator MUST support all contact commands specified in RFC5733 as described in this provision. The EPP contact fields <contact:id>, <contact:postalInfo>, and <contact:authInfo> will be REQUIRED by the Registry Operator. Registry Operator MUST accept but MUST NOT require all other registration data elements that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.
    5. Starting 1 May 2018, Registry Operator MUST require Thick Registration data for an EPP domain object <create> command as described in this provision. Registry Operator MUST require all registration data elements that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.
    6. Between 1 August 2017 and 1 February 2019, Registry Operator SHALL provide Transition Progress Metrics to each registrar at minimum Monthly by the first day of the next month at 23:59 UTC.
    7. Between 1 August 2017 and 1 February 2019, Registry Operator SHALL provide to ICANN all Transition Progress Metrics for all registrars at minimum Monthly by the first day of the next month at 23:59 UTC.
    8. Registry Operator SHALL implement the requirements of the Registry Registration Data Directory Services Consistent Labeling and Display Policy (“CL&D Policy”) in conjunction with Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) by 1 August 2017.
    9. Starting 1 May 2018, Registry Operator MUST comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy for other than Existing Domain Names.
    10. Between 1 August 2017 and 1 February 2019, for Existing Domain Names, for the following RDDS Output fields where no data exists in the Shared Registration System (SRS), the Registry Operator MAY treat the following RDDS fields as Optional as described in section 1.2 of the “RDAP Operational Profile for gTLD Registries and Registrars” if implementing RDAP, and in the case of Whois port 43 and Web-Whois, as described in clarification 1 of the “Advisory: Clarifications to the Registry Agreement, and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications”:
  • Registry Registrant/Admin/Tech ID
  • Registrant/Admin/Tech Name
  • Registrant/Admin/Tech Street
  • Registrant/Admin/Tech City
  • Registrant/Admin/Tech Country
  • Registrant/Admin/Tech Phone
  • Registrant/Admin/Tech Email
    1. The “Billing” contact is optional.  Registry Policy may define if it is required, optional or not supported.  If supported the Billing contact information must be displayed as described in the “Advisory: Clarifications to the Registry Agreement, and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications” (section 22).
  1. The following requirements apply to Registrars only:
    1. Between 1 August 2017 and 1 February 2019, Registrars MUST migrate to the relevant Registry Operator all required fields of Existing Domain Names that are available in the Registrar database that enable the Registry Operator to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.
    2. Registrars MAY provide complete Thick Registration data to Registry Operator that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy, upon creation of new domain name registrations starting 1 August 2017.
    3. Registrars MUST provide complete Thick Registration data to Registry Operator that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy, upon creation of new domain name registrations starting 1 May 2018.

Implementation Notes

  1. Where a conflict exists between local privacy laws and requirements included in this Policy, ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Laws is available for Registry Operators and Registrars

 

Theo Geurts ICANN IRT member

Completely and totally not related music video but still one helluva song.

Thick Whois Migration Verisign

I have been at the IRT for the Thick WHOIS Verisign Migration for some time now (early NOV 2015).

All was well, till we received a draft from Verisign that there might be some issues. This memo wich has been prepared for the GNSO highlights some potential issues.

I’ll publish it in full:

DRAFT

To: GNSO Council

From Thick Whois IRT

Date: xx August 2016

Re: Notice of Unanticipated Thick Whois Privacy Issues

In accordance with Recommendation #3 of the GNSO Council Consensus Policy Recommendations on Thick Whois adopted by the ICANN Board on 7 February 2014 (the “Thick Whois Policy”), the Thick Whois Implementation Review Team (“IRT”) is hereby providing notice to the GNSO Council that privacy issues have emerged from the thin to thick data transition discussions that were not anticipated by the August 29, 2013 Expert Working Group Memo (the “EWG Memo”) and that appear to require additional policy consideration by the GNSO Council so that appropriate action can be taken as the Thick Whois Policy implementation process continues to move forward.

Specifically, and as outlined in more detail below, the recent invalidation of the US-EU Safe Harbor Program and the adoption of the new EU-US “Privacy Shield” framework, the adoption of the General Data Protection Regulation (“GDPR”) in the European Union (“EU”) and the ongoing legal challenges and scrutiny regarding transfers of personal data to the US from the EU have resulted in significant uncertainty regarding data privacy requirements associated with the collection, storage, transmission and display of personally identifiable information (PII), specifically thick Whois data, that should be addressed as the implementation of the Thick Whois Policy moves forward.

Recommendation #3 of the Thick Whois Policy states:

As part of the implementation process a legal review of law applicable to the transition of data from a thin to thick model that has not already been considered in the Expert Working Group (EWG) memo is undertaken and due consideration is given to potential privacy issues that may arise from the discussions on the transition from thin to thick Whois, including, for example, guidance on how the long-standing contractual requirement that registrars give notice to, and obtain consent, from each registrant for uses of any personally identifiable data submitted by the registrant should apply to registrations involved in the transition. Should any privacy issues emerge from these transition discussions that were not anticipated by the WG and which would require additional policy consideration, the Implementation Review Team is expected to notify the GNSO Council of these so that appropriate action can be taken.

As required by Recommendation #3, ICANN staff conducted a legal review of law applicable to the transition of data from a thin to thick model and communicated the results of this review to the IRT in a Legal Review Memorandum dated 8 June 2015 (the “Legal Review Memo”). The Legal Review Memo focused its analysis on a survey of data protection laws within the EU and based on that analysis advised the IRT that “there are some important and legitimate questions relating to data protection obligations under local law that must be addressed” as a part of the Thick Whois Policy implementation. The Legal Review Memo further advised the IRT that the legal requirements regarding the disclosure and transfer of personal data to the relevant registries “trigger particular attention” in relation to the implementation of the Thick Whois Policy. (p. 6)

In the short period since the Legal Review Memo was provided to the IRT highlighting the importance of addressing the law in the EU regarding the disclosure and transfer of personal data as a part of the transition, that law has entered an unprecedented period of change and uncertainty. The US-EU “Safe Harbor Program”, which previously provided one means by which to lawfully transfer personal data from the EU to the US, was invalidated in October 2015 and the replacement “EU- US Privacy Shield” announced in February 2016 was just recently adopted by the European Commission on 12 July 2016.1

In the wake of the invalidation of the US-EU Safe Harbor Program and the development of the EU-US Privacy Shield, the use of consent to effectuate transfers of personal data, which the Legal Review Memo identified as “likely to be the most expedient way of addressing the transition to thick Whois” (p. 10), has been called into question by regulators in the EU, particularly in the context of large and/or repeated transfers of personal data. Both the Irish and German data protection regulators, for example, have indicated that reliance on consent, standing alone, may be problematic and German regulators have determined that consent is not valid for “massive or routine” transfers of personal data.2

The law in the EU regarding personal data protection, in general, has also entered a state of uncertainty and change since the EWG considered the privacy issues associated with the transition, as the new GDPR was adopted on May 4, 2016, and will go into effect on May 25, 2018.3

The GDPR establishes a substantially more restrictive compliance landscape regarding the consent-based processing of personal data. For instance, the European Commission’s fact sheet on the GDPR notes that consent “will have to be given by means of a clear affirmative action before a company can process your personal data.”4 The new GDPR may, therefore, have a significant impact on the Thick Whois transition when it comes into force, particularly with regard to reliance on registrant consent for effectuating the transition.

The IRT believes that the invalidation of the US-EU Safe Harbor Program, the development of the EU-US Privacy Shield, the adoption of the new GDPR by the European Commission and decisions by regulators raise new privacy issues not anticipated by the EWG that require additional policy consideration by the GNSO Council, particularly with respect to the potential use of registrant consent to effectuate the Thick Whois transition. Moreover, as Legal Review Memo recognized, EU data protection laws “embody international principles which serve as a basis for many data protection laws around the world.” (p. 3) In addition to the uncertainty caused by changes in EU laws, members of the IRT are also aware of other jurisdictions which have, or are in the process of, enacting regulations with a potential direct impact on thick Whois policies and procedures, such as laws that require personal data to be hosted locally within a particular jurisdiction. The proliferation of these laws and applicability to the collection, storage, transmission and display of personal data should be a consideration for all gTLD registries and registrars, and in particular for the transition of gTLDs from a thin to thick Whois model.

1 See European Commission Press Release, “European Commission launches EU-U.S. Privacy Shield: stronger protection for transatlantic data flows” (available at http://europa.eu/rapid/press-release_IP-16-2461_en.htm).

2 See Data Protection Commissioner of Ireland, “Transfer Abroad” Guidance (available at https://www.dataprotection.ie/docs/Transfers-Abroad/y/37.htm); Conference of the Data Protection Commissioners of the German Federation and the German States, DSK Position Paper on Safe Harbor Invalidation (available at https://www.datenschutz.hessen.de/ft-europa.htm#entry4521).

3 See European Commission, “Reform of EU data protection rules” (available at http://ec.europa.eu/justice/data-protection/reform/index_en.htm).

4 See European Commission Factsheet, “How does the data protection reform strengthen citizens’ rights?” (available at http://ec.europa.eu/justice/data-protection/reform/index_en.htm)

My problem here? Well as an EU Registrar we never cared much about Safe Harbor. After all, we never sent any personal data to Verisign to register .com or .net domain names. So safe harbor was never on our radar, least not on mine. Now it does and a lot of our business depend on having a reliable process. Privacy Shield is the follow up for the invalidated Safe Harbor. Lawyers in Europe tell me that Privacy Shield will not last long, couple a years max.

So yes, I am sorta paralyzed on what to do here. We got a lot of business riding on this for sure and it looks like we are moving into uncertain waters. On the flip side, the current system is not great also. It won’t be long till some EU privacy regulator comes knocking on our door when it comes to our WHOIS server and the data being published there.

Are we going to buy some time by shifting the legal burden to Verisign or in the long run we have created a single point of failure and we discover in time that the system has failed? I have no idea.

Theo Geurts

ICANN IRT Member

Business trips, firing on all cylinders.

Usually, I take a plane to go to ICANN meetings or go to a business meeting.

Then there is also the car. This meeting, 800 kilometers, in Germany.
We (me and some company folks) did the trip in 6 hours beating a plane when it came to total travel time.

How? 243.

Volvo V60 hybrid max top speed.

Volvo V60 hybrid max top speed.

I do not recommend this unless you have a professional driver at the wheel during day time. Having a pro driver who is able to anticipate behaviour miles ahead makes all the difference. I mean you are in the left lane doing 240.

Then some dork takes over a truck while doing 100km an hour.

YES… I DO love the Volvo breaking system!!!!!

ICANN wants to destroy privacy protect services for domain names.

Privacy for Business

Privacy for Business (Photo credit: Wikipedia)

And that could be read many times, on tons of websites.

The truth is/was that the workgroup (I am a member of the PPSAI WG) is divided. So a few folks wanted a footnote that said commercial websites could not use P/P services and another group wanted a footnote in the report they opposed to that idea.

All good and fine till social media spun it their way. And now we got over 14k comments to look at. Since most of them where submitted came from SaveDomainPrivacy.org the comments are generic.

Still we got tons of good comments and will keep us busy.

The report can be read here : https://www.icann.org/public-comments/ppsai-initial-2015-05-05-en

Funny how things went out of control. I am pretty sure we gonna have a hard time when this needs drafting. Currently I am working on IRTP C, change of control and it has proven to be a nightmare.

 

Testaments Dark Roots of Earth shares

So earlier this month i bought a share for Testaments album Dark Roots of Earth. As a fan i liked the album and the whole package deal for 100 bucks was pretty cheap.

The package includes (well actually it is sold out) :

  • Limited ownership of the album “Dark Roots of Earth”
    Early access to the new Testament album coming in 2015
    Invitation to join Chuck and Eric for an online shareholder meeting
    Print of Chuck Billy’s handwritten “Native Blood” lyrics
    Autographed limited edition certificate of ownership.
    Hand-numbered (of 200) 18″ x 24″ print of Brian Mercer’s “Native Blood” artwork

So today i received the box with the share and i am rather happy about it, looking forward to that shareholder meeting, wonder what that is going to be about 🙂

The shares itself does not hold a commercial value in the sense that you own any rights to claim any money or anything. But fan wise it holds value, like signed albums or cd’s and t-shirts from bands. The native blood art work will be on my wall at some point (got number 59).

Below is the certificate, 59 out of 100, looking forward to the early access album from Testament, hope it is another killer album, like native blood 😉

tg-jpg

 

 

Comment on the Transition NTIA’s Stewardship of the IANA Functions to ICANN

So ICANN wanted comments, we gave them one. While  this was being drafted, Javier Rodriguez released a very intresting read, called 2050: The Internet Odyssey – How We Lost It and a Way to Get It Back. Intresting read right ? Are we at the crossroads ? Looks like it, however it seems we got the message, yet tons of work ahead.  Guess i better get a few more wifi routers 😉 Cya folks at ICANN 50 ! Ping me if you want to meet.

Anyways here is our statement, signed by yours truly.

Late edit, I forgot to mention where one can find the comment url.

http://mm.icann.org/pipermail/ianatransition/2014/date.html

Comments on the Call for Public Input: Draft Proposal, Based on Initial

Community Feedback, of the Principles and Mechanisms and the Process to
Develop a Proposal to Transition NTIA’s Stewardship of the IANA Functions

Date: 8 May 2014

Public Comment URL:
http://www.icann.org/en/about/agreements/iana/transition/draft-proposal-
08apr14-en.htm

The undersigned registrars (“Registrars”), some of whom may also present
individual comments, respectfully submit the attached comments on the Proposal
for the Call for Public Input: Draft Proposal, Based on Initial Community
Feedback, of the Principles and Mechanisms and the Process to Develop a
Proposal to Transition NTIA’s Stewardship of the IANA Functions

We thank the IANA Team for preparing this proposal.

The Registrar Stakeholder Group is currently reviewing this issue and discussing
the ways in which it may impact the global registrar community. We do, however,
have initial comments on specific points that have arisen as a result of the Call
for Public Input.

Several members of the Registrar Stakeholder Group believe that having two
Steering Group representatives for the GNSO will not be sufficient in ensuring
that the interests of all GNSO stakeholders are properly reflected. As the GNSO
is the largest and most diverse structure within ICANN, we find that a “one size
fits all” approach to delegation is not appropriate. Instead, we propose that each
SO/AC submit a number of representatives that it believes to be sufficiently
representative, but be encouraged to keep the number as small as possible.

With regard to the selection process, we recommend that delegates to The
Steering Group should not be selected, chosen or screened by ICANN Staff, as
we have seen recently with Expert Working Groups and Strategy Panels.

We propose that to ensure the most effective process, The ICANN Staff avoid
top-down engagement with the Steering Group. The Steering Group’s legitimacy
with Registrars and other stakeholders will depend upon its ability to choose its
own path forward (with public input) and need not accept the staff-produced
blueprint for developing a transition proposal. Ideally, the role of ICANN Staff
(particularly Executive Staff) would be limited to supporting this effort.

The Registrar Stakeholder Group would like to note that currently, there are three
issues are intertwined with this effort that must be considered dependent, or even prerequisite, issues:

First, the effort to review/improve Accountability Mechanisms must complete
before any transition can occur. There is a general belief that existing
mechanisms are ineffectual.

Second, we need to understand the technical & operational impacts of this
change. Recent events (CZDS outage, TAS “glitch”, etc.) clearly indicate that
ICANN is not up to the task of operating the Root Zone Maintainer function. Will
VeriSign retain this role? If not, who will fill it?

Third, the role of governments is an essential component of the NTIA plan,
however this presumes that the GAC’s structure and operation will be similar to
how it exists today. The transition proposal should ensure that any potential
structural changes by the GAC or other third-parties would not negatively impact
NTIA’s requirement that IANA control must not transition to a government or
inter-governmental organization.

We respectfully request that the above issues be taken into consideration before
a proposal to transition is completed.

Thank you,

Thomas Barrett, EnCirca
John Berryhill, Uniregistry
James Bladel, GoDaddy
Robert Birkner, 1API
Graeme Bunton, Tucows
Jeffrey Eckhaus, eNom
Theo Geurts, Realtime Register
Rob Golding, Astutium
Frédéric Guillemaut, Mailclub
Rob Hall, Momentous
Thomas Keller, 1&1 Internet
Louise Lentino, Instra Corporation
Michele Neylon, Blacknight
Chris Pelling, NetEarth One
Benny Samuelsen, Nordreg AB
Luc Seufer, EuroDNS
Dr. Michael Shohat, Cronon AG
Bruce Tonkin, Melbourne IT
Bob Wiegand, Web.com

Data & Metrics for Policy Making Drafting Team

Last year i joined my first ICANN workgroup, well drafting team to be more precise. Being it

ICANN 44 Wednesday  27th June Prague GNSO Council

ICANN 44 Wednesday 27th June Prague GNSO Council (Photo credit: icannphotos)

my first i must say it was intresting and engaging. The charter for the DMPM was approved by the board.

The 2010 Registration Abuse Policies Working Group (RAPWG) identified the Meta Issue: Uniformity of Reporting which it described as “need for more uniformity in the mechanisms to initiate, track, and analyze policy-violation reports.” The RAPWG recommended in its Final Report that “the GNSO and the larger ICANN community in general, create and support uniform problem-reporting and report-tracking processes.”

 

The GNSO Council recommended the creation of an Issue Report to further research metrics and reporting needs in hopes to improve the policy development process. The report created by ICANN Staff outlined accomplishments regarding reporting and metrics by the Contractual Compliance function and it also reviewed other reporting sources that may be of relevance. The GNSO Council subsequently adopted the recommendation to form this non-PDP Working Group tasked with exploring opportunities for developing reporting and metrics processes and/or appropriate standardized methodologies that could better inform fact-based policy development and decision making.

It’s going to be intresting to see what the workgroup will do with it.  They are currently seeking volunteers, i thought about joining it but the current ICANN workgroup i am currently involved in consumes alot of time not to mention that the RAA 2013 implementation is time consuming also, coupled with the fact that Nominet decided to come up with a new RA also.

Request for volunteers :

http://www.icann.org/en/news/announcements/announcement-21feb14-en.htm

 

Full information and charter that was created after some intresting discussions is available here : http://gnso.icann.org/en/issues/dmpm-charter-23jan14-en.pdf

 

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

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 on 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 generally welcome the concept of a TLD operated by a brand owner for their own 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 of 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. In order 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