1. Supplemental Notes

2. Best Practice Suggestions

1. SUPPLEMENTAL NOTES

10 January 2012

1.2 IDN tables should be submitted in a machine-readable format suitable for ICANN or another party to read them programmatically. A format such as the model format described in Section 5 of RFC 4290 would be ideal. The format used by RFC 3743 is an acceptable alternative. For variant generation algorithms that are more complex (such as those with contextual rules) and cannot be expressed using these table formats, it should be specified in a manner that could be re-implemented programmatically by ICANN. Ideally, for any complex table formats, a reference code implementation should be provided in conjunction with a description of the generation rules.

15 November 2011

1.1 IDNs are an optional service at time of launch. Applicants who respond to this question with plans for implementation of IDNs at time of launch will be scored according to the criteria indicated in the Applicant Guidebook. Applicants applying for an IDN should make sure to cover the following topics:

• Describe how U-label validation and Punycode conversion will be handled


• Describe how registry systems (database, SRS, whois, etc.) will support the required character encoding(s)


• Describe any EPP extensions utilized in support of the IDN in Question 25

2. BEST PRACTICE SUGGESTIONS:

15 November 2011

2.1 Applicants should read each evaluation question in its entirety, including the notes, criteria, and scoring text. The answer should address all criteria specified, and include detailed rationale demonstrating a thorough understanding of the criteria (i.e., show your work).

2.2 If acronyms are used, applicants should spell out the first instance, even if the acronyms represent a common term/product/service.

2.3 Applicants proposing to outsource a function or functions of their registry operations must address all criteria specified in each relevant question, and include detailed rationale demonstrating a thorough understanding of the criteria (i.e., show your work).

2.4 Simply providing a Curriculum Vitae (CVs/resume) will not be considered as demonstrating technical/operational capabilities nor does it necessarily establish “proof” that resources are on hand. The applicant should provide a detailed explanation of the resourcing plan and should including areas such as the resources required to manage/run a function, the skillset required, the hiring schedule, and so on. CVs may be used to augment this proposed resourcing plan.

2.5 If a policy/procedure is referenced in an answer, applicants should provide a summary of such policy/procedure. Applicants should not attach copies of the referenced policy/procedure, unless specifically requested.

2.6 If the applicant proposes custom developed software, the applicant should clarify the scope and the extent of the customization including the software development process. This clarification is meant to help evaluation panels understand the integrity of the customized software.

DISCLAIMER: This material is for information only and does not represent of all requirements and criteria that the applicant must satisfy. ICANN is not providing legal, financial, business or any other kind of advice. This material does not represent a modification to the Applicant Guidebook, or the terms and conditions to the new gTLD program. This material also does not represent a waiver of any ICANN policy, procedure or agreement. In the event that any information provided in this material appears to be inconsistent with any information published elsewhere by ICANN, please do not rely on this material without confirmation or clarification from ICANN.