<<<
Chronological Index
>>> <<<
Thread Index
>>>
Registrar Stakeholder Group Position Regarding PDP Process Work Team Initial Report and Draft Recommendations
- To: "pdp-initial-report@xxxxxxxxx" <pdp-initial-report@xxxxxxxxx>
- Subject: Registrar Stakeholder Group Position Regarding PDP Process Work Team Initial Report and Draft Recommendations
- From: "Clarke D. Walton" <clarke.walton@xxxxxxxxxxxxxx>
- Date: Tue, 3 Aug 2010 19:00:46 -0400
August 1, 2010
Registrar Stakeholder Group Position Regarding
PDP Process Work Team Initial Report and Draft Recommendations
BACKGROUND
The Registrar Stakeholder Group ("RrSG") is providing feedback regarding the
Initial Report and Draft Recommendations from the Policy Development Process
Work Team. This paper captures the sentiment expressed by RrSG members who
provided feedback on the issue. No formal vote regarding the position was
taken.
RrSG OVERALL POSITION
The RrSG applauds the work of the WT. Over the past one to two years, the RrSG
has grown concerned about an increasingly overtaxed community and ICANN staff
and believes it's important to both refine the PDP and find a responsible way
to prioritize the GNSO's work.
Broadly speaking, the RrSG believes:
* PDPs should be based on responsibly documented evidence of an issue to be
addressed. Anecdotal evidence is insufficient. A reasonable data-driven
threshold for introduction of a PDP is a necessary step to concentrating
community resources on PDPs where there is evidence to justify a PDPs
initiation.
* Our SG, and we suspect others, sometimes struggle between the demands of
daily business responsibilities and the significant burden of thoroughly
contributing (sometimes concurrently) to all issues under GNSO consideration.
SGs often rely on "volunteer" leadership and work production, which is not
infinite.
* Particularly in light of the constraints on ICANN's predominately
volunteer community, some PDPs, while possibly well-intentioned, have proven
impractical and have needlessly consumed staff and community resources to the
detriment of more timely and critical issues.
* ICANN staff resources also are finite. All members of the GNSO community
should be responsible stewards of ICANN's time and resources, including
respectful use of the staff's time. The current level of work now being
handled is not sustainable in the long term.
RrSG positions on specific recommendations of the WT
With the above context in mind, the RrSG takes positions on each of the
following points or recommendations of the WT:
Recommendation 4: The PDP-WT recommends that a 'request for an issues
report' template should be developed including items such as definition of
issue, identification of problems, supporting evidence, and rationale for
policy development. Further consideration would need to be given as to whether
some of these elements should be required before a request is considered by the
GNSO Council. Such a template should become part of the above mentioned Policy
Development Process Manual or Guidebook.
The RrSG believes this is a responsible step toward making future polices based
on evidence and facts, and not on "what-ifs." ICANN, as a technical
coordination body, cannot reasonably anticipate all the potential ills that
could befall the DNS. The WT's recommendation for a template that includes a
clearly defined problem, well-documented supporting evidence, and a rationale
for the use of increasingly very limited resources for development of policy,
would be a useful tool.
In alignment with this recommendation, the RrSG recommends that any manual or
guidebook encourage that ICANN participants be mindful and respectful of
ICANN's limited resources.
The RrSG looks forward to a continued discussion of what would constitute a
reasonable threshold for initiating a PDP.
Recommendation 7: The PDP-WT recommends better information and communication
with Working Group members on the potential outcomes of a policy development
process. Contrary to the belief of a number of members of the community, there
are more potential outcomes of the PDP process than just the formation of
"consensus policies" as defined under the applicable gTLD Registry and
Registrar agreements. Acceptable outcomes include the development of best
practices, recommendations to other supporting organizations, recommendations
for future policy development, etc. This information could be included in the
Charter of a Working Group or in the instructions to a WG. It is also an
element that should be included in the Policy Development Process Manual or
Guidebook.
The RrSG welcomes this recommendation. Issues should be met with the solution
that most appropriately resolves them, and over-reliance on strict regulation
is detrimental to the growth and health of the DNS and the industry. The
business advice to "begin with the end in mind" is reflective of the above
recommendation, and the RrSG believes it would help a PDP be correctly focused
and more efficient.
Recommendation 13: The PDP-WT recommends that the Policy Development Process
Manual or Guidebook describe the option for the GNSO Council to require that an
impact analysis be conducted if appropriate or necessary prior to the vote for
the initiation of a PDP. Such an impact analysis could include the assessment
of the economic impact, the impact on competition, the impact on consumer
choice and/or protection, etc.
The RrSG agrees with this recommendation and believes it would be a prudent
step in a PDP. Those proposing policy or regulation are obligated to
responsibly, and respectfully, consider their impact on all affected parties.
The RrSG recommends that the PDP-WT add to this recommendation that impact
analyses include, to the extent possible, an assessment of impact to the
following:
* Operations of registries, registrars, and service providers
* ICANN as an entity (including ICANN's revenue)
* End-users and customers of the DNS
Recommendation 14: The PDP-WT believes that the GNSO Council should prioritize
PDPs and ensure that the resources exist (both staff and volunteer) upon the
initiation of a PDP. In light of the upcoming GNSO Council Prioritization
activity, the PDP-WT is deferring the specifics of how such prioritization can
be achieved pending the outcome of such activity.
The RrSG concurs with this recommendation as well. At present, the community
and staff are obliged to address all open issues simultaneously, probably to
the detriment of final outcomes. There simply isn't enough time or resource
available to thoughtfully consider each issue. Further, it's apparent that
established models are suffering-an example is the recent need to extend many
of the open comment periods to give the community time to "catch up" with the
workload.
The RrSG is aware of the GNSO's recent effort to find a way to prioritize its
agenda. Whatever final method is decided on, the RrSG firmly believes it
should be as free from possible "gaming" as practical. GNSO groups must act
more in cooperation on important issues.
The RrSG looks forward to continued discussion of prioritization methods.
Recommendation 24: The PDP-WT recommends modifying clause 3 - Initiation of a
PDP to clarify that within scope means 'within scope of ICANN's mission and
more specifically the role of the GNSO' as opposed to within scope of the
contracted parties' definition of "consensus policies."
The RrSG found this language to be confusing and would appreciate clarification
from the WT. With regard to the general issue, however, the RrSG believes
ICANN's role, as it has been historically, is that of a technical coordination
body, and that it should limit itself to its role and resist "mission creep."
Further, the SG believes the GNSO is a policy development body and should honor
its role as such and not confuse policy development with policy implementation.
Recommendation 32: the PDP-WT recommends that staff resources needed or
expected in order to implement the policy recommendations should be evaluated
as part of the WG recommendations, and as part of the Council's review of those
recommendations, as part of the feasibility analysis and/or impact statement
(see recommendation 31).
The RrSG concurs with this and encourages adoption of this provision as part of
PDP reform.
Recommendation 38: The PDP-WT recommends to (sic) provide additional guidance
to GNSO Council in the Policy Development Process Manual or Guidebook on how to
treat Working Group recommendations, especially those that have not received
full consensus and the expected / desired approach to adoption of some, but not
all, or rejection of recommendations. There is discussion within the PDP-WT
whether the GNSO Council should have the flexibility to 'pick and choose'
recommendations. There is no agreement yet on what guidance, if any, should be
given on recommendations that have not received full consensus. The PDP-WT
hopes to receive further input on this issue during the public comment period.
The RrSG has no currently formed position on this issue but agrees it's an
issues that deserves attention, and looks forward to contributing to further
discussion.
Recommendation 42: The PDP-WT recommends creating a WG Implementation Review
Team, which would be responsible in (sic) dealing with implementation issues.
The PDP-WT has not arrived yet at a possible recommendation in relation to how
the process for reviewing and addressing implementation questions would work
and hopes to receive further input on this issue during the public comment
period (see also recommendation 31).
The RrSG has no objection to this recommendation; however, it should be
considered in the context of the RrSG's abovementioned concerns about an
overtaxed staff and volunteer community. A team could be very useful, but only
if a commensurate amount of work is reduced to accommodate the demands of such
a review team.
RrSG position on Section 3 of the report: Planning and Request for an Issues
Report
With regard to area 3 of the report, as noted/asked by the WT:
3.a. In theory, there is currently no limit on these issues that can be
raised as there is no requirement for the issue to be 'within scope' (i.e.
either within the "picket fence" of the gTLD Registry and Registrar agreements
or within the parameters of ICANN's mission as it relates to the GNSO in
general). This assessment is carried out as part of the issues report. Should
an initial assessment take place when an issue is raised.
The WT reported: It was suggested that ICANN staff should be willing to
do an initial assessment of scope if requested by the body that is planning to
raise an issue. ICANN staff has expressed a concern that assessing whether an
issue is in scope may be difficult, but at the very lease would require that
issues are narrow and defined or order for this determination to be made.
The RrSG replies: ICANN was established with parameters for good reasons
- to keep the organization from overreaching and causing disruption, to clearly
define its role, etc. If the GNSO is willing to continue accepting every issue
that's raised, whether in scope or not, ICANN will continue to experience the
difficulties it now does.
Many things that have to do with ICANN's
work are difficult, but setting reasonable boundaries about its scope should
not be one of them.
3.b. Should the requestor identify the desired goal/outcome of a PDP?
The WT reported: It was suggested that those requesting the issues
report should be encouraged to identify potential outcomes, if possible, as
long as this would not bias or restrict the Working Group in its activities and
recommendations.
The RrSG replies: No potential outcome should be dictated as part of a
PDP, though the SG agrees a requestor should identify potential outcomes if
possible, without bias. It would be helpful and would encourage efficiency if
the requestor would clearly state the objective of a PDP.
3.c. What actions are needed in order to ensure a precise and narrow
definition of an issue?
The WT reported: ...A suggestion was made that there should be a
mechanism by which there is not sufficient information available an issue does
not pass to the next stage.
The RrSG replies: That is a reasonable suggestion. Proceeding blindly
on policy development without sufficient information is irresponsible.
3.d. Should an initial assessment be foreseen whether GNSO policy
development is the appropriate response to the issue raised or whether other
alternatives are deemed more efficient to achieve the desired outcome?
The WT reported: Some suggested this could be part of the staff response
if requested, but it should not affect the ability to raise an issue. It was
also noted that a policy development process can cover a broad range of issues
and have a variety of outcomes.
The RrSG replies: The RrSG agrees a variety of alternatives should be
employed to address issues of concern to the community. A PDP may or may not
be the appropriate method.
CONCLUSION
The opinions expressed by the RrSG in this position paper should not be
interpreted to reflect the individual opinion of any particular RrSG member.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|