[ncdnhc-discuss] Re: NC-vote

[Harold J. Feld]

ncvote at dnso.org wrote:

> Names Council Vote on 3 Resolutions
> DNSO Secretariat
> 1 October 2002
> 
> Re: b12
> 
>    * This vote is on resolutions/motions proposed by members of the Names
>      Council, for the attention of the ICANN Board as decided at the Names
>      Council teleconference:
> 
>         o http://dnso.org/dnso/notes/20020912.NCteleconf-minutes.html
>         o http://www.dnso.org/dnso/mp3/20020926.NCteleconf.mp3
> 
>    * The time for this NC vote is:
> 
>         o Starting Tuesday, 01 October 2002, 12:00 Paris time (11:00 UTC)
>         o Ending Tuesday 15 October 2002, 12:00 Paris time (11:00 UTC)
>           or when all 20 ballots from the NC have been received, whatever
>           occurs first.
> 	
>    You can find text of resolutions below the ballot or at the following URL :
> 	http://www.dnso.org/dnso/notes/20021001.NC-resolutions-vote.html
> 
>    Results to be published no later than 16 October 2002.
> 
> 
> REQUEST: Four motions are submitted for your consideration.
> REQUEST: Please mark your choice, using 'x', for each resolution.
> 
> REQUEST: This ballot is From: 'ncvote at dnso.org' -- please reply without CC to any list.
> IMPORTANT: Please do not strip ballot.
> IMPORTANT: it  MUST start with line BEGIN: (do not edit BEGIN line).
> IMPORTANT: it  MUST end   with line END__: (do not edit END__ line).
> IMPORTANT: and MUST contain all lines in between.
> 
>  BEGIN:b12:Kce27Z:Harold_Feld:hfeld at mediaaccess.org:SVP-reply
>  b12:Kce27Z:[ ] I agree on the resolution (1)
>  b12:Kce27Z:[ ] I disagree on the resolution (1)
>  b12:Kce27Z:[X] I abstain on the resolution (1)
>  b12:Kce27Z:[X] I agree on the resolution (2)
>  b12:Kce27Z:[ ] I disagree on the resolution (2)
>  b12:Kce27Z:[ ] I abstain on the resolution (2)
>  b12:Kce27Z:[X] I agree on the resolution (3)
>  b12:Kce27Z:[ ] I disagree on the resolution (3)
>  b12:Kce27Z:[ ] I abstain on the resolution (3)
>  b12:Kce27Z:[X] I agree on the resolution (4)
>  b12:Kce27Z:[ ] I disagree on the resolution (4)
>  b12:Kce27Z:[ ] I abstain on the resolution (4)
>  END__:b12:Kce27Z:Harold_Feld:hfeld at mediaaccess.org:SVP-reply
> 
>    * Four Resolutions:
> 
> 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.
> 
> 
> 
> ---
> 	DNSO Voting Automaton (Powered by GVS)
> 
> 
>