[council] Registry constituency statement on the GNSO Council review

[Bruce Tonkin]

Hello All,

The following comments were submitted by the Registries constituency.

Regards,
Bruce Tonkin


gTLD Registry Constituency Comments re. GNSO Council Review
January 24, 2004

gTLD Registries Constituency welcomes the Independent GNSO Council Review.  The following text summarizes gTLD registry constituency views concerning the subject. We also enclose detailed comments and questions raised during our deliberations. 


1. PDP Timelines 

We support the conclusion of the report that changes are needed in PDP timelines.  The timelines chosen for the GNSO PDP process do not address the differences in the issues that are considered by the GNSO although the overall process clearly provides the framework for the needed evaluation and consideration. Timelines should be set that are realistic and predictable. It is critical that a timeline for each of the activities be set as part of the process so that the businesses and various constituencies that must react to the PDP have a stable and predictable process for evaluation of critical items.  

Any item that does not fit within these guidelines should likely be re-evaluated to ensure that the issue is discrete enough that determination whether a consensus can be reached is possible within the PDP timeframe. It is important that timeframes be adhered to so that ICANN constituencies are not placed in an untenable business position by a never-ending PDP related to a critical business process.


2. Constituency Feedback 

Although the GNSO tries to solicit Constituency Feedback on various topics, the timeframes provided are often inadequate and do not coincide with timeframes where representatives will have adequate time to solicit and receive input from their constituency members.    It is important that constituency feedback is required at each time and in full scope as defined in the bylaws.  


3. Outreach on Public Comment 

The GNSO should be more effective in publicizing their desire for public comment on specific topics.  Outreach efforts should be documented and evaluated to see what outreach was effective and which was not as productive and then this information should be used the next time.  Comment should be solicited from both within and outside of ICANN groups. It is important to select the right channels and explain possible impact to those impacted parties which may be less familiar with ICANN process. This is not necessarily an easy problem to solve but is one that is critical to ensure legitimacy of the policy development process.
 

4. PDP Content 

The PDP should be sure to include any information about dissenting opinions in any constituency statement, including detailed information on voting as detailed in the ICANN bylaws.
 

5. Constituency Representativeness  
  
We welcome and support the recommendation to include the issue of representativeness in the review of the GNSO as a whole. 


6. Consensus 

We wish to make an additional recommendation. The Council should recognize that it will not always be possible to reach consensus on an issue and that that is as valuable an outcome in the process as reaching consensus. It is unrealistic to expect that consensus will always be possible in the hugely diverse and global world of the Internet.  Moreover, when a 'no consensus' conclusion is reached, that can be a good indicator that it is an opportunity to let market forces work to sort out the issues and thereby let users make their own buying decisions rather than regulating them.


7. Number of Council Representatives per Constituency

We support recommendation 19 that "the Board should change the bylaws to put in place three representatives from each constituency."
 
 
 
Specific comments concerning the review of the document raised by members of the constituency 


3. PDP timelines. Are the timelines relevant?


P.11, 2nd paragraph:  

"Interviews with those who were involved in the creation of the PDP process suggest that the timelines were always seen as best intentions or stretch targets rather than hard and fast rules."  

This statement may not be accurate.  It does not appear that the PDP process in the ICANN Bylaws was written with this intention.  Further, the "best intentions or stretch targets" approach could put registries and other stakeholders in a possibly untenable business situation.  Running a registry business at the whims of the GNSO Council can make it impossible to be innovative and respond in a timely manner to customer needs.  

Having the same timelines for all PDP processes is not the answer because they will not all be the same, but some clear outside limits seem necessary.  This particular issue is one that is somewhat ironic because we as a constituency, through our representative Rita Rodin, tried to get the timelines lengthened because we knew that they would be very unrealistic in some cases; unfortunately, we were rebuffed in that regard.

Within the timelines, it is possible that a Simple and Complex timeframe could be developed and that the initial establishment of the PDP would identify the timeframe to be used.


P.11, 4th paragraph:  

"Although the timelines have not been kept in most cases, there are pieces of work where the timelines have proved realistic. This has been in cases where issues were not too complex and determining views of constituencies was all that was required of the Council. An example of this is the .net proposal which, while not a formal PDP, did follow the PDP process and was completed within the suggested timelines."  

This conclusion with regard to the .net criteria work by the Council is false and details regarding missed deadlines were publicly communicated in a posting by VeriSign at http://gnso.icann.org/reviews/gnso-review-sec1-22dec04.pdf.  Here is a lengthy quote from that posting, illustrating not only missed deadlines but other areas where the PDP process was not followed:

