February 2006 - council - lists.icann.org

Re: [council] Washington meeting
by Suzanne Sene Feb. 15, 2006

Feb. 15, 2006

hi glen, and thanks for the heads up. i am not sure whether my presence would be required/helpful, so am going to hold off a decision pending the agenda. also fyi, and apologies, i am not sure i can be on the call tomorrow, as i have a calendar conflict. cheers, suz. Suzanne R. Sene Senior Policy Advisor NTIA/OIA 202-482-3167 (ph) 202-482-1865 (fax) >>> "GNSO.SECRETARIAT(a)GNSO.ICANN.ORG" <gnso.secretariat(a)gnso.icann.org> 2/15/2006 10:18 AM >>> [To: council[at]gnso.icann.org] Dear Council Members, Please find some details for the Washington meetings. A more detailed agenda to follow. Schedule: 9am - 6pm on Friday 24 February 2006 8:30am - 3pm on Saturday 25 February 2006 Location: 2nd floor Look for the sign on the door of the conf room: "ICANN GNSO Council working session" 1133 21st Street, N.W., Washington, DC Some nearby hotels: M Street * managed by Marriott * ¾'s block away http://marriott.com/property/propertypage/WASRW 1143 New Hampshire Avenue NW Washington, District Of Columbia 20037 USA Phone: 1-202-775-0800 Fax: 1-202-331-9491 Wireless in the sleeping rooms Marriott on 22nd * about 2 blocks away http://www.thecapitol.net/MapsAndDirections/marriottwestenddc.htm Marriott Washington 1221 22nd Street NW Washington, DC 20037 Phone: 202-872-1500 Guest Fax: 202-872-1424 To reserve a sleeping room, contact the hotel directly. Wireless in the lobby, high speed connections in the sleeping rooms St. Gregory * ½ block away* http://capitalhotelswdc.com/StGregoryHotelWDC_com/ 2033 M STREET, NORTHWEST, WASHINGTON, DC 20036 - (202) 530-3600 (800) 829-5034 PH - (202) 466-6770 F High speed connections in sleeping rooms, no wireless. All are in the neighborhood of $200, and all are nice. Negotiated rates are only available if 15 rooms can be gauranteed so this has not been an option. Please book soon. Thanks and see you there! Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

RE: PDP on new gTLDs - draft Initial Report
by Olof Nordling Feb. 15, 2006

Feb. 15, 2006

Dear Council Members, Please replace the previously sent draft with the attached document. Very minor differences, but this is the correct one. Apologies for spamming you. Best regards Olof _____ From: Olof Nordling [mailto:olof.nordling@icann.org] Sent: Wednesday, February 15, 2006 8:49 PM To: 'council(a)gnso.icann.org' Subject: PDP on new gTLDs - draft Initial Report Dear Council Members, Please find a draft Initial Report attached for our work on the New gTLD PDP. As agreed, it is intended to be an evolving draft, to be successively updated as work progresses within the GNSO as well as in interaction with other SOs and ACs and the wider community. Very best regards Olof Olof Nordling Manager, Policy Development Coordination ICANN 6 Rond Point Schuman, Bt.5 B-1040 Brussels, Belgium Tel.: +32.2.234 7872 Mobile: +32.475.420805 Fax: +32.2.234 7848 E-mail: olof.nordling(a)icann.org <http://www.icann.org> www.icann.org

1 0

Re: [council] Washington meeting
by Marilyn Cade Feb. 15, 2006

Feb. 15, 2006

Excellent! -----Original Message----- From: "GNSO.SECRETARIAT(a)GNSO.ICANN.ORG" <gnso.secretariat(a)gnso.icann.org> Date: Wed, 15 Feb 2006 16:18:44 To:council@gnso.icann.org Subject: [council] Washington meeting [To: council[at]gnso.icann.org] Dear Council Members, Please find some details for the Washington meetings. A more detailed agenda to follow. Schedule: 9am - 6pm on Friday 24 February 2006 8:30am - 3pm on Saturday 25 February 2006 Location: 2nd floor Look for the sign on the door of the conf room: "ICANN GNSO Council working session" 1133 21st Street, N.W., Washington, DC Some nearby hotels: M Street – managed by Marriott – ¾’s block away http://marriott.com/property/propertypage/WASRW 1143 New Hampshire Avenue NW Washington, District Of Columbia 20037 USA Phone: 1-202-775-0800 Fax: 1-202-331-9491 Wireless in the sleeping rooms Marriott on 22nd – about 2 blocks away http://www.thecapitol.net/MapsAndDirections/marriottwestenddc.htm Marriott Washington 1221 22nd Street NW Washington, DC 20037 Phone: 202-872-1500 Guest Fax: 202-872-1424 To reserve a sleeping room, contact the hotel directly. Wireless in the lobby, high speed connections in the sleeping rooms St. Gregory – ½ block away… http://capitalhotelswdc.com/StGregoryHotelWDC_com/ 2033 M STREET, NORTHWEST, WASHINGTON, DC 20036 - (202) 530-3600 (800) 829-5034 PH - (202) 466-6770 F High speed connections in sleeping rooms, no wireless. All are in the neighborhood of $200, and all are nice. Negotiated rates are only available if 15 rooms can be gauranteed so this has not been an option. Please book soon. Thanks and see you there! Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org Regards, Marilyn Cade

