[alac] Revised: Procedural comments on new gTLDs committee.

[Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>]

Please find attached a slightly revised version of the proposed
procedural comments on the new gTLDs draft.  This version has some
changes in wording where it comes to the proposed application of the
policy-development process, both to the issues raised by gtld-com,
and to future substantial advice.

I would like to submit this to the GNSO Council several days before
the 22 May telephone conference.  The comments are complementary to
the draft of a substantial statement circulated earlier today by
Wendy.

Regards,
-- 
Thomas Roessler                   <roessler (at) does-not-exist.org>



------------------------------

Subject: Procedural concerns with gtld-com.
To: council

Dear colleagues,

upon review of the new gTLD committee's final draft report, the ALAC
has noted with some surprise that the draft is neither limited to
just constituency statements (as suggested by the minutes of the
council's 16 January telephone conference), nor limited to advice
about the board's fundamental question, and to identifying "issues"
to be addressed by future policy-making (as had been discussed
during the Council's April 17 telephone conference).  Instead, the
draft includes relatively detailed recommendations on criteria and
procedures which should be used in the selection of new gTLDs. Wendy
Seltzer {will comment|has already commented} separately, to the
gtld-com list, on the concerns we have about the substance of a
number of these recommendations.

The council is to be commended for its aim to broadly understand the
issues at hand, by evaluating not just the narrow question asked by
the board, but by also exploring surrounding policy areas.  However,
risks occur when this exploration gets near to the realm of actual
policy-making -- for this, the policy-development process defined in
the bylaws should (many would say: must) be applied.  This process
in particular guarantees the openness and transparency of the GNSO's
decision-making, by making both the issues and initial reports
available for public comment, to be submitted during two comment
periods of three weeks each.  It is hard to overemphasize the
importance of this particular aspect of the new policy-development
process.

(No comment process has taken place during gtld-com's work. The
outreach independently undertaken by the ALAC itself cannot replace
a formal GNSO public comment period.  While working hard on this,
the ALAC has not yet reached the excellence of the GNSO's outreach
mechanisms.)

In view of the dynamics the gtld-com process has exhibited, and in
view of the emphasis the ICANN 2 bylaws put on using well-defined
processes, the ALAC would like to respectfully propose both
short-term and long-term conclusions to the Council.


1. Short-term conclusions

The Council could, at its 22 May telephone conference, opt to
transmit to the Board only a brief answer to the question asked in
resolution 2.151, namely, that "expansion of the gTLD namespace
should be a bottom-up approach with names proposed by the interested
parties to ICANN. There is no support for a pre-determined list of
new names that putative registries would bid for. Expansion should
be demand-driven." (Text taken from the draft final report.) 

The remaining questions addressed in the new gTLD committee's report
should be subject to formal policy-development processes.

2. Long-term conclusion

We would suggest that the Council use, as a general rule, the
policy-development process established by the bylaws or an analogous
process for all substantial advice it creates.  We recommend that
this general rule be made part of the Council's rules of procedure,
and request discussion of this proposal at either the GNSO Council
meeting in Montreal, or the subsequent meeting.


DISCLAIMER: This message is not intended to be an Advisory Committee
Initiation of a Policy-Development Process, as described in Annex A,
section 1.c of the new bylaws.


Kind regards,
-- 
Thomas Roessler                 <roessler (at) does-not-exist.org>