Names Council Resolutions on ICANN Reform

DNSO Secretariat
26 September 2002

These resolutions/motions has been proposed by members of the Names Council, for the attention of the ICANN Board as decided at the Names Council teleconference:

• http://www.dnso.org/dnso/notes/20020912.NCteleconf-minutes.html
• http://www.dnso.org/dnso/mp3/20020912.NCteleconf.mp3

Resolutions:

1. Proposed NC resolution by Philip Sheppard:
   1. Whereas the ICANN Evolution and Reform Committee (ERC) has published its second implementation report http://www.icann.org/committees/evol-reform/second-implementation-report-02sep02.htm
   2. Whereas the NC has previously commented on the need to make geographic diversity a reality within the proposed Generic Names Supporting Organisation (GNSO) Council.
   3. Whereas the NC has previously commented on the need for constituencies to have sufficient council members to share workload and allow for substitution where required.
   4. Whereas the ERC's supposition that a 21 member council is too big to be efficient is unproven and does not accord with the experience of the Names Council.
   5. Whereas the ERC has acknowledged the above in its proposal to allow three representatives per constituency on the proposed GNSO council for the first year only

   The Names Council resolves that:

   The proposed GNSO council should have three representatives per constituency in perpetuity but that this situation be reviewed 12 months after the formation of the council, so that an intelligent judgement may then be made based on the merits of the competing arguments and 12 months experience.

2. Proposed NC resolution by Philip Sheppard (amended, new whereas 4):
   1. Whereas the ICANN Evolution and Reform Committee (ERC) has published its second implementation report http://www.icann.org/committees/evol-reform/second-implementation-report-02sep02.htm
   2. Whereas the basis for stakeholder representation in ICANN SOs to date has been to give equal votes to each affected stakeholder constituency;
   3. Whereas the report suggests a significant change in the voting balance of ICANN stakeholders to be represented in the new Generic Name Supporting Organisation (GNSO) council whereby it gives twice as many votes to the two stakeholders who have contracts with ICANN (gTLD registries and registrars);
   4. Whereas the 4+4+3 proposed voting structure gives a veto to the contracted suppliers over all ICANN consensus policies, thus negating the balancing role of the three neutral council members;
   5. Whereas the reasoning behind this shift of power is to achieve a balance between contract parties and users;
   6. Whereas such a balance only makes sense once competition in domain name registration is as near perfect as ICANN can reasonably achieve;
   7. Whereas ICANN has not yet achieved full competition in the supply of gTLD registry services;
   8. Whereas there remain problems of competitive restrictive practices in the context of name transfers within the registrar community;

   The Names Council resolves that:

   Any variation from the principle of equal stakeholder constituency representation and votes in the proposed GNSO council is unacceptable.

3. Proposed NC resolution by Elisabeth Porteneuve (amended):
   1. Whereas the ICANN Evolution and Reform Committee (ERC) has published its second implementation report, http://www.icann.org/committees/evol-reform/draft-mission-core-values-02sep02.htm
   2. Whereas the stability of the universal Internet has been part of permanent preoccupations since the White Paper document, http://www.icann.org/general/white-paper-05jun98.htm
   3. Whereas on 28 November 1998, both the USG and the ICANN committed to abide by the principle of Internet stability in the MoU, http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm
   4. Whereas the ccTLD Managers have been seeking an efficient process for updating the IANA database, as previously provided before ICANN took on the stewardship of the IANA function, as explicitly specified in the Amendment 2 to the MoU of 11 September 2000, requesting for "Documentation of IANA procedures for root zone editing, root zone generation, and root zone WHOIS service."
   5. Whereas the ccTLD IANA Service Requirements has been restated once more in Bucharest on 25 June 2002 and approved unanimously by the active ccTLD Managers within the ICANN community http://www.dnso.org/constituency/cctld/ccTLDbucharest-communique.html
   6. Whereas the ICANN principle mission is to "Preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet"
   7. Whereas the global interoperability and stability of Internet depends on the TLD name servers,
   8. Whereas the recent bankruptcy of KPNQwest which provided secondary services to several ccTLD Registries resulted in the need for prompt actions by IANA to update the name servers records as requested by the ccTLD Managers,
   9. Whereas there is widespread dissatisfaction of ccTLD Managers about the deterioration in the performance of the IANA function by ICANN resulting in excessive delays (in some cases over 3 months) in making updates to cctld name server information
   10. Whereas Stuart Lynn and Vint Cerf have written to the Names Council on 21 September seeking the opinion of the Names Council on the suggestion to improve the DNS data quality at all levels in the system http://www.icann.org/correspondence/cerf-lynn-letter-to-names-council-20sep02.htm.

   The Names Council resolves that:

   1. Emergency

      Since June 2002 there is an emergency related to the availability of the ccTLD domain name servers and the preservation of the integrity of the information provided by the servers, and IANA should immediately process the changes in name servers requested by the ccTLDs.

   2. Day to day updates

      ICANN is requested to authenticate name server requests received from the appropriate ccTLD manager as soon as possible after their receipt, to verify the name servers are authoritative for the appropriate ccTLD, and to update the IANA database accordingly, and making the appropriate recommendation to the USG in a expeditious manner.

      Should ICANN determine that any request from a ccTLD manager includes a non-authoritative name server, ICANN is hereby encouraged to refer the disputed request to the independent technical panel formed by the ICANN Security and Stability Advisory Committee and ccTLD Manager's representatives for their opinion in a timely manner.

   3. Improve the overal quality

      In order to improve the quality of DNS and DNS data accuracy on all levels ICANN is hereby encouraged to establish a collaborative work between the ICANN Security and Stability Advisory Committee, the ccTLD Managers and the Regional Internet Registries, which would produce a set of publicly available rules and procedures and tools, for use at every level of DNS, to ensure everybody has the same shared picture of what to do.