1 0

Re: [council] GNSO Council meeting proposed dates
by Your Name Feb. 15, 2006

Feb. 15, 2006

OK with me Tony Harris > Dear Councillors, > > These are proposed dates for Council meetings till the Vancouver meetings. > > Thursday 28 July 12:00 UTC > Thursday 18 August 12:00 UTC > Thursday 21 September 12:00 UTC > Thursday 20 October 12:00 UTC > Wednesday 16 November 19:00 UTC > > Please let me know if you have any questions. > > Thank you very much. > Kind regards, > > Glen > > -- > Glen de Saint Géry > GNSO Secretariat - ICANN > gnso.secretariat[at]gnso.icann.org > http://gnso.icann.org > > --

4 5

GNSO Council revised draft minutes 17 January 2006
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Feb. 15, 2006

Feb. 15, 2006

[To: council[at]gnso.icann.org] Dear Council members, Please find the revised draft GNSO Council minutes of 17 January. The reason for the 8 council members not voting has been added for the record. Please let me know if ther are other changes you would like made. Thank you very much. Kind regards, Glen 17 January 2006 Proposed agenda and related documents List of attendees: Philip Sheppard - Commercial & Business Users C. Marilyn Cade - Commercial & Business Users C. Grant Forsyth - Commercial & Business Users C Greg Ruth - ISCPC - absent - apologies - proxy Tony Holmes Antonio Harris - ISCPC - absent - apologies - proxy Tony Holmes Tony Holmes - ISCPC Thomas Keller- Registrars Ross Rader - Registrars Bruce Tonkin - Registrars Ken Stubbs - gTLD registries June Seo - gTLD registries - absent Cary Karp - gTLD registries Lucy Nichols - Intellectual Property Interests C Ute Decker - Intellectual Property Interests C Kiyoshi Tsuru - Intellectual Property Interests C. - absent Robin Gross - NCUC. Norbert Klein - NCUC. - absent Mawaki Chango - NCUC Sophia Bekele - Nominating Committee appointee Maureen Cubberley - Nominating Committee appointee Avri Doria - Nominating Committee appointee 16 Council Members ICANN Staff Olof Nordling - Manager, Policy Development Coordination Maria Farrell - ICANN GNSO Policy Support Officer Liz Williams - Senior Policy Counselor Tina Dam - Chief gTLD Registry Liaison Glen de Saint Géry - GNSO Secretariat Invited Guests John C. Klensin Patrik Fältström GNSO Council Liaisons Suzanne Sene - GAC Liaison Bret Fausett - ALAC Liaison Michael Palage - ICANN Board member Quorum present at 19 :10 UTC. MP3 Recording Bruce Tonkin chaired this teleconference. Approval of the agenda Item 1: Approval of minutes - GNSO Council Vancouver meeting minutes 28 November 2005 - GNSO Council Vancouver meeting minutes 2 December 2005 - GNSO Council teleconference minutes 21 December 2005 Ken Stubbs, seconded by Maureen Cubberley moved the adoption of all 3 sets of minutes. Motion approved. Ken Stubbs and Maureen Cubberley recorded an abstention for the minutes of 21 December 2005, Ute Decker, Sophia Bekele, Mawaki Chango recorded abstentions for all the minutes. Decision 1: the GNSO Council minutes of 28 November 2005, 2 December 2005 and 21 December 2005 were adopted. Item 2: Update on new gTLD policy development process - advise constituency representatives Philip Sheppard would collect the constituency input for the Commercial and Business Users constituency. Ken Stubbs would collect the constituency input for the gTLD registries constituency and reported that the constituency was making progress with the statements. Caroline Chicoine would collect the constituency input for the Intellectual Property Interests constituency who were working on a draft. Mark McFadden would collect the constituency input for the Internet Service and Connectivity Providers constituency who were working on a draft. Ross Rader would collect the constituency input for the Registrars constituency who had started work. The Non Commercial Users constituency started work but had not yet appointed someone to collect the input. Bret Fausett would be the liaison to the GNSO on the issue and the At Large Advisory Committee had a 4 person task force working on drafting a response and feed back was also solicited from the At Large structures. Avri Doria reported that there were discussions in the civil society circles concerning the issue. Suzanne Sene reported that in Vancouver at the GAC Plenary there was agreement that the GAC would seek to develop principles for the introduction of new gTLDs and a draft could be expected by the Wellington meetings. Item 3: Update on WHOIS policy development - preliminary report on purpose of WHOIS http://gnso.icann.org/issues/whois-privacy/draft-Whois-preliminary.pdf - current work Maria Farrell reported that the Preliminary task force report on the purpose of Whois had been circulated to the task force for a vote at the task force meeting on 18 January, 2006 and would then be posted for 20 days public comment. The GNSO report to the ICANN Board on the GNSO's 'Recommendation for a Procedure for Handling Conflicts between a Registrar/Registry's Legal Obligations under Privacy Laws and their Contractual Obligations to ICANN' would be published for information on the ICANN website. Item 4: IETF draft on IDN issues Patrik Fältström and John Klensin joined the call. John Klensin summarising the IETF draft on IDN issues said that an ad hoc committee, appointed by the Internet Architectural Board (IAB) had been examining the general IDN situation for several months but it was a slow process because the committee was so diverse. The document would undergo significant changes, and it was impossible to predict how the IAB would react. Versions 1 and 2 would be brought in line with additional references and terminology, objections would be noted and discussions had clarified important issues with the inferences that should be drawn from them. If the liberal and unrestricted definitions of the standard providers on constraints were heeded, then it would be extremely easy for careless or malicious people to cause confusion, or fraud. Symptomatic of this phenomenon were the incidences in the spring, which ICANN was warned about 3 – 4 years ago. The work of the ad hoc committee and other groups had shown details, which were included in the IDN briefings during the ICANN meetings in Luxembourg and Vancouver 2005. When considering sophisticated means of preventing confusion, the user, as well as the registry and registrar communities had a tendency to look at the DNS strings and labels and see words - words in whatever languages they were most familiar with or wanted to speak. Seeing words in these strings was problematic as either assumptions, which might or might not be true, were made about the present characters and scripts, or assumptions were made about what ought to be permitted or claims were made about rights to permit elements which the DNS would not sustain. The problem ran afoul of applications' implementers who were protective of their users applying their own rules on what names were valid or invalid. This could lead to further problems of a registry or registrar selling a name and a registry registering a name that can not be resolved because the application designer deems it too dangerous or will not resolve or display the name. These issues were explored in the report and recommendations made to the IETF for modifying the protocol. There is a general principle that anything not restricted in the protocol will be used somewhere in the DNS. From discussions with the applications area directors about issues, it would seem reasonable to assume some Internet Engineering Steering Group (IESG) action but not in so far as what the IETF has written is not interoperable or written in such a way that the designers consider satisfactory. Bruce Tonkin commented that looking at the combination of the IDNA and the ICANN guidelines, there were degrees of freedom with particular characters, character equivalence tables etc. which led to two issues: - with different registries it made it difficult for an application designer because of changes over time - there were variations depending on which tld. John Klensin commented that the applications developers on the user application side should be differentiated from those on the registrar side where there was a problem. On the user side, in theory, unless the application developer decided that they had a higher obligation to protect their users above and beyond what the protocols specified, then all the application developer needed to do was to follow the standard and look up those things. No one committed to the global interoperability of the DNS, had suggested anything about per zone or per TLD rules which would change the look up rules. For the application designer, designing an application to look something up, the only issue was whether it could be found or not. Any restrictions, applied by the ICANN guidelines or other rules, including the JET guidelines in Chinese, Japanese and Korean, pertained to what was registered, not to the interpretation. The rules provided a way to bind names together, so if there were a potentially confusing pair or triplet of names, the rules provided a formal way to find the pair or triplet and provided a rule for the registry that if one of them were registered, the other could not be registered or if one were registered, the other could only be registered by the same registrant. Nothing on the look up side changed the interpretation of a name. However, there were propositions for violating the standards by changing the lookup rules which would only result in the fragmentation of the Internet. The registrar side caused concern as different registries applied different rules. The registrars might have to know which registry they were dealing with to know which rules to apply or to be able to predict the registry behaviour. However, this is an existing problem. This illustrates a situation where IDN makes everything worse by adding tens of thousands of characters, depending on how 36 or 60 odd characters would be counted that could be currently registered. Ross Rader commented that in section 4. Specific Recommendations for Next Steps policy and technical implications had not been sufficiently disentangled for bodies such as the GNSO Council or the IETF to continue further work. John Klensin responded: "If somebody made me king, I could tell you who ought to be doing it but no one is likely to do that." However he did suggest that depending on the position the IAB would take, stronger recommendations could be made. At the policy level there were two issues: country code registries would be affected as much as the gtld registries by IDN issues and while in principle if the GNSO Council reached agreement confirmed by the Board, gTLD behaviour could be mandated but not cctld behaviour. These problems should be confronted in cooperation and participation with other affected bodies. Rather than developing policy in the traditional sense, there should be agreement about what constitutes safe and unsafe practices followed by a clear concept and responsibility for the policy. For example, if a ccTLD were to adopt extremely liberal policies about registrations, countries with consumer protection in their political cultures would presumably come down on those registries in a less ambiguous way and with more authority, than ICANN could do. This is a new area for ICANN and the community which still needs clarifying. Patrik Fälström commented that in section 4 the IAB explicitly listed and compiled the issues in a way that had not been done before without identifying who should take care of each concern. Many of them were overlapping and should be taken into consideration by the IETF, ICANN policy work, application developers in writing applications, and the Intellectual Property Rights community looking at dispute resolution processes. The IAB was concerned that each organisation tried to solve their piece of the puzzle and assumed that the other pieces were taken care of by someone else. It is hoped that the IETF and ICANN, or similar organizations with overlapping or touching pieces of the puzzle could work together toward a total solution. The IAB is not expected to be more specific nor is that the goal of section 4 in the paper. John Klensin added a personal observation that any claim made by a person or organisation, to have the entire picture and decide boundaries, did not understand the problem and should not be trusted. The report lists elements under separate headings, but in fact they are not separable. Patrick Fältström cited an example from inside the IETF, where there was the potential for reissuing a new work group within the IETF, whom most believed fell into the DNS protocol and more traditional uses of the DNS but currently the stringprep and various kinds of algorithms were found in other places, which indicated that even inside the IETF there are multiple different working groups in different areas with various kinds of dependencies that were not found in a traditional DNS registry to registrar setting. Thus it is important to list all the issues so that each group is aware and as such section 4 of the report is important work. Sophia Bekele asked about the role of ICANN and registrars in the testbed and what it would achieve. John Klensin responded that he did not recommend the test bed, was involved peripherally in the formulation of the IDN guidelines and was not on the President’s IDN committee where these initiatives were coming from. Several issues were involved, in contrast to a year ago there was the assumption in the standard that if an IDN showed up as visible in an IDN aware application, that it would be displayed in the characters people would expect to see. For example: if the IDN showed up in Cyrillic or Chinese, there would be Cyrillic or Chinese characters on the screen. Currently it was not the case as browser vendors were differentiating between registries which displayed registration data to prevent confusion and as a consequence displayed their IDNs in native script form, and registries that were negligent and therefore browser vendors did not display their IDNs anywhere in the tree underneath the TLD in native character form. In such situations, whatever the standard is, until it conforms and is acceptable to application developers, they will be looking at the registries' behaviour and deciding what names can be displayed. As has been pointed out in the past, if there were a poor user or company dealing with an ASCII transliteration of its name for years and hating it, going to that user and proposing an improvement by replacing it with something that appeared on their screen like a series of characters would have low appeal. ccTLD Registries have an easier case than the gTLD registries in that they deal with, and make decisions about a relatively small number of scriptal languages. Whereas, with gTLDs it would be bad if ICANN were to discriminate against one language or another and how that would evolve would be up to the GNSO. Different registries making different registry policies is not new except that IDNs pose more opportunities for variation, confusion and scale. The IDN .IDN situation is a different complicated issue where John Klensin even rejected the use of the terminology. A tld registered in non ASCII character in the next level domain registered under that tld will be a non ASCII character possibly even in the same as the top level one assuming that the top level is in a homogeneous script . The original IDN committee suggested that new IDN tlds should be applied for as if they were new tlds with strange names. If ICANN were to adopt such policy then certain concepts about IDN tlds bound to countries would drop away. If the notion of IDN tlds bound to countries, as separate tlds rather than as an alias, were adopted different problems would arise. One of the advantages would be in the approval process, as no new tlds would be approved except for those already in the cue. The cue would build up in part by entrepreneurs discovering some countries could be persuaded to apply for an IDN tld in their name which would create a series a of new country code domains run as gTLDs without any restrictions and resulting in an entirely different situation. Are experiments necessary? Mechanically it is known that IDNs work and that the DNAME alias works with restrictions. Questions arise in implementation and if there were restrictions what they would mean in terms of the root server performance. Little is expected to be learnt by experiments. Cary Karp commented that problems could be avoided if the complex of issues were segmented and proper cross participation among the various groups was in place. What should be the GNSO council's role in assuring IDNs in the entire name space demonstrating technical capability before competition issues were addressed? John Klensin responded that GNSO and country code issues could not be isolated and ICANN should be sensitive that responsible behaviour was the key factor and discourage irresponsible behaviour. There were strong arguments for moving conservatively and the GNSO should take the lead in caution. The question arises whether there is the right to register a name in a given domain based upon a synonym or a translation of that name in the same or another string in the same domain. For example: Assume a registrant registrars General motors .com. General and motors are words translatable into a number of languages, thus would it be possible in .com to register the Russian equivalent of general and motors together as a name and would that constitute an issue to be handled by dispute resolution or some other way? Marilyn Cade asked whether the present or future gtlds strings should be allowed to be registered in all of the different IDN options. John Klensin stated that there were several separate problems. A distinction should be made between registering an alias for a name, the so called DNAME synonym, versus registering a different domain with that name. The difference is that if one puts in a Chinese synonym for com as a DNAME, pointing to the com domain at the second level, what appears to user with that synonym are going to be re registrations in com as there there is only one tree. If one does that there are a lot of reasons why those synonyms are not a good idea or do not solve the problem, but in terms of the particular issue of synonyms versus separate domains are quite safe. Another answer has to do with registering separate domains associated with names with the tlds. It is important to keep in mind that they are really separate domains no matter what they are called. The second problem is registering a second domain to what their synonyms are in another language, is with the exception of a very small number of tlds of which .museum is currently the striking example, travel may be next, that none of those tld names are names in any language, they are abbreviated strings. If com and biz were translated into Swahili it is not clear that there would be 2 names the same causing a conflict problem also possible in the alias case of opportuning the whole net synonym which opens up other problems at the top level. Bruce Tonkin commented that the General Motor example could be related to trade marks. John Klensin commented that it was one of the areas where the tradition of the trade mark field confined to countries and areas application did not work very well with the DNS. With the translations, whether it is a trademark or not may be the same issue as when something becomes confusing or not to the user. Lucy Nichols commented that trademark law broke down to national laws and according to the trademark. Famous trademarks may have a broader protection and may cover translations as well but was not the case across the board. John Klensin commented that stepping away from Indo European languages when using roman scripts and translating the little prints into some language in which the characters and page looked different, the pronunciation was not recognised, questioned whether any UDRP policy or decision would apply in conflict with top level domains. John Klensin emphasised that since the IDNs were technically, culturally and linguistically complicated issues the GNSO Council should to educate itself on the details rather than make assumptions about how things ought to work. A new sub section of section 4 was expected in the next draft which would point back to the Whois problem. There were complex issues between the IDNs, data bases that looked at ancillary information by registrars and the WHOIS problem. The IDN issue should be viewed in principle, as a system rather than as a text or cultural or language or IPR problem and should be considered in every policy. Bruce Tonkin thanked John Klensin and Patrick Fälström for bringing together the IDN issues in the report and proposed that there should be further discussions on IDNs and constrained IDNs, no tld with a "hyphen" for example, should be introduced at the root to begin with so as to minimise some of the issues highlighted Item 5: Update on status of proposed .com agreement Olof Nordling reported that there was no update on the proposed .com agreement and did not have further information. Michael Palage reported that the ICANN Board at its meeting on 10 January, did not get to the specific line item on the agenda. Ross Rader noted disappointment that there was no staff update on the .com agreement. Bruce Tonkin proposed formally requesting General Counsel for a report on the next steps. Grant Forsyth was concerned that the council had expressed its views but it appeared that the action on dotCOM was continuing without any guidance from council. In view of the situation, he posed 2 questions: - which staff member should have been on the call to inform council - what advice would be useful for the ICANN Board and staff, as further input on matters of policy would be useful to develop policy guidelines for the contracts? Item 6: Next steps on policy issues related to proposed .com agreement E.g - policy for renewal of gtld agreements - funding model policy (possible new policy) - policy for capping fees that a registry can charge - exclusions in agreements from future consensus polices or changes in consensus polices Philip Sheppard reminded the council of the resolution taken during the GNSO Council meeting on 2 December 2005 and urged council to proceed with analysing the issues and requesting an issues report. Whereas the GNSO constituencies participated in a review of the proposed settlement and have detailed statements on issues of concern; Whereas the GNSO Council supports the conclusion of the litigation between ICANN and Verisign; Whereas the GNSO Council does not support all articles within this proposed settlement; Whereas the GNSO Council believes that there are broader questions raised in the proposed settlement that need to be first addressed by the GNSO; The GNSO Council resolves: That the ICANN Board should postpone adoption of the proposed settlement while the Council fully investigates the policy issues raised by the proposed changes. Bruce Tonkin clarified the difference between a process and the outcomes of that process. In the agreements there was a specified process by which by certain dates, renewal proposals were required to be created and that the discussion did not concern changing this process. The concern arose because the dotCOM agreement was posted 4 weeks before the widow opened on the dotCOM renewal process and responses were required in less time than was permitted thus the specified time for the process should be followed. Marilyn Cade stated that the Commercial and Business Constituency took the resolution very seriously and would support the idea of seeking independent expertise, chartering an issues report focusing on the areas where there appeared to be broad community agreement from the Vancouver workshop input and constituency statements, on the major problems relating to the dotCOM agreement. These included the policy for presumptive right of renewal, the funding model,the policy change that was inherent in the agreement, the traffic data ownership and control issue and exclusion to consensus policy. Marilyn proposed providing an issues report, developing a timeline and that council would agree to hold a face to face meeting in the third week of February 2006, to devote considerable time to the issue and incorporate taking public comment at such a meeting. Marilyn emphasised the need to develop a timeline that delivered, if not final policy, advanced policy by the Wellington meeting. Marilyn clarified that the face to face meeting would use online tools and a conference approach for councillors not able to attend, public comments would be solicited and shortly after the meeting, draft policy recommendations arising from the issues report and the terms of reference would be published. In summary, the important issue was the need to develop the policy and to implement what had been resolved by the council. Grant Forsyth proposed engaging outside expertise to develop an issue report with the task of identifying issues of policy development related to the proposed .COM agreement. Once the issues are identified in an independent manner Council would have the possibility of progressing the issues in a helpful manner for the Board prior to concluding a .com agreement. Grant Forsyth clarified that he had suggested external expertise for the reason that Olof Nordling explained the difficulty he had in engaging on the subject with the council. Bruce Tonkin clarified two issues: i if the council were choosing to commence a policy development process, a motion was needed to request an issues report which only required 25% of the votes to pass the motion. - if that were agreed upon, the next issue was resources. ii the second issue concerned the implementation, would staff provide the report or would council call upon external expertise and if the latter, was there an available budget. Grant Forsyth, seconded by Lucy Nichols proposed: That the Council solicit an Issues Report related to the dot COM proposed agreement in relation to the various views that have been expressed by the constituencies. A roll call vote was taken and the motion passed. 13 votes in favour, Marilyn Cade, Philip Sheppard, Grant Forsyth, Lucy Nichols, Robin Gross, Mawaki Chango, Maureen Cubberley, Avri Doria, Sophia Bekele, Bruce Tonkin (2) Ross Rader (2), 4 abstention votes, Cary Karp (2) Ken Stubbs (2), 8 council members did not vote: Ute Decker (disconnected at time of vote, no proxy), Kiyosho Tsuru (absent no proxy), Tony Holmes (not on call at time of vote), Tony Harris (Tony Holmes, not on call at time of vote, could not vote proxy for Tony Harris), Greg Ruth ((Tony Holmes, not on call at time of vote, could not vote proxy for Greg Ruth), Norbert Klein (absent, no proxy), Tom Keller (2) (disconnected at time of vote, no proxy), June Seo (2) (absent, no proxy). Decision 2: That the Council solicit an Issues Report related to the dot COM proposed agreement in relation to the various views that have been expressed by the constituencies. Grant Forsyth seconded by Lucy Nichols proposed Given the shortness of time, and the potential conflict within the staff, that the council seek external expertise in the development and presentation of an issues report. Marilyn Cade proposed 2 friendly amendments: recognising that while there may be potential conflicts for the staff, no negative comment was being made about the staff recognising that there was no budget for this, that council proceed with authorising the expenditure of its reserve funds, or soliciting contributions through the constituencies. Bruce Tonkin proposed, and there was general agreement from the council, that staff should inform the council whether they could meet the request for an issues report and proposed consulting with staff on the issue, and if necessary, calling another meeting in one week. Bruce Tonkin declared the GNSO meeting closed and thanked everybody for participating. The meeting ended: 21:40 UTC. Next GNSO Council teleconference 6 February 2006 at 19:00 UTC see: Calendar -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb
by Bruce Tonkin Feb. 14, 2006

