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.)
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?
