August 2003 - council - lists.icann.org

New gTLD "validation" problems...
by Thomas Roessler 14 Aug '03

14 Aug '03

I did a little Google search for e-mail validation tools and tricks, and checked for assumptions on what TLDs look like. (Searches: "email validation javascript", "email valid javascript", "email validation asp", and so on.) Looking at the results, there's an awful lot of sometimes bad, sometimes horrible code (in JavaScript, VBScript, Perl, and friends) and regular expressions around. For a sample dirty dozen, see the link list in the end of this e-mail. All of these are from either the Google top ten or top twenty for some of the searches I did. The most typical mistakes include assuming that: - TLDs are 2-N characters long, with N ranging anywhere from 3 to 6 (In fact, 3 and 6 seem to be the most common upper bounds assumed; the maybe most absurd case had 4 and a comment explicitly referencing .info...) - It is a good idea to have a hard-coded list of TLDs. Such lists frequently *include* the current set of new gTLDs, so these are good news for the current new gTLD operators, and really bad news for the next round. (In one case, there was at least a comment referencing ICANN and the need to update -- but, of course, these JavaScript code snippets are the kind of stuff which gets deployed and forgotten, so that comment is worthless.) Remarkably, most of the code I looked at just accepted two-letter TLDs, with just one (probably not so popular) exception that would only accept ".tv" and ".us". In general terms, I'd suggest that any advisory the GNSO may initiate on the topic of acceptance problems with respect to new TLDs should generally take up the basic theme that the root zone is a dynamic thing, and that operators and programmers should not make unwarranted assumptions on what's in there. Besides the kinds of programming errors mentioned above, that brings up two more dangerous practices: 1. Downloading a copy of the root zone, installing that on a resolver running bind, practically turning that resolver into a root server. If the root zone copy isn't updated regularly, things will break -- not just when new TLDs are added, but also when existing TLDs migrate to different servers. (What's the transition plan for .org, again?) I have no idea how common this kind of setup actually is. 2. Using fake TLDs for local networks. It's not uncommon to just use a random, unused TLD for machines on an intranet; these host names aren't supposed to be seen on the Internet. Of course, it's extremely easy to screw up this kind of setup, and to inadvertently create a "local" collision with a future TLD. Fixing setups like this might get quite costly. At the same time, all this indicates that the "visibility" problems for new gTLDs will persist for quite some time. The dirty dozen address validators: http://sageweb.sage.org/resources/publications/perl/perl17.html http://www.hexillion.com/samples/#Regex http://www.xs4all.nl/~ppk/js/mailcheck.html?email=webmaster%40nic.museum http://insights.iwarp.com/advanced/javascript/validate/formemail.html?email… http://javascript.internet.com/forms/email-address-validation.html?email=ro… http://members.blue.net.au/felgall/emailval.js http://forums.devshed.com/archive/1/2002/09/4/44410 http://www.experts-exchange.com/Web/Web_Languages/JavaScript/Q_20572818.html http://www.js-examples.com/example/?ex=946&mode=1 http://javascriptkit.com/script/script2/acheck.shtml?emailcheck=roessler%40… http://www.aspfree.com/examples/1574,1/examples.aspx http://www.123aspx.com/resdetail.aspx?sfm=308&res=890 -- Thomas Roessler <roessler(a)does-not-exist.org>

1 0

WHOIS Privacy Steering Group Teleconf. Aug. 7/8 - Draft minutes,text and html versions
by GNSO SECRETARIAT 14 Aug '03

14 Aug '03

WHOIS Privacy Steering Group Teleconference August 7/8 - Minutes ATTENDEES: Acting Chair: Bruce Tonkin (non voting) Voting members of the committee: (Note with reference to the GNSO Council decision documented in the minutes of the meeting on 5 June 2003, each constituency could appoint one or two members to the WHOIS Steering Group - the members may be from outside the GNSO Council - each constituency would have one vote in any vote proposed in the WHOIS Steering Group.) Intellectual Property Interests Constituency : Steve Metalitz gTLD Registries constituency: David Maher, Ken Stubbs Commercial and Business Users constituency: Marilyn Cade, Grant Forsyth Non Commercial Users Constituency: Stephanie Perrin (replacing Ruchika Agrawal) Registrars Constituency: Tom Keller, Mark Jeftovic Internet Service and Connectivity Providers constituency: Tony Harris, Maggie Manonukia GNSO Council independent representative: Alick Wilson GNSO Council independent representative: Demi Getschko Non-voting Liaisons At-Large Advisory Committee (ALAC) liaisons: Thomas Roessler, Wendy Seltzer (Note the At-Large Advisory Committee has the same status of the Government Advisory Committee in the new ICANN structure and may report its findings and recommendations directly to the ICANN Board, and in addition may appoint non-voting liaisons to the GNSO Council. The role of Advisory Committees is described in Article XI of the new bylaws - and part 4 of section 2 describes the structure of ALAC in more detail) Government Advisory Committee Liaison: (non yet appointed to the Steering Group) : Absent IP Constituency : Kiyoshi Tsuru Non Commercial Users Constituency: Milton Mueller Item 1 Update on selection of chair Bruce Tonkin reported that during the meeting in Montreal several options were suggested for the chair and Bruce contacted, Mike Roberts, Scott Bradner and Paul Kane on behalf of the WHOIS Privacy Steering Group. Mike Roberts has indicated that he is not available, and Paul Kane would accept the role if no one else would but it was not his preference. No response from received from Scott Bradner. Bruce Tonkin offered to act as non-voting chair, until another chair is selected by the Steering Group Items 2: Update on WHOIS policy coordination with other related groups in ICANN (GAC, ASO, IAB, ALAC, etc) chaired by Paul Twomey. Re-iterating from: http://www.gnso.icann.org/mailing-lists/archives/whois-sc/msg00006.html At the end of the WHOIS workshop in Montreal, Paul Twomey stated: From: "I am asking the chairs of the GNSO, the Governmental Advisory Committee, I'm also asking the IAB Liaison if they will come together with me and help plot out a program for joint meetings between their particular ongoing groups, the GAC as a working group, there's a working group, a steering group in the GNSO, if they'll come together and plot out a program of joint meetings with an aim towards two things: a prioritization of issues to be addressed or issues that need to be further explored, and a work program for the exploring of those issues together, with the aim that that would be done intersessionally, but we would have another report from that joint meeting framework in Carthage." Subsequently two informal teleconferences have been held with representatives from GAC, RIRs, IETF to identify what issues raised in the WHOIS workshop are appropriate for further analysis. The topics discussed included status of the IETF CRISP work, documenting uses for each data element collected at the time of registration, possibility of classifying types of registrants, and different approaches taken by cctld operators. I expect that the next steps forward at an ICANN staff level are probably to collate some of the data from the work already done on WHOIS within the DNSO/GNSO, and also data presented at the Montreal meeting to help provide factual data to guide policy development. The timing of this work will probably be affected by ICANN staff resourcing. The work in turn may result in issues reports, and then subsequently a formal policy development process on some aspects. Item 3: Review the objectives and terms of reference for the WHOIS Privacy Steering Group The WHOIS Steering Committee was formed after the GNSO Council received the Staff Manager's report which was not in a format to allow for a policy development process. The GNSO Council decided to form a Steering group to examine the 20 issues mentioned in the Staff Manager's report and identify which of the issues should be dealt with first and decide on one or more task forces. Re-iterating from: The objective of the steering group is to: - examine the Staff Manager's report on WHOIS Privacy - review the factual presentations of the ICANN public forum on WHOIS in Montreal - develop recommendations, for the GNSO Council to approve, to form a small number (e.g less than 5) of Task Forces to carry out the policy development process on the major issues identified in the Staff manager's report (it should be possible to group some of the related issues for examination within a single task force) - the recommendations should incorporate for each task force a terms of reference in accordance with the ICANN bylaws (Annex A, Section 7(b)): " Such Charter will include: 1. the issue to be addressed by the task force, as such issue was articulated for the vote before the Council that commenced the PDP; 2. the specific timeline that the task force must adhere to, as set forth below, unless the Board determines that there is a compelling reason to extend the timeline; and 3. any specific instructions from the Council for the task force, including whether or not the task force should solicit the advice of outside advisors on the issue." - if the steering group recommends more than two task forces be created it should recommend to the GNSO Council an order in which the task force work should be done, and an approximate timeframe for when each task force will commence and finish Steering Group members might like to review the IETF standard RFC2418 on IETF Working Group Guidelines and Procedures. The standard documents best practice within the IETF in forming working groups and defining charters. Section 2.1 (criteria for forming a working group) and Section 2.2 (Charter) are particularly relevant. Thomas Roessler reported that the ALAC was looking at how the WHOIS would evolve in general terms and timewise, the ALAC felt that it was continuous policy work. Bruce Tonkin noted that there should be an evolutionary approach in making improvements to the contractual requirements for gtlds to better address privacy concerns, rather than a sudden radical change.. As far as the WHOIS Steering Committee mandate is concerned, in the ICANN structure the GNSO is only able to make recommendations on gTLDs that become binding on Registrars and Registries. Some documents produced by the GNSO could be used as "best practice" documents in other parts of ICANN. It was stressed that the GNSO should focus on a few manageable tasks at a time. The difference was explained between representatives from constituencies, responsible for policy recommendations, and liaisons who were responsible for bringing information from work done within their policy development structure and taking back information from the GNSO work to their fora. The hope was that by ensuring that all parts of ICANN were well informed on the activities relating to WHOIS and Privacy, that a workable balance could be achieved amongst the various stakeholder preferences. Item 4: Review the objectives and terms of reference in light of the Staff Manager's report . The Staff Manager's report drew a distinction between WHOIS itself that is concerned with the display of data, and the wider issues of privacy that relate to the entire domain name registration and maintenance process, and include what data is collected from the registrant, and how it is used, maintained, and made available to others. Preliminary Catalog of Issues Issues concerning data collection 1. Should the elements of data that registrars are required to collect at the time of registration of a domain name be revised? (See Registrar Accreditation Agreement (RAA) § 3.2.) 2. Should registrars be prohibited by ICANN from collecting additional items of data? 3. Should all registrants, or certain classes of registrants (see Issue 18 below), be afforded the option of not providing some or all elements that registrars are required to collect and, if so, which elements? 4. Should the current mechanism for pseudonymous registration be changed or supplemented with one or more alternative mechanisms? (See RAA § 3.7.7.3.) Should steps be taken to encourage broader availability of this mechanism? 5. Are the current requirements that registrars make disclosures to, and obtain consent by, registrants concerning the uses of collected data adequate and appropriate? (See RAA §§ 3.7.7.4 to 3.7.7.6.) Issues Concerning Data Quality 6. Are the procedures currently followed by registrars adequate to promote accurate, complete, and up-to-date data, as required by both privacy and accountability principles? (See RAA §§ 3.7.7.1, 3.7.7.2, and 3.7.8, as well as the GNSOs Whois recommendations on accuracy adopted by the ICANN Board on 27 March 2003.) 7. What should be the consequences when a registrant provides inaccurate or incomplete data, or fails to correct inaccurate or incomplete data? (See RAA §§ 3.7.7.1, 3.7.7.2, and 3.7.8.) Are safeguards needed to prevent abusive reports of inaccuracies? Should certain classes of registrants (see Issue 18 below) be permitted to provide inaccurate or incomplete data? Issues Concerning Data Handling 8. Are the current requirements that registrars handle personal data according to the notices given at the time of registration, and in a manner that avoids loss, misuse, unauthorized access or disclosure, alteration, or destruction, adequate and appropriate? (See RAA §§ 3.7.7.7 and 3.7.7.8.) 9. Are the current requirements for handling of registrar data by registry operators adequate and appropriate? Issues Concerning Data Disclosure 10. Are the current means of query-based access appropriate? Should both web-based access and port-43 access be required? (RAA § 3.3.1.) 11. What are the purposes for providing public query-based access? Are the elements currently required to be disclosed in public query-based access adequate and appropriate? (RAA § 3.3.1.) 12. What measures, if any, should registrars and registry operators be permitted to take to limit data mining of Whois servers? 13. Should access to data be differentiated based on the party receiving access, or based on the use to which the data will be put? If so, how should differentiated access be implemented and how should the cost of differentiation be funded? 14. Should the current requirement that registrars provide bulk Whois access for non-marketing uses be further limited or eliminated? (RAA § 3.3.6, as well as the GNSOs Whois recommendations on accuracy adopted by the ICANN Board on 27 March 2003.) Issues Concerning Data Use 15. Which uses of Whois data by members of the public should be permitted (e.g., resolving technical problems, sourcing spam, identifying online merchants, law enforcement activities, identifying online infringers for enforcement of intellectual property rights, etc.)? Which uses should be prohibited? 16. How should restrictions on permissible uses by members of the public be enforced? (RAA §§ 3.3.6.3 to 3.3.6.5.) 17. To what extent is Whois data actually used to the harm of registrants (e.g., identity theft, spam, stalking, and other harassment)? Issues Concerning Classification of Registrants 18. Should certain types of registrants (e.g., those using domains for political and similar activities) be exempt from the usual requirements to provide data, or to have it available in Whois? How should the eligibility of particular registrants for these exemptions be determined? Are measures required to address the possibility of abuses in the classification procedure? Issues Concerning Commercial Confidentiality and Rights in Data 19. Should registrars have the option, independent of their customers, to protect the confidentiality of Whois data based on registrars proprietary rights to that data? Are the current provisions permitting registrars to claim proprietary rights in personal data about their customers appropriate? (RAA § 3.5.) 20. Should there be ICANN requirements limiting registrars' ability to sell or use Whois data, or other data collected about customers, for commercial purposes? Bruce Tonkin reported on the Top level Steering group commentary as reported by the representatives of each group during the 2 teleconferences: 1. Data collection: what is the actual/original focus of the data? The ICANN staff charged with creating a table from the WHOIS workshop in Montreal on data elements/data use 2. Data quality - accuracy. Discussed by the GNSO and in Montreal. This has been dealt with as a first step in the reminder to registrar to ask registrants to provide accurate data. 3. Data handling: not much discussion 4. Data disclosure: Work is going on in Internet Engineering Task Force on new protocol. John Klensin, the IETF liaison on the ICANN Board requested input from the GNSO on the requirements of this protocol. 5. Data use: not much discussion 6. Classification of registrants: Individual and commercial users. How does the registrar make the separation? It is possible that ICANN staff may assist in developinga discussion paper on the various options. 7. Different countries have taken different approaches to the managementof privacy issues associated with domain names within their related country code, and ICANN staff may assist in putting together a table to compare the various approaches.. Alick Wilson proposed: That there should be different rules for disclosure and different rules for eligibility for the Registrant and for the domain in which the Registrant registers the name. Ken Stubbs noted that there may be some variances to the handling of data based on the purpose of the TLD. For example .name has some different requirements, as it is primarily aimed at individuals. Marilyn Cade noted that a conscious policy decision should be made on whether to attempt to establish some minimum common standards amongst all gltds, or whether to treat each gtld differently. Item 5: Initial discussion on possible task forces As the GNSO needs to prioritize its work program, Bruce Tonkin called for input from each constituency of the GNSO to help select 5 top issues for further consideration in one or more task forces. Intellectual Property Interests Constituency : Steve Metalitz reported that issues 10, 12, 14, 20, and 5 were of most importance. In particular it should be possible to makes some recommendations in the short term (related to issues 10,12) to deal with the present problems of data mining of registration data using the IETF WHOIS protocol (which uses TCP port 43). He also noted that the contractual requirements associated with the use of bulk WHOIS (related to issues 14,20) for marketing purposes were not being enforced, and it also appeared that registrants were not properly informed about how the data collected at registration would be accessed by the public (related to issue 5). gTLD Registries Constituency: David Maher selected issues 18, 10, 3, 4, and noted that with regard to the .org registry that some registrants were seeking anonymity (related to issues 3,4,18). Ken Stubbs added issues 12, 20 (related to issue 10), and also agreed with Steve Metalitz that issue 5 was a problem. Non-commercial Users Constituency: Stephanie Perrin noted that the non-commercial users constituency was interested in the preservation of anonymity (related to issues 3,4, 18), and if there was some distinction made between data made available publicly and data provided to for example law enforcement, that there was sufficient transparency to the user as to who had access to non-public data (related to issues 5 and 15). An appropriate oversight mechanism would be required for differentiated access. Commercial and Business Users Constituency Marilyn Cade noted that WHOIS data should not be used for marketing and cited the need to control data mining related to issues 10 and 12. Marilyn also stated that registrars should not use data collected for the purposes of domain name registration for other commercial purposes related to issue 20. Finally commercial and business users of domain names require accurate data (related to issues 6 and 7). Registrars Constituency Tom Keller noted that the main issue for registrars concerned the data mining of registration data via the query based service provided by port 43 WHOIS (related to issues 10 and 12). In addition registrars were considering whether differentiated access to data is feasible (related to issue 13). Tom agreed with Steve and Ken that registrants need to be made more aware of how the data collected at the time of registration would be made available to others (issue 5). Tom also questioned whether all data elements currently required in the contracts were necessary (e.g customers may be prepared accept a poorer quality of service that results from providing only a limited number of contact points e.g if only email, or only postal address was supplied). Mark Jeftovic noted with respect to issue 7, that registrants needed to accept some responsibility in return for being online. Mark also noted that the impact of providing bulk WHOIS on registrants needed to be examined (issues 14, and 17). Internet Service and Connectivity Providers Constituency Tony Harris selected issues 6, 7,10, 12, and 13. Maggie Manonukia elaborated that data quality (issues 6,7) and limitations on data mining (issues 10,12) were the main issues for ISPs. Specifically accurate technical contact information was very important (related to issues 1 and 6). Issues under consideration within the At Large Advisory Committee Wendy Seltzer reported that the At Large Advisory Committee was reviewing WHOIS from first principles and considering what data must be collected (related to issues 1,2,3,4,5). There were concerns that if the present data collected was restricted for public access, but with mechanisms for law enforcement access, that registrants may not be aware of what uses their data would be put (ie this would lead to a lack of transparency for individual users). Wendy reported that some individual users desire anonymity (the ability to use a domain name without supplying their name), and pseudonymity (the ability to provide a false name or nickname when registering a domain name). In the absence of an accurate name, if a domain name was being used for illegal purposes the action could be to shutdown the operation of the domain name. Thomas Roessler added that individual users should be able to choose how much contact information they supplied at the time of registration, on the basis that an individual could choose to experience a lower quality of service from a registrar that would result from such limited information. Advice from GNSO Council members Demi Getschko noted that in his personal opinion the most important issues are 5,7 12, 14, 18, and 20. Alick Wilson recommended that each constituency review the data that must be collected by registrars currently and identify which elements should be mandatory and identify for each of these elements the consequences if the data element was not available. Alick also suggested that ICANN review how countries that are operating cctlds have handled WHOIS with respect to the privacy legislation applicable in that country. Alick suggested that ICANN staff develop a data model for domain name registration data. Item 6: Next steps The GNSO Secretariat will prepare a draft table of the top 5 issues from each GNSO Constituency based on the discussions above prior to the next meeting of the Steering Group. Each Constituency should discuss amongst its members to reach a consensus on the top 5 issues and report these to the GNSO Secretariat to create a final version of the table. The GNSO Secretariat will prepare a table of the current data elements that must be collected by registrars at the time of registration. Each constituency should discuss amongst its members to reach a consensus on which data elements should continue to be mandatory and identify the consequences if a mandatory element was not available. The Steering Committee also requested that the chair (Bruce Tonkin) liaise with the ccNSO through the ccNSO Liaison to the GNSO to seek a non-voting liaison from the ccNSO on the steering group. Individual cctlds may be able to provide their input on the table of data elements. Alick Wilson to provide further information on the requirements for a data model for domain name registration data. Next teleconference to be scheduled by the Chair, with the objective of agreeing on the top 5 issues, and beginning to see how the issues could be grouped in one or more task forces. Bruce Tonkin ended the call at 9:00 am Friday 8 August, Melbourne time, 24:00 UTC.

1 0

GNSO Council teleconference MP3 recording , August 14, 2003
by GNSO SECRETARIAT 14 Aug '03

14 Aug '03

[To: ga(a)dnso.org; announce(a)dnso.org] [To: liaison6c(a)dnso.org; council(a)dnso.org] Please find the MP3 recording of the GNSO Council teleconference, held on August 14, 2003 at: http://www.coresystem.net/gnso/GNSO-20030814.mp3.zip (to download) http://www.coresystem.net/gnso/GNSO-20030814.mp3 (real time play) Happy listening! GNSO Secretariat gnso.secretariat(a)gnso.icann.org

1 0

Re: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE
by ellen＠ellenshankman.com 14 Aug '03

14 Aug '03

On Wed, 13 Aug 2003 18:17:55 +0200, "GNSO SECRETARIAT" wrote: I'm sorry that I will be unable to make the call - am traveling and will not be phone available at that time. My proxy to Laurence and/or Lynda. Still agree to the proposal. Warmest, Ellen > > [To: Council(a)dnso.org] > > At the request of Antonio Harris, this mail is > forwarded to the GNSO Council > list > > mercredi 13 août 2003 16:57 > À : gnso.secretariat(a)gnso.icann.org; > owner-council(a)dnso.org > Objet : RESOLUTION FOR TOMORROW'S TELECONFERENCE > > > Bruce, > > I would like to present the following resolution > to be discussed in the teleconference: > > Proposed Council resolution on Constituency > representation to meet ICANN > requirements on geographical diversity and informed > decision-making > Proposed by, in alphabetical order, > Antonio Harris > Ellen Shankman, > Philip Sheppard > Ken Stubbs > > Whereas, > the Names Council resolution of 1st August 2002 > called for "three > representatives > per Constituency on the GNSO Council". > > Whereas, > ICANN core value 2.4 is: > - "Seeking and supporting broad, informed > participation reflecting the > functional, geographic, and cultural diversity of the > Internet at all > levels > of policy development and decision-making". > > Whereas, > ICANN core value 2.7 is: > - "Employing open and transparent policy development > mechanisms that > (i) promote well-informed decisions based on expert > advice, and (ii) ensure > that those entities most affected can assist in the > policy development > process." > > Whereas, > by-law article XX.5.8 states: > "In the absence of further action on the topic by > the New Board, each > of the GNSO constituencies shall select two > representatives to the GNSO > Council.." "..no later than 1 October 2003." > > > The GNSO council resolves that: > > Two representatives per Constituency is inconsistent > with ICANN core > value 2.4 > on geographic and cultural diversity within the > constituency. With three > representatives per constituency, the majority of > ICANN regions ARE > represented. > With two, the majority of ICANN regions are NOT > represented. > > . > Two representatives per Constituency is inconsistent > with ICANN core > value 2.7 > on well-informed decision making. Experience has shown > that three > representatives > improves the constituencies ability to share the > workload of a council > member, to be able to participate in task forces of > the council, and to > more effectively communicate with multiple regions. > . > There is no evidence of increased effectiveness with > two representatives > rather than three. > . > And therefore the GNSO Council requests the Board to > make two changes > in its review timetable: > 1. To change the transition article to allow three > representatives per > constituency on the GNSO Council until the end of the > ICANN annual meeting > 2004; > 2. To perform a review of the GNSO council in or > around June 2004. > > Regards > > Tony Harris

1 0

Re: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE
by philip.sheppard＠aim.be 14 Aug '03

14 Aug '03

I too am happy to support Jeff's new wording. Hope to join the call later. If not accept this as a proxy vote in favour. Philip "Ken Stubbs" <kstubbs(a)digitel.net> wrote .. > fellow council members > > i like jeff's wording and would propose this as a modification to the > initial proposal proposal.. > > it is truly more positive and, i believe, remains a reflection of the > sentiments of many . > > sincerely > > ken stubbs > > ----- Original Message ----- > From: "Neuman, Jeff" <Jeff.Neuman(a)Neustar.us> > To: "Neuman, Jeff" <Jeff.Neuman(a)Neustar.us>; > <gnso.secretariat(a)gnso.icann.org>; "'council'" <council(a)dnso.org> > Sent: Wednesday, August 13, 2003 2:04 PM > Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE > > > > Here is what I would recommend, which sounds much more positive. I have > > still not decided on my position on this motion, but I thought this > > resolution sounds more palatable. > > > > > > Please let me know your thoughts. > > > > > **************************************************************************** > > * > > > > Whereas, > > the Names Council resolution of 1st August 2002 called for "three > > representatives > > per Constituency on the GNSO Council". > > > > Whereas, > > ICANN core value 2.4 is: > > - "Seeking and supporting broad, informed participation reflecting > the > > functional, geographic, and cultural diversity of the Internet at all > > levels > > of policy development and decision-making". > > > > Whereas, > > ICANN core value 2.7 is: > > - "Employing open and transparent policy development mechanisms that > > (i) promote well-informed decisions based on expert advice, and (ii) > ensure > > that those entities most affected can assist in the policy development > > process." > > > > Whereas, > > by-law article XX.5.8 states: > > "In the absence of further action on the topic by the New Board, each > > of the GNSO constituencies shall select two representatives to the GNSO > > Council.." "..no later than 1 October 2003." > > > > > > The GNSO council resolves that: > > > > Three representatives per Constituency is consistent with ICANN core > > value 2.4 on geographic and cultural diversity within the constituency > as > > the majority of ICANN regions are > > represented. > > . > > Three representatives per Constituency is consistent with ICANN core > > value 2.7 on well-informed decision making. Experience has shown that > three > > representatives improves the constituencies ability to share the workload > > of a council > > member, to be able to participate in task forces of the council, and > to > > more effectively communicate with multiple regions. > > > > And therefore the GNSO Council requests the Board to make two changes > > in its review timetable: > > 1. To change the transition article to allow three representatives > per > > constituency on the GNSO Council until the end of the ICANN annual > meeting > > 2004; > > 2. To perform a review of the GNSO council in or around June 2004. > > > > -----Original Message----- > > From: Neuman, Jeff > > Sent: Wednesday, August 13, 2003 12:30 PM > > To: 'gnso.secretariat(a)gnso.icann.org'; council > > Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE > > > > > > All, > > > > This is my personal opinion. I am not against this resolution. In fact > the > > principle of having 3 representatives makes sense. > > > > However, if this resolution were to stand, I would have to oppose it > because > > I do not believe that the requirement of having 2 representatives is > > inconsistent with the existing bylaws (as stated in the resolution below). > > Whether it is inconsistent or not is a point of debate in which reasonable > > minds may differ. In addition, arguments of efficiency are also > debatable. > > Lets not give the Board a topic to debate and give them just the bottom > line > > resolution. > > > > I want to support this concept. Therefore, I would recommend that we > revise > > the motion. I will send around my recommendation later on today. > > > > Thanks > > > > > > > > -----Original Message----- > > From: GNSO SECRETARIAT [mailto:gnso.secretariat@gnso.icann.org] > > Sent: Wednesday, August 13, 2003 12:18 PM > > To: council > > Subject: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE > > > > > > [To: Council(a)dnso.org] > > > > At the request of Antonio Harris, this mail is forwarded to the GNSO > Council > > list > > > > mercredi 13 août 2003 16:57 > > À : gnso.secretariat(a)gnso.icann.org; owner-council(a)dnso.org > > Objet : RESOLUTION FOR TOMORROW'S TELECONFERENCE > > > > > > Bruce, > > > > I would like to present the following resolution > > to be discussed in the teleconference: > > > > Proposed Council resolution on Constituency representation to meet ICANN > > requirements on geographical diversity and informed decision-making > > Proposed by, in alphabetical order, > > Antonio Harris > > Ellen Shankman, > > Philip Sheppard > > Ken Stubbs > > > > Whereas, > > the Names Council resolution of 1st August 2002 called for "three > > representatives > > per Constituency on the GNSO Council". > > > > Whereas, > > ICANN core value 2.4 is: > > - "Seeking and supporting broad, informed participation reflecting > the > > functional, geographic, and cultural diversity of the Internet at all > > levels > > of policy development and decision-making". > > > > Whereas, > > ICANN core value 2.7 is: > > - "Employing open and transparent policy development mechanisms that > > (i) promote well-informed decisions based on expert advice, and (ii) > ensure > > that those entities most affected can assist in the policy development > > process." > > > > Whereas, > > by-law article XX.5.8 states: > > "In the absence of further action on the topic by the New Board, each > > of the GNSO constituencies shall select two representatives to the GNSO > > Council.." "..no later than 1 October 2003." > > > > > > The GNSO council resolves that: > > > > Two representatives per Constituency is inconsistent with ICANN core > > value 2.4 > > on geographic and cultural diversity within the constituency. With three > > representatives per constituency, the majority of ICANN regions ARE > > represented. > > With two, the majority of ICANN regions are NOT represented. > > > > . > > Two representatives per Constituency is inconsistent with ICANN core > > value 2.7 > > on well-informed decision making. Experience has shown that three > > representatives > > improves the constituencies ability to share the workload of a council > > member, to be able to participate in task forces of the council, and > to > > more effectively communicate with multiple regions. > > . > > There is no evidence of increased effectiveness with two > representatives > > rather than three. > > . > > And therefore the GNSO Council requests the Board to make two changes > > in its review timetable: > > 1. To change the transition article to allow three representatives > per > > constituency on the GNSO Council until the end of the ICANN annual > meeting > > 2004; > > 2. To perform a review of the GNSO council in or around June 2004. > > > > Regards > > > > Tony Harris > > > > > >

1 0

TR: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE
by GNSO SECRETARIAT 14 Aug '03

14 Aug '03

[To: council(a)dnso.org] Forwarded as requested. Dial in number and participant code have been sent to Michael Palage as well. Glen -----Message d'origine----- De : Michael D. Palage [mailto:michael@palage.com] Envoyé : jeudi 14 août 2003 07:23 À : Glen De Saint Gery; gnso.secretariat(a)gnso.icann.org Objet : RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE Glen, Could you please forward this email to the Names Council mailing list and provide me information on the dial-in listen only ports for tomorrow's Names Council meeting. Thanks in advance. Mike Hello Name Council Members: I will be trying to join your teleconference today via a listen port if it is available. As the Board may be required to take action upon this proposed resolution, I would ask that you consider my "personal" comments during your deliberation of this resolution. I agree that the resolution's restatement of ICANN's core values as set forth in ICANN's by-laws, however, I see no nexus for the proposition that three Names Council representatives are more consistent with ICANN's core values that two Names Council representatives. Additionally, I see no basis for the proposition that three Names Council representatives are more "effective" that two Names Council representatives, since the Names Council has never operated with two representatives. On what data are you basing this proposition. Would it not be prudent to allow the ICANN By-laws that were properly and thoroughly vetted to be implemented prior to requesting the Board to change them. Some additional data points for consideration. If the Names Council and respective constituencies are truly concerned about outreach and global participation I would encourage them to review the NCUC proposed new charter which provides for Regional Representatives. see, http://dnso.ipsl.fr/constituency/ncdnh/20030731.NCUC-charter.html. I submit to this council that adherence to ICANN's core values as set forth in your resolution should start and remained focused at the constituency level. ICANN as we all know is a bottoms-up organization, thus ICANN's core values should be most strongly supported at the constituency level. Moreover, based on my experience and review of the various constituency by-laws, the Names Council representatives are responsible to act as directed by the constituency thus further undermining the need for three representatives as opposed to two. Finally, I was in attendance during the ICANN regional meeting in Berlin (1999) when the individual domain name holders constituency sought accreditation by the Board. Unfortunately, despite repeated efforts over the years to have this constituency recognized there has been no additional constituencies recognized by ICANN since 1999. I believe that by shrinking the Names Council to two representatives per constituency as per the by-laws, this will enable potentially new constituencies to come into existence as envisioned by the by-laws. Although there currently exists a voting balance between users and providers, there may be the need for more balance between commercial versus non-commercial users. Specifically, there are three commercial user constituencies (Business, ISP, and IP) and only one non-commercial user constituency. Just some personal comments that I thought I would share. Best regards, Michael D. Palage > -----Original Message----- > From: GNSO SECRETARIAT [mailto:gnso.secretariat@gnso.icann.org] > Sent: Wednesday, August 13, 2003 12:18 PM > To: council > Subject: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE > > > [To: Council(a)dnso.org] > > At the request of Antonio Harris, this mail is forwarded to the > GNSO Council > list > > mercredi 13 août 2003 16:57 > À : gnso.secretariat(a)gnso.icann.org; owner-council(a)dnso.org > Objet : RESOLUTION FOR TOMORROW'S TELECONFERENCE > > > Bruce, > > I would like to present the following resolution > to be discussed in the teleconference: > > Proposed Council resolution on Constituency representation to meet ICANN > requirements on geographical diversity and informed decision-making > Proposed by, in alphabetical order, > Antonio Harris > Ellen Shankman, > Philip Sheppard > Ken Stubbs > > Whereas, > the Names Council resolution of 1st August 2002 called for "three > representatives > per Constituency on the GNSO Council". > > Whereas, > ICANN core value 2.4 is: > - "Seeking and supporting broad, informed participation reflecting the > functional, geographic, and cultural diversity of the Internet at all > levels > of policy development and decision-making". > > Whereas, > ICANN core value 2.7 is: > - "Employing open and transparent policy development mechanisms that > (i) promote well-informed decisions based on expert advice, and > (ii) ensure > that those entities most affected can assist in the policy development > process." > > Whereas, > by-law article XX.5.8 states: > "In the absence of further action on the topic by the New Board, each > of the GNSO constituencies shall select two representatives to the GNSO > Council.." "..no later than 1 October 2003." > > > The GNSO council resolves that: > > Two representatives per Constituency is inconsistent with ICANN core > value 2.4 > on geographic and cultural diversity within the constituency. With three > representatives per constituency, the majority of ICANN regions ARE > represented. > With two, the majority of ICANN regions are NOT represented. > > . > Two representatives per Constituency is inconsistent with ICANN core > value 2.7 > on well-informed decision making. Experience has shown that three > representatives > improves the constituencies ability to share the workload of a council > member, to be able to participate in task forces of the council, and to > more effectively communicate with multiple regions. > . > There is no evidence of increased effectiveness with two > representatives > rather than three. > . > And therefore the GNSO Council requests the Board to make two changes > in its review timetable: > 1. To change the transition article to allow three representatives per > constituency on the GNSO Council until the end of the ICANN > annual meeting > 2004; > 2. To perform a review of the GNSO council in or around June 2004. > > Regards > > Tony Harris > >

1 0

RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE
by Cade,Marilyn S - LGCRP 14 Aug '03

14 Aug '03

I will be on part of tomorrow's call if possible and maybe be able to present this in person, but just in case, I wish to call something to the Council's attention. It depends on how the call proceeds in terms of timing. As some of you know, I have a family medical situation to manage tomorrow which affects my availability. However, I will do my best. First, let me be clear that I support a resolution which will ensure that there are three reps per constituency. Should I not be on the call, I have given a proxy. I am not sure why you would say that you would oppose the resolution, Jeff. It sounds like you are proposing a modification to the resolution. :-) I hope that is what you were intending to convey. I can support some changes in the language of the resolution as long as the intent of the resolution is clear. Thanks for the rewording effort. However, I note one other change which I think is needed in the motion, in order to ensure clarity. I have been off line most of the week, due to the medical situation mentioned above, so didn't have a chance to review the motion until now. My apologies for late comments. I suggest a change, as noted below. I have pasted below, a segment from the original resolution where I propose a change for clarity. PRESENT LANGUAGE READS: " And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004." I suggest that 1., as drafted should be modified as follows/additions IN CAPS: PROPOSED LANGUAGE: " And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004, WHICH SHOULD INCLUDE AMONG OTHER ASPECTS OF THE REVIEW CRITERIA, A RECOMMENDATION REGARDING NUMBER OF REPRESENTATIVES PER CONSTITUENCY. -----Original Message----- From: Neuman, Jeff [mailto:Jeff.Neuman@Neustar.us] Sent: Wednesday, August 13, 2003 10:53 PM To: 'Antonio Harris'; Neuman, Jeff; gnso.secretariat(a)gnso.icann.org; 'council' Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE Already know the answer to your last question... It would be me :) -----Original Message----- From: Antonio Harris [mailto:harris@cabase.org.ar] Sent: Wednesday, August 13, 2003 4:37 PM To: Neuman, Jeff; gnso.secretariat(a)gnso.icann.org; 'council' Subject: Re: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE Jeff, This is ok with me. I hope we can count on your support also, as it would avoid your having to decide which of your constituency three reps must step down on October 1 ? Regards Tony Harris ----- Original Message ----- From: "Neuman, Jeff" <Jeff.Neuman(a)Neustar.us> To: "Neuman, Jeff" <Jeff.Neuman(a)Neustar.us>; <gnso.secretariat(a)gnso.icann.org>; "'council'" <council(a)dnso.org> Sent: Wednesday, August 13, 2003 3:04 PM Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE Here is what I would recommend, which sounds much more positive. I have still not decided on my position on this motion, but I thought this resolution sounds more palatable. Please let me know your thoughts. **************************************************************************** * Whereas, the Names Council resolution of 1st August 2002 called for "three representatives per Constituency on the GNSO Council". Whereas, ICANN core value 2.4 is: - "Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making". Whereas, ICANN core value 2.7 is: - "Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process." Whereas, by-law article XX.5.8 states: "In the absence of further action on the topic by the New Board, each of the GNSO constituencies shall select two representatives to the GNSO Council.." "..no later than 1 October 2003." The GNSO council resolves that: Three representatives per Constituency is consistent with ICANN core value 2.4 on geographic and cultural diversity within the constituency as the majority of ICANN regions are represented. . Three representatives per Constituency is consistent with ICANN core value 2.7 on well-informed decision making. Experience has shown that three representatives improves the constituencies ability to share the workload of a council member, to be able to participate in task forces of the council, and to more effectively communicate with multiple regions. And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004. -----Original Message----- From: Neuman, Jeff Sent: Wednesday, August 13, 2003 12:30 PM To: 'gnso.secretariat(a)gnso.icann.org'; council Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE All, This is my personal opinion. I am not against this resolution. In fact the principle of having 3 representatives makes sense. However, if this resolution were to stand, I would have to oppose it because I do not believe that the requirement of having 2 representatives is inconsistent with the existing bylaws (as stated in the resolution below). Whether it is inconsistent or not is a point of debate in which reasonable minds may differ. In addition, arguments of efficiency are also debatable. Lets not give the Board a topic to debate and give them just the bottom line resolution. I want to support this concept. Therefore, I would recommend that we revise the motion. I will send around my recommendation later on today. Thanks -----Original Message----- From: GNSO SECRETARIAT [mailto:gnso.secretariat@gnso.icann.org] Sent: Wednesday, August 13, 2003 12:18 PM To: council Subject: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE [To: Council(a)dnso.org] At the request of Antonio Harris, this mail is forwarded to the GNSO Council list mercredi 13 août 2003 16:57 À : gnso.secretariat(a)gnso.icann.org; owner-council(a)dnso.org Objet : RESOLUTION FOR TOMORROW'S TELECONFERENCE Bruce, I would like to present the following resolution to be discussed in the teleconference: Proposed Council resolution on Constituency representation to meet ICANN requirements on geographical diversity and informed decision-making Proposed by, in alphabetical order, Antonio Harris Ellen Shankman, Philip Sheppard Ken Stubbs Whereas, the Names Council resolution of 1st August 2002 called for "three representatives per Constituency on the GNSO Council". Whereas, ICANN core value 2.4 is: - "Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making". Whereas, ICANN core value 2.7 is: - "Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process." Whereas, by-law article XX.5.8 states: "In the absence of further action on the topic by the New Board, each of the GNSO constituencies shall select two representatives to the GNSO Council.." "..no later than 1 October 2003." The GNSO council resolves that: Two representatives per Constituency is inconsistent with ICANN core value 2.4 on geographic and cultural diversity within the constituency. With three representatives per constituency, the majority of ICANN regions ARE represented. With two, the majority of ICANN regions are NOT represented. . Two representatives per Constituency is inconsistent with ICANN core value 2.7 on well-informed decision making. Experience has shown that three representatives improves the constituencies ability to share the workload of a council member, to be able to participate in task forces of the council, and to more effectively communicate with multiple regions. . There is no evidence of increased effectiveness with two representatives rather than three. . And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004. Regards Tony Harris