Feb. 14, 2006

Hello All, As agreed during our teleconference on 6 Feb 2006, the meeting in Washington will be for the Committee working on the new gTLD policy development process. The Committee is of the whole Council, but where a Council member cannot attend, they may nominate another person from their constituency to participate. The constituency/Council member should inform the GNSO Secretariat of such a nomination prior to the meeting. I am hoping that Olof will be able to at least have a draft Initial Report that summarises the constituency input, the papers that have been submitted in response to our call for papers, and the public comments submitted via the ICANN website. The aim of the meeting will be to consider this report and identify areas of consensus. We are essentially operating under the provisions of section 8(b) and 8(c), of Annex A of the ICANN bylaws. One thing we did not cover in the Council call, was whether to hold an open public forum. Given that there were a few Council members that were against this idea, and also given the additional logistics and costs of arranging such a forum, I suggest instead that we follow up on our call for papers on 3 January 2006: http://www.icann.org/announcements/announcement-03jan06.htm . In that call for papers we stated: "Received papers will be considered for oral presentations to the GNSO Council during February 2006, via scheduled conference calls with the GNSO Council." We could simply set up a conference bridge to allow selected authors of papers to call-in, and where cost is an issue we can call-out to appropriate people. Please let me know if you agree with this approach, and also please identify any particular papers where you think it would be beneficial for the author to present a summary of the paper orally and respond to questions. I will also ask Olof to review the received papers with this in mind. Glen can then contact the authors and see who may be available (we may have to schedule time appropriate to the time zones of the authors). I think it is important to ensure future substantial contributions to the policy development process, that the Committee gives significant attention to considering these submissions - and doesn't simply rely on reading a staff summary. Regards, Bruce Tonkin

