RE: [council] gTLD Registries Constituency Recommendation fro GNSO Improvement

["Marilyn Cade" <marilynscade@xxxxxxxxxxx>]

Dear colleagues, 

I ask that this contribution be moved into the AOB section. We don't have an
agenda item specific to reform of the PDP process on this particular agenda,
and have a very full agenda otherwise, but we have all acknowledged that we
want to schedule, as priorities permit, a process to review and revise the
PDP. This can be a useful contribution to that discussion. Thanks to the
Constituency. You guys have a lot of spare time! We may need to take
advantage of that more!!!!!!!!!!!

Marilyn

-----Original Message-----
From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On
Behalf Of Bruce Tonkin
Sent: Monday, January 16, 2006 4:57 PM
To: GNSO Council
Subject: [council] gTLD Registries Constituency Recommendation fro GNSO
Improvement

 
Hello All,

Attached are some recommendations from the gTLD registries constituency
regarding how to improve the GNSO processes.  I have included the core
recommendations in plain text at the end of this message.

Regards,
Bruce Tonkin



-----Original Message-----
From: Marie Zitkova
Sent: Monday, 16 January 2006 7:08 PM
To: Bruce Tonkin

Subject: gTLD Registries Constituency Recommendation fro GNSO
Improvement

Dear Bruce,

Late last year, the gTLD Registries constituency prepared the enclosed
document for the attention of the GNSO Council to communicate
suggestions for GNSO improvement for consideration by the Council.

The underlying assumption of the suggestions is that the success of
ICANN is heavily dependent on the success of the GNSO, and in particular
the Council.  Therefore, the suggestions are offered with the sincere
intent of improving the effectiveness of the GNSO by strengthening the
confidence of the Internet community especially with regard to the
functioning of the Council.

Members of the gTLD registry constituency welcome the opportunity to
discuss any or all of recommendations presented in this document with
the Council or any members of the community.  Please feel free to ask
questions and communicate concerns that the recommendations may raise.

It is recognized that implementation of the recommendations will require
time and effort of people who are already stretched thin, but we firmly
believe that any such time and effort will be rewarded several times
over in terms of time needed in the future and that the improvement of
GNSO effectiveness will pay strong dividends.  Moreover, the gTLD
registry constituency will cooperate however possible to assist in
implementation of the recommendations.

Best regards,

Marie Zitkova
Chair, gTLD Registries Constituency


GNSO Improvement Recommendations Final

Submitted by the gTLD Registry Constituency, December 21, 2005

This document is presented to the ICANN GNSO Council from the gTLD
Registry Constituency for the purpose of communicating some suggestions
for consideration by the Council.  The underlying assumption of the
suggestions is that the success of ICANN is heavily dependent on the
success of the GNSO and in particular the Council.  Therefore, the
suggestions are offered with the sincere intent of improving the
effectiveness of the GNSO by strengthening the confidence of the
Internet community especially with regard to the functioning of the
Council.

According to Article X of the ICANN Bylaws:

*       "the Generic Names Supporting Organization . . . shall be
responsible for developing and recommending to the ICANN Board
substantive policies relating to generic top-level domains." (Section 1)

*       "The GNSO Council is responsible for managing the policy
development process of the GNSO. It shall adopt such procedures as it
sees fit to carry out that responsibility, provided that such procedures
are approved by the Board, and further provided that, until any
modifications are recommended by the GNSO Council and approved by the
Board, the applicable procedures shall be as set forth in Section 6 of
this Article. In addition, the GNSO Council is responsible for managing
open forums, in the form of mailing lists or otherwise, for the
participation of all who are willing to contribute to the work of the
GNSO; such forums shall be appropriately moderated to ensure maximum
focus on the business of the GNSO and to minimize non-substantive and
abusive postings. (Section 3, paragraph 4)

*       Initially, the policy-development procedures to be followed by
the GNSO shall be as stated in Annex A to these Bylaws. These procedures
may be supplemented or revised in the manner stated in Section 3(4) of
this Article. (Section 6)  [Note that Annex A contains the GNSO
Policy-Development Process (PDP).]

As with all organizations, the GNSO needs to continually ensure that it
stays on task and not stray from its defined mission of "developing and
recommending to the ICANN Board substantive policies relating to generic
top-level domains".  The GNSO is made up of individuals and
organizations who have busy schedules outside of the ICANN world so it
is very important that their time is valued and that serious efforts are
made to ensure that time is spent on appropriate tasks and done so as
efficiently as possible.  The following two recommendations address
these objectives.


Recommendation 1 - Mission Check
================================

