Comment Close
Date
Statement
Name 

Status

Assignee(s) and
RALO(s)

Call for
Comments
Call for
Comments
Close 
Vote
Announcement 
Vote OpenVote
Reminder
Vote CloseDate of SubmissionStaff Contact and EmailStatement Number
31.10.2013Policy & Implementation Working GroupAdopted 12Y, 0N, 0A

Alan Greenberg (NARALO)

14.11.201320.11.201320.11.201321.11.2013n/a21.11.201321.11.2013n/aAL-ALAC-ST-1113-03-00-EN

To Supporting Organisation and Advisory Committee Chairs:

 

Dear Olivier,

We are the Chairs of the newly constituted Policy & Implementation Working Group.  This Working Group (WG) has been tasked with providing the GNSO Council with a set of recommendations on the following issues:

  1. What guidance do the ICANN core values (Bylaws Article 1, Sec. 2) directly provide with regard to policy development work and policy implementation efforts? (e.g., multi-stakeholder participation).
  2. What guidance do other ICANN core values provide that relate indirectly to policy development and policy implementation?  (e.g., effective and timely process).
  3. “Questions for Discussion” contained in the Policy versus Implementation Draft Framework prepared by ICANN staff.  (See, http://www.icann.org/en/news/public-comment/policy-implementation-31jan13-en.htm).
  4. What lessons can be learned from past experience?
    1. What are the consequences of action being considered “policy” vs. 
      “implementation”?
    2. Does it matter if something is “policy” or “implementation”?  If so, why?
    3. Under what circumstances, if any, should the GNSO Council make recommendations or state positions to the Board on matters of policy and implementation as a representative of the GNSO as a whole?
    4. How do we avoid the current morass of outcome-derived labeling (i.e., I will call this “policy” because I want certain consequences or “handling instructions” to be attached to it?)
    5. Can we answer these questions so the definitions of “policy” and “implementation” matter less, if at all?
  5. What options are available for policy (“Consensus Policy” or other) and implementation efforts and what are the criteria for determining which should be used?
    1. Are “policy” and “implementation” on a spectrum rather than binary?
    2. What are the “flavors” of policy and what consequences should attach to each “flavor?
    3. What happens if you change those consequences?
  6. Who determines the choice of whether something is “policy” or “implementation”?
    1. How is policy set/recommended/adopted and do different paths lead to different “flavors”?
    2. How is the “policy” versus “implementation” issue reviewed and approved?
    3. What happens if reviewing bodies come to a deadlock?
  7. What is the process by which this identification, analysis, review and approval work is done?
    1. How are “policy and implementation” issues first identified (before, during and after implementation)?
    2. What is the role of the GNSO in implementation?
    3. In order to maintain the multi-stakeholder process, once policy moves to implementation, how should the community be involved in a way that is meaningful and effective?
    4. Should policy staff be involved through the implementation process to facilitate continuity of the multi-stakeholder process that already occurred 

Alternatively, if you would prefer to set up an exchange of views by teleconference or possibly in person during the ICANN meeting in Buenos Aires, the Working Group would welcome such an approach as well.

Finally, we would like to remind you that the WG is open to the full community and we welcome any additional members from your organization that my wish to participate in this work. To review the current membership, please see https://community.icann.org/x/81V-Ag.

Thank you in advance for your consideration.  Please do not hesitate to reach out to either of us if you have any questions or if you require any additional information.

Kind regards. 

Chuck Gomes (cgomes@verisign.com)
J. Scott Evans (jscottevans@yahoo.com)

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please click here to download the PDF below.

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:

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.

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:

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.