1 0

RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE
by Neuman, Jeff 14 Aug '03

14 Aug '03

Already know the answer to your last question... It would be me :) -----Original Message----- From: Antonio Harris [mailto:harris@cabase.org.ar] Sent: Wednesday, August 13, 2003 4:37 PM To: Neuman, Jeff; gnso.secretariat(a)gnso.icann.org; 'council' Subject: Re: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE Jeff, This is ok with me. I hope we can count on your support also, as it would avoid your having to decide which of your constituency three reps must step down on October 1 ? Regards Tony Harris ----- Original Message ----- From: "Neuman, Jeff" <Jeff.Neuman(a)Neustar.us> To: "Neuman, Jeff" <Jeff.Neuman(a)Neustar.us>; <gnso.secretariat(a)gnso.icann.org>; "'council'" <council(a)dnso.org> Sent: Wednesday, August 13, 2003 3:04 PM Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE Here is what I would recommend, which sounds much more positive. I have still not decided on my position on this motion, but I thought this resolution sounds more palatable. Please let me know your thoughts. **************************************************************************** * Whereas, the Names Council resolution of 1st August 2002 called for "three representatives per Constituency on the GNSO Council". Whereas, ICANN core value 2.4 is: - "Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making". Whereas, ICANN core value 2.7 is: - "Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process." Whereas, by-law article XX.5.8 states: "In the absence of further action on the topic by the New Board, each of the GNSO constituencies shall select two representatives to the GNSO Council.." "..no later than 1 October 2003." The GNSO council resolves that: Three representatives per Constituency is consistent with ICANN core value 2.4 on geographic and cultural diversity within the constituency as the majority of ICANN regions are represented. . Three representatives per Constituency is consistent with ICANN core value 2.7 on well-informed decision making. Experience has shown that three representatives improves the constituencies ability to share the workload of a council member, to be able to participate in task forces of the council, and to more effectively communicate with multiple regions. And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004. -----Original Message----- From: Neuman, Jeff Sent: Wednesday, August 13, 2003 12:30 PM To: 'gnso.secretariat(a)gnso.icann.org'; council Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE All, This is my personal opinion. I am not against this resolution. In fact the principle of having 3 representatives makes sense. However, if this resolution were to stand, I would have to oppose it because I do not believe that the requirement of having 2 representatives is inconsistent with the existing bylaws (as stated in the resolution below). Whether it is inconsistent or not is a point of debate in which reasonable minds may differ. In addition, arguments of efficiency are also debatable. Lets not give the Board a topic to debate and give them just the bottom line resolution. I want to support this concept. Therefore, I would recommend that we revise the motion. I will send around my recommendation later on today. Thanks -----Original Message----- From: GNSO SECRETARIAT [mailto:gnso.secretariat@gnso.icann.org] Sent: Wednesday, August 13, 2003 12:18 PM To: council Subject: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE [To: Council(a)dnso.org] At the request of Antonio Harris, this mail is forwarded to the GNSO Council list mercredi 13 août 2003 16:57 À : gnso.secretariat(a)gnso.icann.org; owner-council(a)dnso.org Objet : RESOLUTION FOR TOMORROW'S TELECONFERENCE Bruce, I would like to present the following resolution to be discussed in the teleconference: Proposed Council resolution on Constituency representation to meet ICANN requirements on geographical diversity and informed decision-making Proposed by, in alphabetical order, Antonio Harris Ellen Shankman, Philip Sheppard Ken Stubbs Whereas, the Names Council resolution of 1st August 2002 called for "three representatives per Constituency on the GNSO Council". Whereas, ICANN core value 2.4 is: - "Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making". Whereas, ICANN core value 2.7 is: - "Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process." Whereas, by-law article XX.5.8 states: "In the absence of further action on the topic by the New Board, each of the GNSO constituencies shall select two representatives to the GNSO Council.." "..no later than 1 October 2003." The GNSO council resolves that: Two representatives per Constituency is inconsistent with ICANN core value 2.4 on geographic and cultural diversity within the constituency. With three representatives per constituency, the majority of ICANN regions ARE represented. With two, the majority of ICANN regions are NOT represented. . Two representatives per Constituency is inconsistent with ICANN core value 2.7 on well-informed decision making. Experience has shown that three representatives improves the constituencies ability to share the workload of a council member, to be able to participate in task forces of the council, and to more effectively communicate with multiple regions. . There is no evidence of increased effectiveness with two representatives rather than three. . And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004. Regards Tony Harris