Prior to initiating any activity, the GNSO Council should carefully
evaluate the proposed activity to ensure that it involves the possible
development of a substantive policy relating to generic top-level
domains".  If it is not a policy issue, it falls outside of the GNSO's
mission and should probably be discarded.  If it is a policy issue but
not substantive in nature, it should only be pursued if adequate
resources are available considering other priorities.  To accomplish
this recommendation, it would be helpful to reach some consensus
regarding guidelines that can be used to determine whether or not an
issue is a policy issue and also whether it is substantive in nature.


Recommendation 2 - Input Instructions
=====================================

Whenever GNSO participants are asked to contribute to a policy
development effort, every possible means should be made to provide clear
instructions with regard to all of the following:
*       The purpose of the activity
*       Relevant background information
*       The possible results
*       Desired input.
Using a consistent format to provide these instructions would be
helpful; standard template should be used for desired input to ensure
completeness and consistency as well as to facilitate use of the
information received.  An example of such a template for public input
into a PDP is provided as Attachment A.  A similar template could be
used for constituency input and for input from key stakeholders not
directly represented in the GNSO.

Coordination of the consensus policy development process including
coordination with participants in the process is extremely important.
This is even more important when multiple efforts are going on
simultaneously.  Fortunately, ICANN has filled two positions that should
be used to ensure effective and timely coordination:  Manager, Policy
Development Coordination; GNSO Policy Officer.  Recommendation 3 deals
with the coordination function.


Recommendation 3 - PDP Coordination
===================================

To make sure that coordination responsibilities for GNSO policy
development activities are clearly understood by all GNSO participants
and to ensure that tasks happen in a timely manner:

a.      Responsibilities of the Manager, Policy Development Coordination
and GNSO Policy Officer related to GNSO policy development efforts
should be clearly delineated.  This should include but not be limited to
the following:
*       Identification of backup support in case of personnel
unavailability
*       Specific listing of applicable coordination tasks such as:
liaising with ICANN staff, GNSO Council chair, task force chair, GNSO
Secretariat, etc.; collection of relevant documentation; scheduling
meetings; arranging for meeting minutes; progress reporting;
consolidation of input; monitoring compliance with PDP requirements;
etc.

b.      Responsibilities of task force chairs and task force members
should be clearly delineated.  In both cases, general responsibilities
should be the same for all policy development efforts with only minor
adjustments made to deal with special circumstances; any such
adjustments should be identified.

Many lessons have been learned in PDPs that have occurred since the
implementation of the PDP procedures defined in the ICANN Bylaws.  The
Bylaws allow for revision of the PDP procedures; moreover, improvement
of the procedures should be a continual goal.  But the PDP procedures
have remained unchanged from their original form.  Recommendation 4
addresses this.


Recommendation 4 - PDP Revision
===============================

The GNSO Council should develop a proposal for revision of the PDP as
currently described in the ICANN Bylaws and any such proposal should be
submitted to the ICANN Board for consideration.  As much as possible,
all GNSO constituents should be involved in identifying possible
improvements to the PDP as well as the development of such a proposal.
A few ideas for possible areas for improvement are: 

1) establishing more realistic timeframes for various steps of the PDP
process including possibly having different timeframes for issues of
different levels of complexity; 

2) breaking broad issues into smaller components that can more
reasonably be considered in required PDP time frames; 

3) clearly defining measurable data that is required with any GNSO
recommendations to the Board; 

4) building increased flexibility in the process to accommodate
unanticipated complications; 

developing procedures and/or guidelines to deal with policy development
efforts addressing issues for which there appear to be clear regulatory
demands but for which consensus cannot be reached within the GNSO; 

developing procedures and/or guidelines with clear criteria for
disbanding task forces in cases where it is clear that consensus cannot
be reached (Note: it appears that the PDP may be based on what we
believe is a false assumption that it is always possible to develop a
consensus and therefore the GNSO Council may have expectations that a
recommendation must always be made.)


Over the past several years, the GNSO Council has seemed to move toward
an operational model whereby the majority of policy issues are dealt
with directly by Council members with only minimal involvement of
non-Council members.  This has resulted in an extremely heavy workload
for Counselors and undoubtedly slowed down the progress on various
issues because so many task forces involve the same participants.  It is
understandable that there is value in having at least one Counselor on
each task force to provide a ready interface between the task force and
the Council, but it would seem wise to expand the number of participants
outside the Council significantly and minimize the number of projects
with which any one Counselor is directly involved.  Ultimately, the
Council as a whole will have to take final action on any decisions made
so every Counselor will have final input.  In addition, all Counselors
will have the opportunity to recommend task force participants with whom
they can communicate throughout the task force work.  Recommendations 5
and 6 address this issue.



