ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

[council] Updated self-review doc - version 2.2

  • To: <council@xxxxxxxxxxxxxx>
  • Subject: [council] Updated self-review doc - version 2.2
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Thu, 2 Dec 2004 23:41:19 +1100
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcTYbDib81OBnQLpQVOthQDfQdaxgw==
  • Thread-topic: Updated self-review doc - version 2.2

Hello All

Attached is the latest version of the self-review document with the
addition suggested by Niklas.

Below is a plain text summary of the recommendations.

Regards,
Bruce Tonkin

10.1.   Required changes to ICANN bylaws
=======================================

10.1.1. Maintain the present 3 representatives per constituency

10.1.2. Adjust the bylaws to specify that the timelines in the policy
development process are guidelines, and allow the GNSO Council to set
and revise timelines according to the level of consensus on a particular
issue and the amount of volunteer and staff resources available for the
specific issue.


10.2.   Additional ICANN staff resources required
===============================================

10.2.1. Prior to the commencement of policy development on a particular
issue, ensure that ICANN staff provide an analysis and Issues Paper that
provides sufficient background and information to support the
development of the Terms of Reference and statement of work for a Task
Force.   .   The issue report should indicate how the issue is currently
handled within the existing contractual and policy framework.   In some
instances, it may be necessary for Council to agree to commission an
independent expert to analyse an issue (which may include interviewing
affected parties within the GNSO) and propose options for policy
recommendations that may address the issue.
.  
10.2.2. During the pubic comment process on a proposed policy
recommendation, an independent expert may need to be commissioned to
produce a report on the views of the GNSO community in relation to a
proposed policy recommendation.

10.2.3. Provide staff support to the task forces and GNSO Council
sub-committees that are skilled in creating reports that reflect the
input provided by members of Council, and clearly identify where the
areas of disagreement exist.

10.2.4. Provide staff support to the Task Forces and to the GNSO Council
subcommittees that familiarize themselves with the bylaws and the policy
development processes, as well as the relevant previous work of the
Council. 

10.2.5. Ensure that legal counsel is available for all GNSO Council
calls, and ensure that legal counsel is available to task forces and
subcommittees as required.  With respect to policy development activity,
ensure that the legal counsel is fully briefed on the existing
contractual arrangements with registries and registrars that relate to
the particular issue under discussion.   

10.2.6. Prior to the development of a final policy recommendation for
the GNSO Council, ICANN should ensure that the recommendation has been
reviewed by legal counsel to ensure that the recommendation can be
implemented and enforced via the relevant contracts.

10.2.7. Establish a project management process within ICANN that defines
a plan and expected dates for implementation of a policy once it is
approved by the ICANN Board.

10.2.8. Ensure that the mechanisms are established for monitoring and
enforcing compliance with a new policy.   This is particularly important
in the first 6 months of a new policy, when registry and registrars
systems are being modified to support a new policy.

10.2.9. ICANN staff develop a complaints handling process that is
capable of logging complaints regarding gtld domain name registration
practices, and capable of producing data on a trend basis.   This data
reporting would be useful on a monthly basis.  


10.3.   Actions required by the GNSO Council
==========================================

10.3.1. During the early public comment process, encourage members of
the ICANN community to submit proposals for solutions to a particular
issue. 

10.3.2. Given that legal contracts between ICANN and registries and
registrars may be open to different interpretation by the contracted
parties.  Ensure that legal advice from ICANN legal counsel (or external
counsel to ICANN) is in writing, and allow affected parties (such as
registrars and registries) to submit their own written legal advice for
consideration by the GNSO community.

10.3.3.  Ensure that the policy is ready for implementation after
approval by the GNSO Council and ICANN Board.


10.3.4. As part of the Council report at the end of the policy
development process, establish key metrics for measuring the success of
the policy, and ensure that appropriate measurement and reporting
systems are put in place.

10.3.5. To the extent that the lack of intermediate sanctions for
non-compliance with contractual obligations presents a significant
impediment to compliance activities, the GNSO should, without prejudice
to efforts to enforce existing contractual obligations, develop
recommendations for a system of graduated or intermediate sanctions for
incorporation in revised contracts.  As an initial step, ICANN legal
counsel should brief GNSO Council (or a relevant subgroup/task force) on
ICANN's current plans to correct ongoing harm and provide greater
flexibility and legitimacy for the compliance function.

Attachment: GNSOCouncil-selfreview-2-2.doc
Description: GNSOCouncil-selfreview-2-2.doc



<<< Chronological Index >>>    <<< Thread Index >>>