[BEGIN VERISIGN QUOTE]

"Specific cases where the PDP procedures were not followed are listed here in summary (without limitation) and described in further detail in Appendix B, citing the applicable section from the ICANN Bylaws, Annex A:
*	Section 2 describes the process by which an Issue Report shall be created, its scope, required deadlines, and purpose.  We note, at a minimum, the following deficiencies:
(1) The request of ICANN staff was sent to the GNSO Council 25 days after Board action instead of the required 15 days;
(2)There is no evidence that the required Issue Report, containing even the minimum information and instruction required by Section 2, was created or transmitted to the GNSO Council; and 
(3)The request sent to the GNSO Council was not accompanied by an opinion of the ICANN General Counsel.
*	Section 4 (and by reference Sections 7 and 8) describe the manner in which a PDP shall be initiated.  We note, at a minimum, the following deficiencies:
(1) We have not been able to locate any public posting of the minutes of the GNSO Council meeting that allegedly took place on 1 April 2004 authorizing the creation of the "Subcommittee" notwithstanding the fact that under the Bylaws those minutes should have been posted by 22 April; and
(2) There does not appear to be any public record of a vote by the Council.


Sections 5-7 describe the composition and selection of task forces, their role and the collection of information, and the public notification of the PDP.  We note, at a minimum, the following deficiencies: 

*	Section 5
(1) There appeared to be a lack of involvement of the ICANN Staff Manager; and
(2) There appeared to be a lack of transparency in requesting appointment of representatives to the Subcommittee.
*	Section 6
(1) The first request for public comment did not occur upon initiation of the PDP but rather 57 days later.
*	Section 7(b)
(1) There is no evidence of a charter created by the GNSO Council; and
(2) No specific directions to the "Subcommittee" were published by the GNSO Council or any specific guidelines developed to assure that the Subcommittee does not deviate from instructions of the GNSO Council.
*	Section 7(d)
(1) The one constituency statement received failed to contain even the minimum disclosures required by Section 7(d) for the Subcommittee's consideration of those statements (i.e., voting results, how the constituency arrived at its position in the statement, dissenting or opposing positions of constituency members to the position submitted as the consensus position in the constituency statement, any analysis of time or impact on the constituency, etc.).
*	Section 7(e)
(1) The GNSO Subcommittee draft, if intended as a Preliminary Report as specified in the Bylaws, does not contain most of the disclosures or information required; and
(2) None of the following dates were met:
§	The Preliminary Report was due not later than 12 May.
§	A Final Report was due not later than 17 May.
§	The Final Report was supposed to be posted by 22 May.
§	The GNSO Council should have called for a meeting of the full Council to consider the Final Report by 2 June, 2004.

Section 8 describes the procedure if no task force is formed.  We note at a minimum, the following deficiencies: 

*	Section 8
(1) GNSO constituencies did not appoint representatives within 10 days;
(2)  Representatives generally did not solicit comments from their constituencies;
(3)	Constituency statements were only received from one constituency, and that statement was wholly deficient in that it is reasonable to assume that  statements received by the GNSO Council should contain disclosures similar to those required of constituency statements submitted to a task force; and
(4) The ICANN Staff Manager did not compile an Initial Report and post it within 50 days of the PDP initiation."

[END VERISIGN QUOTE]


P.12, 1st full paragraph:  

"One feature of the PDP that has worked well is the outreach of Council within the GNSO. For all of the policy issues addressed by Council, Council members were able to consult with their constituencies and report back with a constituency position. Constituency reports as required by the PDP exist for all issues."  

Is it actually true that all constituencies submitted reports on all issues?  If not, that point should be made clear.  It is also questionable whether "For all of the policy issues addressed by Council, Council members were able to consult with their constituencies and report back with a constituency position."  

There seem to be multiple instances where Council members had limited time to consult with their constituencies.  In fact, the last sentence of this paragraph seems to confirm this: "Preparing these within the timeframe suggested by the PDP has not been unrealistic."

The GNSO should review the means and the timeframes by which the representatives can provide the needed statements and include that in decisions on the PDP timeframes and other requests for input.  This should also take into account calendar events that might require extension of the timeframes such as year-end or other periods where the volunteers that make up the bulk of those working on constituency statements will be unavailable for these activities.


P.12, 3rd full paragraph:  
"Another aspect of the PDP that seems to be working well is the public comment period which allows anyone who is interested to comment on reports when they are issued."  

