Page History

...

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

History
ICANN is currently focused on the concepts of Policy and Implementation as it related to the gTLD world. It is a debate that was not really an issue until recently. The Bylaws are reasonably clear that the GNSO is responsible for developing gTLD Policy. The Bylaws are silent on what happens next.

The formal Policy Development Process (PDP) a vehicle for developing gTLD policy, although the Bylaws do allow for other methodologies (except for the very specific type of Policy called Consensus Policy).

Most policies developed by the GNSO under the current methodology have been relatively simple and the issue of the details of the implementation have not been earth-shattering. That cannot be said of the Policy on New gTLDs. In that case, the policy itself did not go into excruciating detail. A team of ICANN Staff members spend several years following the adoption of the policy putting together the “implementation” embodied by the Applicant Guidebook (AG). The process involved very significant involvement of the GNSO and the wider ICANN community. There was never a formal methodology published on how issues would be resolved, but in most cases, the specifics of a particular issue were discussed until there was some consensus of agreement, or perhaps until the community was sufficiently worn down. It was clear that Staff played a very major role in arbitrating, but nothing was explicit.

A key part of the philosophy was that decisions made during the “implementation” could not alter the originally adopted GNSO Policy.

The issue of intellectual property rights and the mechanisms that would be available to protect them forced the issue. A number of new and modified protection mechanisms were proposed and eventually adopted by ICANN. The method by which they were developed was unorthodox from the traditional ICANN perspective. Some groups claimed that parts of the new mechanisms were definitively policy and thus could not be put into effect without involving the GNSO. Others claimed they were purely implementation. As such, some believed that as implementation issues, it was purely a Staff responsibility. This was counter to the AG development which, while deemed to be implementation, clearly had a major community involvement.

Resolution Methodology
The ALAC believes that once the issue became apparent, the ICANN Board should have taken the lead in chartering a cross community effort to delve into the issue and make recommendations on how to once more have a sense of order related to gTLD policy and implementation. That did not happen. As a result, the GNSO has chartered a Working Group (WG) to address the issue from a GNSO perspective. Although other parts of the community are invited to participate and are doing so, the ALAC believes that this was not how the problem should have been addressed.

Order from Chaos
Since gTLD Policy (with an upper case P) is defined in the Bylaws as the realm of the GNSO, it is simple enough to state that a Policy consists of whatever the PDP WG decides to put into its recommendations. These can be explicit and detailed, as they have been for several recent PDPs, attempting to ensure that Staff had no latitude to be “creative” during the implementation. PDP Implementation teams have also been formed with the aim of ensuring that the INTENT of the PDP WG was carried out, even if the recommendations were less that clear.

In the case of the New gTLD PDP, the recommendations were mostly quite general and left a lot of latitude to the implementers. Thus there were inevitably “implementation” decisions which would have substantive impact of the community and thus *could* have been considered Policy if that PDP had chosen to be more specific. But they didn’t.

The answer appears to be in recognizing that what we have been calling implementation is really composed of (at least) two distinct phases. Part of it, call it “execution” involved no decision which will impact the community. The other part, call it “implementation design” includes decision that could have been part of the original policy, but for whatever reason, were not. The process is even a bit more complicated because the overall implementation will in all but the simplest cases, involve iterative invoking of these phases.

The challenge is now to decide on what mechanisms to use to make these decisions which do not exclude the bottom-up process, but at the same time do not result in interminable delays. Although the GNSO must be a part of the decision process, it chose not to include them in the PDP, and thus waived its exclusive right to decide on them. The ALAC has no prescription for how to do this at the moment, but can offer some principles which should guide the process:

• There must be a methodology to recognize when a decision will impact the community, and such decisions must involve a bottom-up process in addressing those decisions;
• The processes must be designed to be time-sensitive – unending debate should not be an option; and
• There must be a way to come to closure when the community is divided, and this should not simply give executive powers to ICANN Staff.

One of the key question that must be resolved is what part should the Board play in taking action if the community is divided. This question is one of the reasons that the ALAC believes that this should have been a Board-led initiative, but the fact that it isn’t does not remove the importance of the question.

FIRST DRAFT SUBMITTED

History
ICANN is currently focused on the concepts of Policy and Implementation as it related to the gTLD world. It is a debate that was not really an issue until recently. The Bylaws are reasonably clear that the GNSO is responsible for developing gTLD Policy. The Bylaws are silent on what happens next.

...