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:

• 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.
• 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 there 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:
• 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.
• 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.

Attachment A

Draft PDP Input Template for Public Comments

General Information

Name of the author of the comments:

Brief description of author’s experience related to the PDP topic:

Brief description of the author’s interest in the PDP topic:

Author contact information for follow-up if necessary:

If author is associated with a GNSO Constituency, provide the constituency name here:
(Choose from one of the following: Commercial & Business Users, Intellectual Property Interests, ISPs, Non-Commercial Users, gTLD Registrars, gTLD Registries, none.)

If author is associated with one of the following, please name the group or groups here:
(Choose from one or more of the following: ASO, ccNSO, ccTLD manager, GAC, individual Internet users, other – please identify.)

Listing of specific questions for which input is requested

Question #1 (insert question)

Answer to question #1

Question #2 (insert question)

Answer to question #2

Etc.

(Note that questions may include direct questions of support for specific recommendations.)

General Comments

Attachment B

Draft Consensus Policy Input Template

General Information

Name of organization:
[Choose one of the following: GNSO Constituency (Commercial & Business Users, Intellectual Property Interests, ISPs, Non-Commercial Users, gTLD Registrars, gTLD Registries); ccNSO (if applicable; ASO (if applicable); GAC (if applicable); At-Large organization if applicable.  This list should be customized for specific PDPs.]

Contact Person:

Contact email address:

Number of official members of the organization:

Estimated number of potential eligible members of the organization:

Number of unique participants in this PDP process:

Listing of specific questions for which input is requested

Question #1 (insert question)

Answer to question #1

Question #2 (insert question)

Answer to question #2

Etc.

(Note that questions may include direct questions of support for specific recommendations.)

General Comments

Attachment C

Draft Consensus Policy Measurements Table for GNSO