5 4

GNSO Council call this week
by Maria Farrell Feb. 14, 2006

Feb. 14, 2006

Dear all, Glen is having connectivity difficulties today, so I am sending you this reminder of the GNSO Council call to be held later this week, on Thursday 16 February. We don't have the facility to send automated reminders with the call-in details and do not broadcast them to the list, so please be aware that the call-in details are the same as for the last Council call, held on February 6. If you don't have a record of the call-in details, please email me and I'll send you them directly. There will be a GNSO Council teleconference on Thursday, 16 February, 2006 at 19:00 (7:00 pm) UTC. (11am Los Angeles, 2pm Washington DC, 4pm Buenos Aires, 7pm London, 8pm Brussels, 2am Phnom Penh (next day) 6am (next day)Melbourne ) The agenda is as circulated by Bruce Tonkin, below. All the best, Maria Draft Agenda for Council meeting - Thursday 16 February 2006 Coordinated Universal Time UTC 19:00 (11am Los Angeles, 2pm Washington DC, 7pm London, 6am (next day) Melbourne ) Item 1: Approval of minutes of 17 January 2006 <http://www.gnso.icann.org/mailing-lists/archives/council/msg01961.html> http://www.gnso.icann.org/mailing-lists/archives/council/msg01961.html Item 2: Commencement of PDP initiated in the meeting of 6 Feb 06 [PDP-Feb06] - Declare any statement of interest relevant to this issue - Decide whether to appoint a task force to address the issue (Under the provisions of section 4 of Annex A of the ICANN bylaws) Item 3: Terms of reference for PDP-Feb06 - Decide the terms of reference for the PDP (Under the provisions of section 7(b) of Annex A of the ICANN bylaws) <http://www.gnso.icann.org/mailing-lists/archives/council/msg02005.html> http://www.gnso.icann.org/mailing-lists/archives/council/msg02005.html Item 4: Any other business

