Skip to main content

IDN ccPDP WG 2 – Draft Final Report

Comment Period Deadlines (*) Important Information Links
Public Comment Box
Open Date: 22 October 2011 To Submit Your Comments (Forum Closed)
Close Date: 15 December 2011 Time (UTC): 23:59 View Comments Submitted
Section I: Description, Explanation, and Purpose

The purpose of the IDN country code policy development process Working Group 2 (IDN ccPDP WG 2) is to report on and identify feasible recommendations for the inclusion of IDN ccTLDs in the ccNSO within the framework of the IDN ccPDP.

To date the WG has identified the following clusters of issues/topic area's:

  1. Membership definition.
  2. Roles of members
    1. Eligibility and selection of Councilors to the ccNSO Council
    2. Initiation of PDP
    3. Voting (Policy development process, selection of Councilors)
  3. Quorum for voting
  4. Scope of PDP as defined in Annex C

Recommendation on membership definition

The WG recommends that the definition in Article IX section 4.1 should be updated to maintain the one-to- one correspondence between the IANA Root Zone Database and membership in the ccNSO.

Recommendation on Eligibility and Nomination of councilors

No changes in Bylaws needed.

Recommendation on initiation of ccPDP

In order to maintain the envisioned balance and taking into account the leading principles, the WG recommends that:

  • All members of the ccNSO should be entitled to call for the creation of an Issue Report;
  • These members need to be from different Territories;
  • The current minimum of 10 members to request the creation of an Issue Report should be maintained.

Recommendation on voting (Council member selection and members vote PDP)

The majority of the WG members is of the view that with the inclusion of IDN ccTLD in the ccNSO the voting in the ccNSO should be based on the principle of one vote per Territory should be applied.

A minority of the WG members is of the view the voting should be based on the principle of one member one vote

Recommendation for one vote per Territory with multiple members

If there are two or more ccTLD managers in a Territory who have become members of the ccNSO, for purposes of voting in the ccNSO an emissary for that Territory has to be appointed by all members from that Territory. It is a matter for the ccNSO members in the Territory how to designate such an emissary.

During the period the emissary has not been appointed, the incumbent member of the ccNSO from that Territory is deemed to vote for that Territory, until such time the ccNSO Council is informed by all members from that Territory of the appointment of an emissary for the Territory.

Recommendation on quorum

Assuming that one vote per Territory is the preferred principle, the current quorum rule could be maintained, albeit the relevant sections in the Bylaws need to be adjusted to reflect this principle.

Recommendation on changes to Annex C (Scope of the ccPDP)

No changes needed to the Annex C of the Bylaws.

At this stage the WG seeks your comments and input on the following:

  • Should alternative solutions be included to resolve an issue identified?
  • Do you support the proposed solution, and why? Would you prefer an alternative solution, and why?

After closure of the public comment period the working group will prepare submit its Final report to the Issue manager to be included in the IDN ccPDP Final Report.

Section II: Background

The purpose of the IDN country code policy development process Working Group 2 (IDN ccPDP WG 2) is to report on and identify feasible recommendations for the inclusion of IDN ccTLDs in the ccNSO within the framework of the IDN ccPDP.

The scope of the IDN ccPDP WG 2 is to focus on, without limitation, examination of Article IX of the ICANN Bylaws and associated Annexes (Annex B and C of the ICANN Bylaws). It shall also take into account the proposals and recommendations of the IDN country code policy development process Working Group 1 (IDN ccPDP WG 1) on the selection and delegation of IDN ccTLDs associated with the territories listed in the ISO 3166-1 (IDN ccTLDs).

As this IDN ccPDP WG 2 undertakes its activities within the framework of the IDN ccPDP, the limitations on the scope of a ccPDP, in particular by Article IX of and Annex C to the Bylaws, applies accordingly.

Section III: Document and Resource Links

Documents posted for comment:

The draft Final Report can be found at the following link: https://ccnso.icann.org/workinggroups/idn-pdp-wg2-draft-final-report-22oct11-en.pdf [PDF, 321 KB]

Additional Resources:

Further information on the IDN country code policy development process Working Group 2 is available at: http://ccnso.icann.org/workinggroups/ipwg2.htm

Section IV: Additional Information
After closure of the public comment period the working group will prepare its Final report and submit it to the Issue manager for inclusion in the IDN ccPDP Final Report.
Staff Contact: Bart Boswinkel Email: bart.boswinkel@icann.org

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."