1 0

RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE
by Neuman, Jeff 13 Aug '03

13 Aug '03

Here is what I would recommend, which sounds much more positive. I have still not decided on my position on this motion, but I thought this resolution sounds more palatable. Please let me know your thoughts. **************************************************************************** * Whereas, the Names Council resolution of 1st August 2002 called for "three representatives per Constituency on the GNSO Council". Whereas, ICANN core value 2.4 is: - "Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making". Whereas, ICANN core value 2.7 is: - "Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process." Whereas, by-law article XX.5.8 states: "In the absence of further action on the topic by the New Board, each of the GNSO constituencies shall select two representatives to the GNSO Council.." "..no later than 1 October 2003." The GNSO council resolves that: Three representatives per Constituency is consistent with ICANN core value 2.4 on geographic and cultural diversity within the constituency as the majority of ICANN regions are represented. . Three representatives per Constituency is consistent with ICANN core value 2.7 on well-informed decision making. Experience has shown that three representatives improves the constituencies ability to share the workload of a council member, to be able to participate in task forces of the council, and to more effectively communicate with multiple regions. And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004. -----Original Message----- From: Neuman, Jeff Sent: Wednesday, August 13, 2003 12:30 PM To: 'gnso.secretariat(a)gnso.icann.org'; council Subject: RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE All, This is my personal opinion. I am not against this resolution. In fact the principle of having 3 representatives makes sense. However, if this resolution were to stand, I would have to oppose it because I do not believe that the requirement of having 2 representatives is inconsistent with the existing bylaws (as stated in the resolution below). Whether it is inconsistent or not is a point of debate in which reasonable minds may differ. In addition, arguments of efficiency are also debatable. Lets not give the Board a topic to debate and give them just the bottom line resolution. I want to support this concept. Therefore, I would recommend that we revise the motion. I will send around my recommendation later on today. Thanks -----Original Message----- From: GNSO SECRETARIAT [mailto:gnso.secretariat@gnso.icann.org] Sent: Wednesday, August 13, 2003 12:18 PM To: council Subject: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE [To: Council(a)dnso.org] At the request of Antonio Harris, this mail is forwarded to the GNSO Council list mercredi 13 août 2003 16:57 À : gnso.secretariat(a)gnso.icann.org; owner-council(a)dnso.org Objet : RESOLUTION FOR TOMORROW'S TELECONFERENCE Bruce, I would like to present the following resolution to be discussed in the teleconference: Proposed Council resolution on Constituency representation to meet ICANN requirements on geographical diversity and informed decision-making Proposed by, in alphabetical order, Antonio Harris Ellen Shankman, Philip Sheppard Ken Stubbs Whereas, the Names Council resolution of 1st August 2002 called for "three representatives per Constituency on the GNSO Council". Whereas, ICANN core value 2.4 is: - "Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making". Whereas, ICANN core value 2.7 is: - "Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process." Whereas, by-law article XX.5.8 states: "In the absence of further action on the topic by the New Board, each of the GNSO constituencies shall select two representatives to the GNSO Council.." "..no later than 1 October 2003." The GNSO council resolves that: Two representatives per Constituency is inconsistent with ICANN core value 2.4 on geographic and cultural diversity within the constituency. With three representatives per constituency, the majority of ICANN regions ARE represented. With two, the majority of ICANN regions are NOT represented. . Two representatives per Constituency is inconsistent with ICANN core value 2.7 on well-informed decision making. Experience has shown that three representatives improves the constituencies ability to share the workload of a council member, to be able to participate in task forces of the council, and to more effectively communicate with multiple regions. . There is no evidence of increased effectiveness with two representatives rather than three. . And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004. Regards Tony Harris

