<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [council] Role of council with respect to Agenda Item 4
- To: "'Bruce Tonkin'" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>, "'council@xxxxxxxxxxxxxx'" <council@xxxxxxxxxxxxxx>
- Subject: RE: [council] Role of council with respect to Agenda Item 4
- From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
- Date: Wed, 24 Sep 2003 23:04:27 -0400
- Cc: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
- Sender: owner-council@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, September 24, 2003 8:15 PM
To: council@xxxxxxxxxxxxxx
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|