2 1

RE: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb
by tony.ar.holmes＠bt.com Feb. 13, 2006

Feb. 13, 2006

Marilyn That's helpful and gives us some more options - thanks. Early sight of the schedule is also required though, to make this work. Tony -----Original Message----- From: Marilyn Cade [mailto:marilynscade@hotmail.com] Sent: 12 February 2006 23:25 To: Holmes,AR,Tony,CXM R; council(a)gnso.icann.org Cc: bruce.tonkin(a)melbourneit.com.au Subject: RE: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb As I understand the plans, all constituencies can substitute members for elected councilors. It would be good to have any of the councilors on the phone/conference to the extent possible - even if not for the full time slot [the BC certainly doesn't expect Grant and Philip to be on the call for both full days if they are not here in person].I understand that Glen is arranging for dial out/or dial in, recognizing the expense to a councilor to dial in for several hours. Since I'm organizing logistics with Glen for the meeting, I wanted to just note that we should have a very well developed agenda, and keep to it, so that councilors - remote - can pick and choose their times on the call. For instance, for presentations from various parties, councilors might choose to read the transcript, rather than stay online for 3 hours. But choose to be online while there is a discussion of policy options. Etc. Marilyn _____ From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of tony.ar.holmes(a)bt.com Sent: Sunday, February 12, 2006 5:51 PM To: tony.ar.holmes(a)bt.com; marilynscade(a)hotmail.com; council(a)gnso.icann.org Cc: bruce.tonkin(a)melbourneit.com.au Subject: RE: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb Bruce/Marilyn Seeing Marilyn's note below I thought it appropriate to advise you that the timeframe set for the Washington meeting is proving particularly difficult for the ISPCP. Whilst we are actively pursuing options that will hopefully result in ISPCP participation, it is quite likely that none of the ISPCP Council members will be able to travel to Washington. Within the ISPCP there are no perceived problems in allowing formally agreed representatives to speak for the Constituency, so I hope that will be taken into consideration as rules are defined for that meeting. Regards Tony -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Marilyn Cade Sent: 10 February 2006 22:49 To: 'Council GNSO' Cc: 'bruce tonkin' Subject: RE: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb Dear Bruce, I respectfully request that some portion of the Washington meeting be focused on discussing the ToR and PDP for the policy issues in registry contracts, especially because there is a need to respond to existing gTLD contracts that are under discussion or posted for public comment. I'd ask that we set aside a minimum of 2 hours for this discussion and that we give special attention to the timing of that discussion so that the New Zealand BC representative and any other of time zone challenged councilors who are committed to dial in for a segment or two of the meeting, are not terribly disadvantaged. I leave time management/translations to our capable Secretariat. Here is my concern: I note that when I made the motion FOR the meeting, I specifically asked that we address this set of issues. Subsequently, the Chair posted a suggestion that we address two topics in the meeting. I fully supported that. However, somehow the meeting has morphed into only addressing the new gTLD policy development PDP, and I strongly prefer to have a set amount of the time focused on the second and time sensitive PDP just agreed. I would expect we will be approving the relevant ToR on the Council call on 2/16, so a 2 hour discussion on methods, how to best proceed, etc. seems critical to include in the working group/session in Washington. And, given the intervening days between Monday and 2/24 or 2/25, we can certainly expect each of the constituencies to consult within themselves on the options. To accommodate that many councilors are not going to be in person, we could identify/explore options for organizing the work, and the various approaches of how to best progress the work, any needed information or resources, etc. and post them for discussion on the Council list. Time lines for completing the work should also be discussed. I have a concrete proposal for how to manage the work and I'd propose that others give thought as well to options: I propose that the second PDP be worked as a modified TF. I had previously supported the Council working as a Committee of the Whole of Council. However, I've spoken with several councilors, and I suggest that following adaptation: Create a Council working group all councilors, but, allow each Constituency to substitute Constituency members for Councilors, so long as there is a minimum of one councilor from each constituency, for a total of three per constituency. Other members would be the liaisons from the ACs, and the NomComm members. Rationale: The two PDPs are quite interlinked, and it is essential for the full understanding of the Council of the discussions and examinations of the policy issues on PDP on contractual issues in existing registry contracts [or whatever we call it] and of the policy issues and explorations being undertaken in new GTLD policy PDP. I understand that some constituencies may want to appoint constituency members, but that may not the case for all constituencies... and this will allow flexibility. Also, should some constituencies want to have three reps, and some only two, or even one, that can be balanced by simply giving all constituencies the same number of votes on the Council Working Group/TF. As we all recall, votes are singular, and not "weighted" in the PDP working process. Marilyn Cade BC Councilor -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Mawaki Chango Sent: Friday, February 10, 2006 7:43 AM To: Council GNSO Subject: Re: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb Hello, --- Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au> wrote: > Hello All, > > As agreed during our teleconference on 6 Feb 2006, the meeting in > Washington will be for the Committee working on the new gTLD policy > development process. The Committee is of the whole Council, but > where a > Council member cannot attend, they may nominate another person from > their constituency to participate. The constituency/Council > member > should inform the GNSO Secretariat of such a nomination prior to > the > meeting. > I have also understood that each constituency could send up to 3 delegates to the meeting - is that correct? is this also a feature of the "Committee of the whole Council", or was it part of the earlier D.C meeting package :) or formula? Mawaki > > > Regards, > Bruce Tonkin > > > >

