FINAL VERSION TO BE SUBMITTED IF RATIFIED
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
FIRST DRAFT SUBMITTED
The first draft submitted will be placed here before the call for comments begins.
Please reference the "Work Track 2 Questions" document above for detailed questions asked
Summary of ALAC Responses to Work Track 2 Questions
The ALAC largely supports proposals made under Track 2. The ALAC supports the continued use of one Registry Agreement for all applicants, with exceptions for applicants only as necessary. This should ensure that, as much as possible, there is a level playing field for applicants, as well as easier understanding of the requirements that all new GTLD operators must meet. We also support that, again as much as possible, all relevant sections of the application are incorporated into the Registry Agreement. This should make any commitments made by applicants enforceable by ICANN under the Registry Agreement.
The Applicant Guidebook also has various restrictions on the use of Reserved Names, ineligible strings, two-character ISO 3166 codes and geographic names. The Guidebook should include all of those and any subsequent restrictions on names and/of strings that are clearly spelled out for all applicants.
| Work Track 2 Question # | Comment from Holly Raiche |
|---|---|
| 2.1 Base Registry Agreement | |
2.1.1 Single Registry Agreement with exemptions for different TLD categories or different agreements | Support a single registry agreement to ensure, as far as possible, consistency of terms across all categories of TLDs |
2.1.2 Further restrictions on sunrise periods or other activities | |
2.1.3 Inclusion of entire application into a signed Registry Agreement. If so, how to manage minor changes or community opportunity to comment | Agree all relevant aspects of application should be taken to be incorporated into the Registry Agreement. This would ensure that what a proposed RO has undertaken to do is part of the agreement. Any changes should be the subject of notice with an opportunity for public comment |
| 2.2 Reserved Names | |
2.2.1 Changes required to String Requirements as defined in 2.2.1.3.2 of Guidebook? | I am not aware of any changes we have sought – check with Edmon on IDNs |
2.2.2 Changes required to Reserved Names list at 2.2.1.2.1 | I am not aware of any changes we have sought |
2.2.3 Add special Use Domain Names to Applicant Guidebook | Yes – to prevent applicants from applying for reserved names |
2.2.4 Change Spec 5 of Registry Agreement which allows Registry Operator reserving up to 100 names at 2nd level for operation/use of TLD? | We do not expect Spec 5 to change as it seems to be sufficient as is. |
| 2.3 Registrant Protections | |
2.3.1 Should there be exemptions from registrant protection programs (emergency back-end RO, Continued Operations Instrument and data Escrow requirements, performance specs) and do they work? What changes if there is an RSP program (clause 1.1.1) | Current protections should remain. On possible development of an RSP program, our response to the proposal is that while ALAC does not see any benefits from the further expansion of new gTLDs into the domain system, benefits could be achieved by the proposed programme to develop and enhance the technical and knowledge capacity of RSPs, especially for underdeveloped economies |
2.3.2 Other funding models for EBERO providers | |
2.3.3 Proposed changes to background screenings of applicant registries? Should previous breach(es) by ROs be grounds for rejection? And performed when: time of application or just before signing or both | No suggested changes. On timing for screening, should be both at he time of application (to immediately weed out unsuitable applicants) and at time of contract signing (to ensure there have not been material changes in the applicant |
| 2.4 Closed Generics | |
2.4.1 Enforcement of rule against having generics closed to only one RO | Yes. Permitting closed generics could impact both on consumer choice and consumer confusion. |
2.4.2 Any change to the definition on ‘generic’ and if the ban on closed generics is maintained, should there be exemptions | No, the definition is clear and the ban should be maintained |
| 2.5 Applicant Terms and Conditions | |
2.5.1 Right of ICANN to reject any application? Should it be articulated | Yes, ICANN should have that right, and it should be clearly spelled out in the Applicant Guidebook and in an ICANN policy |
2.5.2 T&C includes a ‘covenant not to sue ICANN’ except through accountability mechanisms. | Appeals mechanism (in 3.5.2 we have not answered) Suggestion – if appeals allowed, should only be when de3cision is based on an error of fact that ICANN had available to it at the time. |
2.5.3 Ability of ICANN to change Applicant Guidebook | Agree after the application procedure has been initiated, Guidebook should not be changed |
2.5.4 Changes needed to Module 6 of AG? | ??These are contract terms – and I don’t think ALAC wants to be providing legal advice |
| 2.6 Registrar Non Discrimination & Registry / Registrar Separation | |
2.6.1 Issues with vertically integrated registries? | |
2.6.2 Apart from exception for vertically integrated registries, any suggested changes to Registry Code of Conduct? | I can’t see any that I would suggest |
2.6.3 In Registry Agreement, while allowing integration, is rule that registry must not discriminate in favour of its registrar - even though causes inefficiencies | Retain non-discrimination rule even if causes inefficiencies |
| 2.7 TLD Rollout | |
2.7.1 Are existing timeframes reasonable (9 months for contract completion and 12 months for delegation | |
| 2.8 Contractual Compliance | |
2.8.1 Assume Contractual Compliance responsible for contract enforcement | Agree with approach |
| 2.9 Global Public Interest | |
2.9.1 Have PICS served their purpose and any other mechanisms to the public interest – explain with documentation | The CCT-RT Draft Report which is supported by the ALAC makes it clear that a significant amount of further information is necessary before it is possible to say that the introduction of new gTLD has increased either consumer trust or consumer choice. The ALAC, therefore, reinforces the CCT-RT Report’s pre-requisite recommendation for more and better data before it is possible to state that the objectives of the program have achieved. At this point, therefore, the ALAC does not support any new round of new gTLDs. Reputation and familiarity, as proxies for trust, have facilitated greater public trust in the legacy gTLDs than new gTLDs, but one factor that could contribute to trust was that certain restrictions be placed on who can become a registrant and on how the new name is used. ALAC statement: AL-ALAC-ST-1114-02-00-EN produced on 19 November 2014, provided an expansive ALAC comment on the Public Interest Commitment ALAC Review. "Greatest amongst those concerns are the lack of public oversight, the temporary and arbitrary nature of the “optional” PICs, and an unsure and adversarial enforcement process that created significant obstacles for reporting of breaches." |
