Names Council Vote on 4 Resolutions |
DNSO Secretariat
19 September 2002
Re: b12
Results to be published no later than 16 October 2002.
BEGIN:b12:KabcdZ:First_Last:email@some.where:SVP-reply b12:KabcdZ:[ ] I agree on the resolution (1) b12:KabcdZ:[ ] I disagree on the resolution (1) b12:KabcdZ:[ ] I abstain on the resolution (1) b12:KabcdZ:[ ] I agree on the resolution (2) b12:KabcdZ:[ ] I disagree on the resolution (2) b12:KabcdZ:[ ] I abstain on the resolution (2) b12:KabcdZ:[ ] I agree on the resolution (3) b12:KabcdZ:[ ] I disagree on the resolution (3) b12:KabcdZ:[ ] I abstain on the resolution (3) b12:KabcdZ:[ ] I agree on the resolution (4) b12:KabcdZ:[ ] I disagree on the resolution (4) b12:KabcdZ:[ ] I abstain on the resolution (4) END__:b12:KabcdZ:First_Last:email@some.where:SVP-replyThe description of the four resolutions can be found below :
Resolution 1 ============ Proposed by Philip Sheppard on 13 September 2002 Amended on 27 September 2002 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-02s ep02.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. A further review may also be neccesary should new constituencies be created. Resolution 2 ============ Proposed by Philip Sheppard on 13 September 2002 Amended on 27 September 2002 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-02s ep02.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, The NC therefore resolves that: any variation from the principle of equal stakeholder constituency representation and votes in the proposed GNSO council is unacceptable. Resolution 3 ============ Proposed by Elisabeth Porteneuve on 13 September 2002 Amended on 1 October 2002 Whereas the ccTLD Managers have been seeking an efficient process for updating the IANA database 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." Whereas the ccTLD IANA Service Requirements have 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 Whereas the global interoperability and stability of Internet depends on the TLD name servers, 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, Whereas there has been excessive delays in updating nameserver information resulting from disagreements between ICANN staff performing IANA function and ccTLD Managers over the procedures to be followed at the time of nameserver updates. The Names Council resolves: That ICANN promptly process the backlog of nameserver change requests in the root zone and make the appropriate recommendations to the United States Department of Commerce (which must approve changes to the root zone), subject to external checks to verify that the name servers are authoritative for the appropriate ccTLD. The Names Council also recommends that the ccTLD Managers and the ICANN Committee for Security and Stability (http://www.icann.org/committees/security/), with input from the ICANN staff performing the IANA function, jointly develop procedures at the interface between the IANA function and the ccTLD Managers that improve the quality of DNS data at the top level of the DNS. Resolution 4 ============ Proposed by Bruce Tonkin on 27 September 2002 as a response to the Stuart Lynn letter Amended on 1 October 2002 Whereas the stability of the DNS depends on the quality of the nameserver information contained in the zones at all levels of the DNS hierarchy. 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 ask the Committee on Security and Stability (http://www.icann.org/committees/security/) to develop a recommendation on the most sound technical practices to follow to improve the DNS data quality at all levels in the system, http://www.icann.org/correspondence/cerf-lynn-letter-to-names-council-20sep0 2.htm Whereas the responsibility of the DNS data quality is a shared responsibility, which comes in addition to the core IANA function, and methods to improve the DNS data quality need to consider the increased cost on Registries and Registrars and Registrants altogether, in the TLD space. The Names Council resolves that: The ICANN Board should ask the Committee on Security and Stability to work cooperatively with the ICANN staff responsible for performing the IANA function, the TLD managers, and registrars, to develop a recommendation on the most sound technical practices to follow to improve the DNS data quality at all levels of the DNS hierarchy.
| Information from: |
© DNSO Secretariat |