Initial observations about The Issues Report.
Issues report:
http://icann.org/gnso/issue-reports/registry-svcs-report-19nov03.htm
After having read the issues report on new registry services several
times and after having slept over it, I'm still trying to parse what
ICANN staff is really suggesting here. Your comments would be
highly welcome.
* * *
On its face, the issues report gives an account of some recent
history, and then roughly describes the process that's currently
used when registries plan changes to their architecture or plan new
services.
* Registry operator notifies ICANN of planned change.
* If ICANN believes that change is compatible with contracts, ICANN
quickly gives thumbs-up.
* If change of contract is required, ICANN performs a "quick-look"
evaluation whether or not the service may harm others.
- no harm: thumbs up.
- possible harm: further process.
The initial checks with ICANN staff apparently are performed within
30 days (or are supposed to be performed within 30 days for
unsponsored registry operators?).
The process is described as applying to both sponsored and
unsponsored gTLDs.
The issues report then goes on to describe possibly competing
considerations: Possible harm to others; the need for innovation at
the TLD level; the impact on competition. The part about
"requirements for a new procedure" then suggests that the current
procedure should be revised, and gives an extremely rough summary of
constituency positions: Unsponsored registries demand that
"contractual agreements" be accounted for; registrars want to be
consulted "where a new sole-source registry service mighth displace
services provided on a competitive basis at the registrar level" --
think WLS --; user constituencies want to be consulted when a
service might adversely affect their members' interests.
The document closes with "recommendations" to the GNSO: A PDP
should be intiated,
to develop a policy to guide the establishment of a
predictable procedure for ICANN's consideration o f
proposals by registry operators and sponsors for changes in
the architecture and operation of a gTLD registry.
The GNSO is asked to develop the "essential characteristics" of such
a process; details should be left to the President. Some
"sub-issues" are identified: Documenting the process; transparency
of the process; time lines; confidentiality protection; expert
consultation; gathering input from the community.
The staff manager then recommends against forming a task force on
this issue, and suggests that the council as a whole deal with this;
several phases of work are suggested, each of which is supposed to
begin with a staff document on which constituencies and advisory
committees then can comment.
* * *
Looking more closely, though, there are a number of interesting
issues with this issues report.
To begin with, the report indiscriminately talks about sponsored and
unsponsored registries, and about registry services and other
changes.
Where the GNSO Council deliberately talked about Registry Services
(as a contractual term!) in its October 16 version of the issue
statement, the issues report uses an essentially rhetoric argument
to significantly broaden the scope of the proposed process, talking
about "the reality that proposed changes may include but are not
limited to things that could be called 'services' or 'products,' and
that any proposed changes that could have the effects described
should be subject to an appropriate consideration process."
What makes this change interesting is the question on what legal
basis ICANN is proposing that a process be developed.
Unfortunately, the issues report only offers hand-waving on this.
The situation with unsponsored registry operators is described with
the words "among other constraints, unsponsored registry operators
have agreed that they will not introduce new for-fee 'registry
services' except upon establishment of a maximum price ... with
ICANN's written consent." The "other constraints" are neither
referenced, nor explained.
For sponsored TLDs, there is actually an explicit delegation of
authority regarding "functional and performance specifications for,
and pricing of, Registry Services." (See, e.g., .musem agreement,
attachment 2;
<http://www.icann.org/tlds/agreements/museum/sponsorship-agmt-att2-20aug01.htm>.)
This not discussed in the issues report.
Finally, there's the issue of review: In the "requirements" section,
the issues report talks about a "timeline for an appeals procedure";
the report never comes back to this point.
On the procedural side, ICANN seems to be proposing a process that
is essentially driven and controlled by ICANN staff, with the
council merely in the role of collecting and consolidating
constituency input.
* * *
Finally, why is ICANN invoking the policy-development process here?
Why is collecting principles for what looks like an ICANN-internal
process from constituencies characterized as establishing policy?
On its face, this would be a task that could be performed without
invoking the PDP, and without having council votes in the process.
When combined with the hand-waving about ICANN's contractual ability
to actually enforce the decisions made using that process, the use
of the PDP for establishing it may point in a different direction:
Is ICANN staff attempting to rush a consensus policy through the
GNSO that would require registry operators and sponsors to subject
any suggested changes to the process designed?
Regards,
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/