Recommendation 5 - Task Force Participation
===========================================

The GNSO Council should take steps to minimize the number of
simultaneous projects (task forces) with which any one Counselor is
directly involved.  Except in very special circumstances, experts who
are not Counselors should make up the majority of task forces and
working groups established by the Council thereby freeing Counselors to
focus most of their attention in managing the consensus policy
development process instead of directly developing policy.  To
facilitate interface with the Council, at least one and possible two
Counselors should be members of each task force and working group.
Deciding to not use a task force in a PDP should be considered rarely if
ever.


Recommendation 6 - Task Force Instructions
===========================================

The GNSO Council should provide very clear, unambiguous instructions for
every GNSO task force, working group or committee including: 

1) required time frames; 

2) required deliverables; 

3) instructions regarding what to do in case there is no consensus
position achievable; 

4) questions that must be answered; etc.

The ICANN Board is regularly confronted with difficult decisions that
deal with conflicting points of view by different members of the
community.  Unfortunately, it seems that they often have to make such
decisions based on mostly subjective information with very little if any
objective data.  Subjective information should not be ignored but such
information should always be complemented with objective measurements.
In addition, because the Board has to review a voluminous amount of
information, it is very important that information they are provided is
as concise and to the point as possible.  Recommendations 7, 8 and 9
deal with these concerns.


Recommendation 7 - Measurable Data for Recommendations to the Board
===================================================================

For all policy recommendations to the ICANN Board, specific, objective
measurements should always be provided without limitation to the
following:

*       A quantifiable measurement of the level of consensus achieved in
the GNSO - This should certainly include the level of consensus on the
Council (e.g., 100%, 80%, 60%), but it should go further and include
level of consensus achieved in each of the constituencies represented on
the Council.

*       Listing of impacted parties including their perceived level of
impact (e.g., high, medium, low)

*       Data regarding the types and quantity of outreach efforts to
GNSO constituents and the community at-large including the success
and/or failure of those efforts.  (e.g., website request for comments
received 11 relevant responses over a 21-day period; GNSO constituency
request for comments resulted in statements from 5 of the 6
constituencies; etc.)

*       The level of representativeness of participants in the consensus
development process including:

o       The level of representativeness of each constituency voting on a
recommendation (e.g., 11 gTLD registries including all of the active
registries participated in the process out of a total of 12 gTLD
Registry Constituency members and out of a total of 14 eligible
members.)  Data about constituency representativeness (and/or
membership) should be generally available, say on the GNSO web site,
rather than re-inserted each time constituency comments on a policy.
That would provide a readily available means of validating
representativeness claims at any given point in time.

o       The level of representativeness of stakeholder groups from who
input was requested.

A standardized input template should be used to ensure completeness and
consistency of data reported to the Board.  A possible example of such a
template is included as Attachment B.


Recommendation 8 -Conciseness of GNSO Recommendations
======================================================

All policy recommendations to the ICANN Board should be presented as
concisely as possible.  Thorough executive summaries should always be
provided.  Objective data should be provided in a standardized table or
chart format; a possible example of this is provided in Attachment C.
The temptation to provide excessive documentation of GNSO processes and
results should be avoided and clear summaries of the policy development
efforts should be provided with references to detailed documents if some
individuals would like to see them.


Recommendation 9 - Standardization of Recommendations to the Board
===================================================================

A standardized outline should be developed and used for all
recommendations to the Board.  Any such outline should correlate closely
with the requirements of the ICANN Bylaws requirements in Article X,
Section 6 and Annex A (GNSO PDP) to ensure that all required information
is included.


Conclusion
==========

An overriding objective in the above job tasks is to minimize the amount
of subjectivity and increase the amount of measurable objective criteria
in the consensus-building process.  This should result in clearer
direction for working groups, committees, Constituencies, etc. and it
should therefore make it more readily possible for the Council to
perform its role of managing the consensus-building process in a way
that will create increased confidence throughout the Internet community.

Members of the gTLD registry constituency welcome the opportunity to
discuss any or all of recommendations presented in this document with
the Council or any members of the community.  Please feel free to ask
questions and communicate concerns that the recommendations may raise. 

It is recognized that implementation of the recommendations will require
time and effort of people who are already stretched thin, but we firmly
believe that any such time and effort will be rewarded several times
over in terms of time needed in the future and that the improvement of
GNSO effectiveness will pay strong dividends.  Moreover, the gTLD
registry constituency will cooperate however possible to assist in
implementation of the recommendations.