3 2

RE: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE
by Neuman, Jeff 13 Aug '03

13 Aug '03

All, This is my personal opinion. I am not against this resolution. In fact the principle of having 3 representatives makes sense. However, if this resolution were to stand, I would have to oppose it because I do not believe that the requirement of having 2 representatives is inconsistent with the existing bylaws (as stated in the resolution below). Whether it is inconsistent or not is a point of debate in which reasonable minds may differ. In addition, arguments of efficiency are also debatable. Lets not give the Board a topic to debate and give them just the bottom line resolution. I want to support this concept. Therefore, I would recommend that we revise the motion. I will send around my recommendation later on today. Thanks -----Original Message----- From: GNSO SECRETARIAT [mailto:gnso.secretariat@gnso.icann.org] Sent: Wednesday, August 13, 2003 12:18 PM To: council Subject: [council] RESOLUTION FOR TOMORROW'S TELECONFERENCE [To: Council(a)dnso.org] At the request of Antonio Harris, this mail is forwarded to the GNSO Council list mercredi 13 août 2003 16:57 À : gnso.secretariat(a)gnso.icann.org; owner-council(a)dnso.org Objet : RESOLUTION FOR TOMORROW'S TELECONFERENCE Bruce, I would like to present the following resolution to be discussed in the teleconference: Proposed Council resolution on Constituency representation to meet ICANN requirements on geographical diversity and informed decision-making Proposed by, in alphabetical order, Antonio Harris Ellen Shankman, Philip Sheppard Ken Stubbs Whereas, the Names Council resolution of 1st August 2002 called for "three representatives per Constituency on the GNSO Council". Whereas, ICANN core value 2.4 is: - "Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making". Whereas, ICANN core value 2.7 is: - "Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process." Whereas, by-law article XX.5.8 states: "In the absence of further action on the topic by the New Board, each of the GNSO constituencies shall select two representatives to the GNSO Council.." "..no later than 1 October 2003." The GNSO council resolves that: Two representatives per Constituency is inconsistent with ICANN core value 2.4 on geographic and cultural diversity within the constituency. With three representatives per constituency, the majority of ICANN regions ARE represented. With two, the majority of ICANN regions are NOT represented. . Two representatives per Constituency is inconsistent with ICANN core value 2.7 on well-informed decision making. Experience has shown that three representatives improves the constituencies ability to share the workload of a council member, to be able to participate in task forces of the council, and to more effectively communicate with multiple regions. . There is no evidence of increased effectiveness with two representatives rather than three. . And therefore the GNSO Council requests the Board to make two changes in its review timetable: 1. To change the transition article to allow three representatives per constituency on the GNSO Council until the end of the ICANN annual meeting 2004; 2. To perform a review of the GNSO council in or around June 2004. Regards Tony Harris

1 0