Registrar Stakeholder Group Position Regarding PDP Process Work Team Initial Report and Draft Recommendations

[Clarke Douglas Walton <cdw@xxxxxxxxxxxxxxxx>]

April 1, 2011


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.