It is accurate to conclude that opportunity for public comment is always provided.  It is not clear though that this is sufficient without more outreach to impacted parties.  It seems unreasonable to assume that simply posting documents for comment through normal ICANN channels should be expected to generate comments from the broader community of stakeholders on particular issues.  The small number of comments received and the sources of those comments may be evidence of this because most comments have been from groups heavily involved in ICANN activities with very few coming from other groups.  

This is not necessarily an easy problem to solve but is one that is very important if the policy development process is ever going to be one that becomes one that is more than just an "insiders" process.  To the extent that ICANN constituencies are representative of the broader community, this would be less of a concern but, even it that were the case, documentation of the adequacy of the representativeness with regard to a particular issue should be included as part of each report.  Outreach efforts of the Council should also be documented for each issue to include measures of success of that outreach such as identification of impacted parties, description of outreach efforts to those parties, measures of response, etc.  In cases where outreach does not generate expected response, that should be documented to at least show that the opportunity was given.


P.12, 5th full paragraph:  
"Changes are needed to the PDP timelines. There is a need to formalize current practice, not least to ensure that the GNSO operates in accordance with its own bylaws and procedures. The structure of the PDP needs to be maintained, but it needs to acknowledge that different policy issues require different types of work and therefore different timeframes." 
 
The conclusions made in this paragraph appear to be reasonable and the recommendations following the paragraph are consistent with the conclusions but do not go far enough as noted in the next three comments.


Pp.12-13, Recommendation 5: 

"The Council should seek approval from the Board for a revised policy Development Process. The alternative process should have the following elements: Scoping phase (history of the issue, key questions, contractual issues, terms of reference, timelines, milestones including deliverables and check points for legal opinion) which should be done as quickly as feasible, probably within the timeframe of the current issues report; Policy work (including research, consultation with constituencies, periods for public comment) with timelines set in the scoping phase according to the complexity of the task; Regular reporting to Council on milestones as established in the scoping phase; A final report and public comment period as in the current PDP; A Council vote as in the current PDP."  

The scoping phase should also include identification of impacted parties and how best to reach out to them.  The policy work should include consultation with representatives of impacted organizations and/or individuals not usually part of ICANN processes.  The final report should include documentation of each step of the process with measurable data demonstrating the extent of consensus or lack thereof as the ICANN Bylaws PDP process requires: "1. A clear statement of any Supermajority Vote position of the task force on the issue; 2. If a Supermajority Vote was not reached, a clear statement of all positions espoused by task force members submitted within the twenty-day timeline for submission of constituency reports. Each statement should clearly indicate (i) the reasons underlying the position and (ii) the constituency(ies) that held the position; 3. An analysis of how the issue would affect each constituency of the task force, including any financial impact on the constituency; 4. An analysis of the period of time that would likely be necessary to implement the policy; and 5. The advice of any outside advisors appointed to the task force by the Council, accompanied by a detailed statement of the advisors' (i) qualifications and relevant experience; and (ii) potential conflicts of interest."  To support the final report data required, constituency statements and statements from parties outside of ICANN should be required to include similar data relative to their organizations.  A helpful way to ensure this happens each time input is solicited would be to provide templates that outline the major elements required for each type of submission.  This would not only ensure that all needed information is received but would also make it easier for submitters to prepare their input.


P.13, Recommendation 6:  

"The Council should develop a formal process for seeking input from other ICANN organizations for each of the policies it is developing." 
 
This should be extended to include input from organizations outside of ICANN when applicable.  As noted above, to ensure required completeness of submissions from various stakeholders and to make it easier for them to respond, we recommend that templates be developed and provided that outline the major elements required for each type of submission.


Other issues


P.22, 1st paragraph:  

"One issue which come up in many of the interviews was concern about the representativeness of the constituencies. Perhaps not surprisingly, many of the constituency representatives and members were concerned that constituencies other than their own were not truly representative of the groups that they claim to represent. This issue is beyond the scope of this review which is focused on the GNSO Council, not the GNSO as a whole. It is however, an extremely significant issue. The review of the GNSO as a whole will need to investigate whether each of the constituencies is truly representative of "the interests globally of the stakeholder communities it purports to represent" as required in the bylaws."  

The GNSO and previously the DNSO was never intended to be a legislative body but rather an organization to facilitate the DNS policy development process.  As such that process must be as inclusive as possible and should avoid the capture of the process by small groups of involved participants.  To the extent that ICANN constituencies are indeed representative of the groups they claim to represent, there are increased chances that the broader community will be served well and that capture will not occur.  Therefore, it is appropriate that a review of this issue be included in a review of the GNSO as a whole.