1 0

RE: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb
by tony.ar.holmes＠bt.com Feb. 12, 2006

Feb. 12, 2006

Bruce/Marilyn Seeing Marilyn's note below I thought it appropriate to advise you that the timeframe set for the Washington meeting is proving particularly difficult for the ISPCP. Whilst we are actively pursuing options that will hopefully result in ISPCP participation, it is quite likely that none of the ISPCP Council members will be able to travel to Washington. Within the ISPCP there are no perceived problems in allowing formally agreed representatives to speak for the Constituency, so I hope that will be taken into consideration as rules are defined for that meeting. Regards Tony -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Marilyn Cade Sent: 10 February 2006 22:49 To: 'Council GNSO' Cc: 'bruce tonkin' Subject: RE: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb Dear Bruce, I respectfully request that some portion of the Washington meeting be focused on discussing the ToR and PDP for the policy issues in registry contracts, especially because there is a need to respond to existing gTLD contracts that are under discussion or posted for public comment. I'd ask that we set aside a minimum of 2 hours for this discussion and that we give special attention to the timing of that discussion so that the New Zealand BC representative and any other of time zone challenged councilors who are committed to dial in for a segment or two of the meeting, are not terribly disadvantaged. I leave time management/translations to our capable Secretariat. Here is my concern: I note that when I made the motion FOR the meeting, I specifically asked that we address this set of issues. Subsequently, the Chair posted a suggestion that we address two topics in the meeting. I fully supported that. However, somehow the meeting has morphed into only addressing the new gTLD policy development PDP, and I strongly prefer to have a set amount of the time focused on the second and time sensitive PDP just agreed. I would expect we will be approving the relevant ToR on the Council call on 2/16, so a 2 hour discussion on methods, how to best proceed, etc. seems critical to include in the working group/session in Washington. And, given the intervening days between Monday and 2/24 or 2/25, we can certainly expect each of the constituencies to consult within themselves on the options. To accommodate that many councilors are not going to be in person, we could identify/explore options for organizing the work, and the various approaches of how to best progress the work, any needed information or resources, etc. and post them for discussion on the Council list. Time lines for completing the work should also be discussed. I have a concrete proposal for how to manage the work and I'd propose that others give thought as well to options: I propose that the second PDP be worked as a modified TF. I had previously supported the Council working as a Committee of the Whole of Council. However, I've spoken with several councilors, and I suggest that following adaptation: Create a Council working group all councilors, but, allow each Constituency to substitute Constituency members for Councilors, so long as there is a minimum of one councilor from each constituency, for a total of three per constituency. Other members would be the liaisons from the ACs, and the NomComm members. Rationale: The two PDPs are quite interlinked, and it is essential for the full understanding of the Council of the discussions and examinations of the policy issues on PDP on contractual issues in existing registry contracts [or whatever we call it] and of the policy issues and explorations being undertaken in new GTLD policy PDP. I understand that some constituencies may want to appoint constituency members, but that may not the case for all constituencies... and this will allow flexibility. Also, should some constituencies want to have three reps, and some only two, or even one, that can be balanced by simply giving all constituencies the same number of votes on the Council Working Group/TF. As we all recall, votes are singular, and not "weighted" in the PDP working process. Marilyn Cade BC Councilor -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Mawaki Chango Sent: Friday, February 10, 2006 7:43 AM To: Council GNSO Subject: Re: [council] Regarding meeting in Washington, DC - Friday 24 Feb and Saturday 25 Feb Hello, --- Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au> wrote: > Hello All, > > As agreed during our teleconference on 6 Feb 2006, the meeting in > Washington will be for the Committee working on the new gTLD policy > development process. The Committee is of the whole Council, but > where a > Council member cannot attend, they may nominate another person from > their constituency to participate. The constituency/Council > member > should inform the GNSO Secretariat of such a nomination prior to > the > meeting. > I have also understood that each constituency could send up to 3 delegates to the meeting - is that correct? is this also a feature of the "Committee of the whole Council", or was it part of the earlier D.C meeting package :) or formula? Mawaki > > > Regards, > Bruce Tonkin > > > >

2 1

RESEND Commencement of the new PDP
by Bruce Tonkin Feb. 11, 2006

Feb. 11, 2006

Hello again, That last email was a bit jumbled - my attempt to refer to Marilyn's text at the beginning of my last email failed. Here is a cleaner version of my response. Regards, Bruce Tonkin I recommend we follow the structure of the bylaws where we can. I think we could achieve your objective by doing the following: With reference to section 5(a), Annex A of the bylaws: "5. Composition and Selection of Task Forces a. Upon voting to appoint a task force, the Council shall invite each of the constituencies of the GNSO to appoint one individual to participate in the task force. Additionally, the Council may appoint up to three outside advisors to sit on the task force. (Each task force member is referred to in this Annex as a "Representative" and collectively, the "Representatives"). The Council may increase the number of Representatives per constituency that may sit on a task force in its discretion in circumstances that it deems necessary or appropriate." The Council could decide to appoint a task force for PDP-Feb06 with 3 voting representatives per constituency. The Council could also recommend that constituencies consider appointing one or more Council members to the task force to ensure linkage with PDP-Dec05. This will ensure that constituencies have some flexibility on how they choose to resource PDP-Dec05 and PDP-Feb06. Regards, Bruce Tonkin

1 0