Comment ccNSOAG3:

["Mackay, Bart" <BMackay@xxxxxxxxxxxx>]

On behalf of eNIC Corporation (.cc) and The DotTV Corporation (.tv), I
submit the following comments to the ccNSO Assistance Group's Preliminary
Recommendation on the Policy-Development Process.  

Initially, we extend our thanks for the hard work of the Assistance Group
and its insight in framing and addressing the issues involved in a
methodical, foundation-up approach.  The key element in the AG's work had
been its identifying and defining the functions and scope the ccNSO's role,
as well as the role of ICANN overall, in ccTLD matters.  Our view of those
functions are consistent with those published by the ccNSO AG in Shanghai,
which correctly limit and restrict the issues that may even arise for
policymaking consideration within the ccNSO and, hence, ICANN.  One of the
primary challenges will be to maintain the vigilance and discipline
necessary to thwart "mission creep" as the ccNSO and ICANN move forward.
Such mission creep would have the negative effect of unwinding the positive
work done by the AG and once again plunging ICANN and the ccNSO into a state
of dysfunction.  

At the outset, we acknowledge the comments submitted by Mr. Stephan Welzel
of Denic and lend our support to his insightful observations.  It is our
hope that those points will be carefully considered and appropriate
adjustments to the Recommendations made.  We strongly support the principle
that, once the PDP is defined, no single party or group (whether it be the
ICANN Board or the Council) should be allowed to unilaterally impose any
modifications to it.  Rather, any proposed modifications must themselves be
subject to ccNSO processes and the PDP in existence at the time of the
proposed modification.  Such a requirement should be clearly stated in the
ccNSO AG Recommendation. 

Our additional comments herein are made in the context of ICANN's adoption
of the functions and role of the ccNSO as laid out by the ccNSO AG in
Shanghai.  Any deviation from or enlargement of those functions, whether
through formal action by ICANN as an institution or through construction and
interpretation by the General Counsel's Office as a result of the PDP
process, may result in different conclusions or recommendations.  

Particularly disconcerting is Section 2, wherein the PDP gives significant
powers and discretion to both the Issue Manager and the Office of the
General Counsel to shape the ccNSO agenda and the Council's perception of
the scope of policies which are subject to the PDP.  While the screening of
Issues may initially appear desirable, such an approach could easily lead to
selective decisionmaking by the Council, with decisions being made primarily
on Issues that the "gatekeepers" choose to be considered.  Among other
things, this structure presents inherent and significant risks for mission
creep and tunnel vision by Council members.

An appropriate alternative would be for the Issue Manager to act only in an
administrative and coordinating capacity, producing agendas and distributing
original documentation originating a request for PDP from one groups
designated in Section 1, rather than summarizing or framing the issues and
arguments through the creation of an Issue Report before passing the request
to the Council.  Additionally, rather than requiring that all requests for
PDP first pass through the Office of the General Counsel for analysis as
currently anticipated, the Council should receive requests directly,
determine if a request fits within the constraints of ccNSO policymaking and
take appropriate action.  This action could include requesting guidance from
the Office of the General Counsel using the criteria set forth in Section 2.
The foregoing would allow the Council, as the responsible body, unfettered
access and unfiltered information to take  the appropriate course of action
on all Issues flowing from the procedures described in Section 1.

We are also concerned that the Recommendation does not clearly state what
consequences, if any, flow from the failure to meet the rather aggressive
timeframes for action imposed by the PDP.  For example, in Section 3, what
happens if the Council does not meet for a vote within the 15 days after
receiving an Issue Report?  Does the Issue 1) simply fail because of lack of
compliance with the deadline, 2) continue to be considered through an
unstated automatic extension to the voting timeframe, or 3) fall into some
other unspecified category for future consideration?  Similarly, what
happens if a Task Force report is not submitted within the designated
timeframe or the Task Force charter is not published in the 10 calendar days
required by Section 7(b).  We suggest that the appropriate consequence would
be the failure of the Issue request, thereby requiring that the Issue
request be reintroduced (i.e, start the process from the beginning) to be
considered once again unless a supermajority on the Council (defined as 66
2/3% of the entire Council membership) vote to continue the consideration of
the Issue through extending the designated timeframe for a short period.
What ever the consequence, it should be clearly stated in the PDP.

Once again, .cc and .tv continues to support the AG's efforts to develop and
define a framework for the ccNSO that serves the needs of the ccTLD
community in the context of its institutional involvement within ICANN.  We
are confident that this process will result in a satisfactory conclusion
that should be embraced by the ERC and the ICANN Board.

Bart P. Mackay
Designated Representative of .cc and .tv