[council] Registry constituency statement on the GNSO Council review

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

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.