Bruce, I do agree with much of what you have stated in your e-mail with respect to the GNSO's role. However, I would like to clarify that that the introduction of registry services is not a policy matter within the scope of the GNSO. Such a policy (or even if you believe a lack of policy) is governed by the contracts and not through the GNSO policy process. This is what the parties (ICANN and the registries) negotiated during the contract negotiations in 2001. Although the parties (ICANN and the registries) may agree to change the contracts, the GNSO, even if it has the consensus of every constituency, may not. I would be happy to answer any questions about the contracts, but I would recommend sticking to Bruce's recommendation. Thanks. Jeff -----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Wednesday, September 24, 2003 8:15 PM To: council@gnso.icann.org Subject: [council] Role of council with respect to Agenda Item 4 Hello All, I would just like to remind the Council that GNSO is "responsible for developing and recommending to the ICANN Board substantive policies relating to generic top-level domains" (taken from the ICANN bylaws, Article X, section 1) In discussed agenda item 4, it is not the GNSO's role to make a decision with respect to whether the Verisign service complies with the existing contracts or policy. That is a role for the ICANN staff with advice from the ICANN General Counsel. It is also not the GNSO's role to make decisions with respect to whether it affects the security and stability of the Internet - that is the role of the Security and Stability Advisory Committee. Given advice from the ICANN General Counsel as to whether the issue is covered by the existing contracts, and given the advice from the Security and Stability Advisory Committee, the GNSO should consider whether the issue being discussed in agenda item 4 highlights a "need" for additional policy. The possible areas of additional policy include: - developing a policy for the introduction of new registry services (e.g relating to what circumstance is approval required from ICANN, and what sort of notice periods should be required) - developing a policy around the introduction of wildcard entries to gtlds (note .museum already has a wildcard entry as part of their agreement with ICANN) My recommendation for agenda item 4 is that we keep the discussion focused on the issues for which the GNSO is responsible for, and also consider whether we need to formally support the actions already taken by ICANN and the Security and Stability Committee. I believe in the past we have taken this approach with respect to the ccNSO, where we have supported the creation of a ccNSO and the recent decisions made by ICANN with respect to the ccNSO. If we believe there is a need for new policy, then we should consider formally commencing the policy development process at the next GNSO Council meeting. The GNSO should primarily be focussed on how to avoid problems in the future. Regards, Bruce Tonkin