[council] Registry constituency statement on the GNSO Council review
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 constit!
uency; 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.