ICA just filed a comment letter responding to a draft ICANN framework for determining what is policy and what is just implementation of existing policy. We’ll be the first to admit that the subject is dry, vague, and of general interest only to Internet policy wonks – but the answers are critically important to assuring that domain investors and registrants get a fair shake in the ICANN process.
That importance was recently illustrated in the debate on the “Strawman Solution”, an eleventh hour proposal from ICANN’s Business and IP Constituencies that seems to have exacerbated existing tensions rather than solving anything. The most controversial adjunct to the “solution” was the Limited Preventive Registration Mechanism (LPRM) initiative, which boiled down to letting trademark owners register all sorts of terms that were not their trademarks in the Trademark Clearinghouse and then to have those terms serve as blocking mechanisms against anyone trying to register a domain matching them at any new gTLD.
Naturally, the proponents of the LPRM contended that it was no big deal, just implementation of existing ICANN policies. ICA and other opponents responded that it seemed like a pretty radical new initiative that had to be subjected to ICANN processes designed to assure that new policies are well considered and have consensus support. ICA’s comment letter on the “Strawman” has this to say about LPRM:
The LPRM also may well expand trademark rights far beyond their status in current law – from a reactive right that can be enforced when infringed by a domain registrant to a preemptive one that can be exercised to block a domain registration. Both the UDRP and the URS require a complainant to show both bad faith registration and use on the part of a registrant, but the LPRM would presume bad faith registration and future bad faith use by a new registrant based upon the past action of an entirely different registrant at a different TLD. The “crystal ball”, pre-infringement approach embodied in this proposed RPM is simply unacceptable.
As a result of the deep schisms generated by the “Strawman”, ICANN requested that the public weigh in on a draft framework for deciding the dividing line between policy and implementation in the future.
We think the staff paper is a thoughtful first stab at the subject – but that its default position leans too heavily toward the implementation check off. In particular, it fails to adequately address the impact of proposals on registrants, doesn’t recognize that implementation steps can raise their own new policy issues, and doesn’t address the burning need to provide some certainty and finality in the policy and implementation process.
For the policy wonks among you, our complete comment letter follows —
VIRTUALAW LLC
Philip S. Corwin, Founding Principal
1155 F Street, NW Suite 1050
Washington, DC 20004
202-559-8597/Direct
202-559-8750/Fax
202-255-6172/Cell
psc@vlaw-dc.com
February 21, 2013
By E-Mail
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
Re: Policy vs. Implementation
Dear ICANN:
I am writing on behalf of the members of the Internet Commerce Association (ICA). ICA is a not-for-profit trade association representing the domain name industry, including domain registrants, domain marketplaces, and direct search providers. Its membership is composed of domain name registrants who invest in domain names (DNs) and develop the associated websites, as well as the companies that serve them. Professional domain name registrants are a major source of the fees that support registrars, registries, and ICANN itself. ICA members own and operate approximately ten percent of all existing Internet domains on behalf of their own domain portfolios as well as those of thousands of customers.
These comments reflect our views on the Policy vs. Implementation issue that was posted for public comment on January 31, 2013 at http://www.icann.org/en/news/public-comment/policy-implementation-31jan13-en.htm . The ICANN community and the global public have been asked to react to an ICANN staff paper “outlining a draft framework for community discussion that identifies a number of steps and criteria that might facilitate dealing with questions relating to policy vs. implementation in the future”.
Executive Summary
The major points made in this comment letter are:
- · Impact on domain r
egistrants must be fully considered in the development of policy and its subsequent implementation. - · It must be recognized that implementation of broad policy directives can raise important additional policy considerations.
- · There must be some finality to both the policy development and implementation phases.
- · Intermediary policy implementation parties must be placed under contract – Including UDRP and URS arbitration providers.
- · Implementation review teams must be open to a diverse membership and operate in a transparent manner.
- · When necessary, PDP Working groups should be provided by ICANN with legal and technical support to assure practicality of policy implementation.
- · There should be a bias against the adoption of new or substantially altered policies where no clear community consensus exits – but in favor of implementation of adopted policies when there is disagreement on the details.
Discussion
The issue of what constitutes policy development within the ICANN process and therefore requires substantial further consideration of and feedback from the broad ICANN community – as opposed to what constitutes implementation of existing policy and thereby requires lesser community notice and feedback or none at all – recently came to the fore in the submission of comments on the proposed “Strawman Solution” for the Trademark Clearinghouse. ICA filed its comment on that matter (see http://forum.icann.org/lists/tmch-strawman/msg00036.html ) and opined that several of the proposals within that proffered solution indeed constituted significant policy initiatives and therefore required additional process to consider and refine or reject them. Proponents of the “Solution”, unsurprisingly, felt that they constituted mere implementation of existing policy and therefore required no such additional consideration beyond that comment period prior to being implemented by ICANN. Overall, the community was sharply divided on the matter with little consensus on the major constituent parts of the proposed “Solution”.
We therefore welcome staff’s thoughtful approach to this important topic. It is clear that, to the extent possible, ICANN should better define the criteria that distinguish policy from implementation, as well as the processes appropriate to each, to better inform its handling of future issues that confront ICANN and the community.
We doubt that a “bright line” test can be established to mechanically yield a clear decision in regard to all future issues – especially since, as the paper observes, “there are multiple kinds of “policy” within the ICANN world”, including formal policies developed through the policy development process (PDP), operational policies, and general practices or procedures. However, we do believe that the current effort can both minimize future disagreement as well as establish clear procedures to be followed, and clear roles for various DNS stakeholders, in the consideration and establishment of overarching policy as well as the implementation and refinement of such policy.
While our comments on this matter are to some extent informed by the recent experience with the “Strawman Solution”, the intent of our comments is not to re-litigate that dispute but to provide constructive comments that will contribute to developing an analytical framework that will be useful in and applicable to future issues under consideration by ICANN and its community. This present effort will indeed be successful only if it produces such an approach.
Registrant Impact Must be Considered
One factor that should lead to a conclusion that a proposal falls within the policy category is when it will impose new responsibilities upon domain registrants or will have a material impact upon their rights.
The staff paper recognizes this potential means of distinction between operational and formal policies, noting:
Another improvement may be to clearly separate policies that apply to ICANN (e.g., as relates to the evaluation of new gTLD applicants), from policies that apply to Internet stakeholders such as registries, registrars, and registrants. (Emphasis added)
In this regard, we believe that the “default position” taken by the staff paper, which would treat any proposed change as mere implementation “unless the objective is to create new obligations on existing parties”, is too narrow. The viewpoint it expresses seems to be focused on obligations on contracted parties such as registries and registrars. Proposed changes that might narrow the rights of domain registrants should also be a factor that leads to the conclusion that a proposed change constitutes policy. This would include any alteration of the Trademark Clearinghouse (TMC) or the Uniform Rapid Suspension (URS) that could make a domain more susceptible to being the subject of an arbitration action under the Uniform Dispute Resolution Policy (UDRP) or the URS, or materially affect the outcome of such action — as well as any modification of the existing URS policy that would alter a registrant’s procedural and substantive rights.
We would therefore urge that the framework be modified so that it is clear that a policy matter exists where the objective or result of a proposed change is to create new obligations or impose new responsibilities upon, or materially alter the rights of, existing parties. Further, the portion of the flow chart found at the conclusion of the staff paper – which would only require “public consultation” but not
policy development or guidance when an implementation change would “have a substantial effect on registry, registrar, or Internet users generally” or create a “new precedent” – seems to draw the line too restrictively in precluding the treatment of such substantial changes in implementation as raising significant policy issues.
Implementation of Broad Policy Directives
Any framework for differentiation between policy and implementation must recognize that the implementation of a broad, high-level policy directive may itself raise important additional policy considerations.
For example, many of the parties who supported the “Limited Preventive Registration” adjunct to the recent “Strawman Solution” based their assertion that it was mere implementation and not substantial new policy upon the fact that there was an existing GNSO policy requiring that the new gTLD program “not infringe the existing legal rights of others”. While no one can disagree with the principle expressed in that short and general policy statement, there is no contradiction in asserting that proposed detailed mechanisms for carrying it out can raise new and profound policy issues.
ICA took an entirely opposite view on that element, stating:
We oppose any further consideration of such a “preventative mechanisms” until it has been subjected to broad community review through a full PDP. The LPRM is clearly a significant new policy initiative and an entirely new RPM. Further, it presumes implementation of an expanded TMCH database, which we also oppose. [Note: We opposed expansion of the TMCH database on the grounds that it would alter the fundamental nature of the TMCH – as well as upon the fact that a letter sent by ICANN’s CEO to members of the US Congress stated “Extending the protections offered through the Trademark Clearinghouse to any form of name would potentially expand rights beyond those granted under trademark law and put the Clearinghouse in the role of making determination as to the scope of particular rights.”]
The LPRM also may well expand trademark rights far beyond their status in current law – from a reactive right that can be enforced when infringed by a domain registrant to a preemptive one that can be exercised to block a domain registration. Both the UDRP and the URS require a complainant to show both bad faith registration and use on the part of a registrant, but the LPRM would presume bad faith registration and future bad faith use by a new registrant based upon the past action of an entirely different registrant at a different TLD. The “crystal ball”, pre-infringement approach embodied in this proposed RPM is simply unacceptable.
Overall, the issues raised by the LPRM are so broad and profound that any proposal along these lines must be subjected to ICANN’s full PDP treatment.
The differentiation framework must recognize that the implementation of broad, overarching, and generally stated policies will often raise subsidiary yet significant new policy issues that must be treated as such. The ability to point to a general “intent” of a broad and vague policy should not preclude its implementation from being regarded as raising subsidiary yet substantive new policy matters that deserve treatment as such.
Finality to the Policy and Implementation Phases
One issue that is not adequately addressed by the staff paper is the need for some finality in both the policy development adoption and implementation phases. We would propose that ICANN consider declaring, for both phases, a point in time at which no further alterations will be considered absent significant new facts or substantial real world experience with the policy at issue.
For example, a great deal of the debate over the TMC and URS rights protection mechanisms (RPMs) has centered on the desire of IP interests to reopen the RPMs, versus the charges of other parties that the IP sector is seeking too many “bites at the apple” (as well as their own desire for new gTLD implementation to proceed expeditiously without further substantial alteration of the RPMs). Regardless of the merits of the arguments on either side, there is also the practical consideration that TMC operators and URS arbitration providers will be challenged to successfully administer the existing model, much less a moving target subject to continual recalibration.
There must be some finality to both the policy and implementation phases and a date certain after which additional modifications or adjustments will be barred except in narrowly defined circumstances.
Intermediary Policy Implementation Parties Must be Under Contract
The staff paper notes correctly:
When a policy applies to a set of Internet stakeholders such as the gTLD registry and gTLD registrars, the implementation of the policy is typically achieved through the agreements that ICANN has with those stakeholders. ICANN also manages a contractual compliance function to ensure that the stakeholders are complying with their agreements (including the policies incorporated into those agreements).
While that statement is generally true, one atypical exception is that while both registries and registrars are contractually bound to abide by and enforce the decisions rendered by UDRP arbitration providers, those ICANN-accredited UDRP arbitrators have not been placed under any contractual agreement – which in turn means that ICANN has no means, other than through the extreme “death penalty” option of deaccreditation, to ensure that they are faithfully carrying out the policy incorporated within the UDRP. Further, while ICANN has entered into contractual agreements with those entities who will administer the TMC, we have no firm assurance that it will comply with the STI recommendation that URS providers be placed under contract.
We believe that ICANN should adopt the principle that any intermediary parties tasked with carrying out and enforcing ICANN policies should be placed under binding and flexibly enforceable contract so that ICANN can ensure that t
hey are complying with and uniformly implementing those policies.
Implementation Review Teams
The staff report notes that “the new concept of Implementation Review Teams [IRTs] applies to all pending PDPs, but not to PDPs that were conducted under the prior PDP rules”. We have no quarrel with the concept of establishing an IRT to implement a new policy. However, there must be assurance that an IRT will be open to membership by a diverse group of stakeholders, and that it operate in an open and transparent manner, to assure that the implementation is fully consistent with the overarching policy.
In this regard, we reference and take some issue with the paper’s statement that “one of the advisory-seeking mechanisms used recently was the IRT/STI process used in crafting the rights protection mechanism in the new gTLD program”. The IRT being referenced is a clear example of a model that should not be followed as it was created with no notice to the community, its membership was not open to broad representation by potentially affected stakeholders, it operated in an opaque manner, and its recommendations were so unbalanced that they generated intense opposition from broad sectors of the community.
The STI, which was in fact created as a result of intense community dissent against the IRT recommendations, is by contrast a worthwhile model to emulate. Its membership was open and diverse, it operated in an open and transparent manner, and its recommendations were unanimously adopted by the GNSO Council and subsequently by the ICANN Board.
Expert Support for Working Groups
The staff report notes that “PDP WGs do not necessarily have the legal and technical expertise to anticipate all the possible information that needs to be provided to ensure a smooth implementation; there is only agreement on the high level principles and the details are punted to the implementation phase.”
Having participated in various Working Groups, which consist of uncompensated volunteers who are generally stretched for time and have numerous other obligations, we believe that the lack of necessary legal and technical support often leads to policy recommendations that have failed to fully consider the practicality of implementation, as well as the additional thorny issues that may arise as implementation proceeds. There is evidence of this as various components of the new gTLD program are implemented.
The paper later notes that “if very specific implementation guidance is desired as part of the policy development, specific expertise (legal, technical) will be needed by WGs developing such guidance.” We agree with that observation, and believe that in many instances of policy development ICANN should support the efforts of the WGs by supplying expert assistance — either from the ranks of ICANN’s own staff or, when necessary, by hiring outside experts for defined tasks.
While not all implementation details and factors can be considered in the policy development phase, greater attention to them will generally result in better and more effective policies as well as avoid subsequent disputes and potential delays over implementation details.
Policy Adoption in the Absence of Consensus
The staff paper correctly notes:
Another associated issue is when resolution of a new issue should be supported by a consensus of the ICANN community, and when an issue arising from the implementation of a policy may be effectuated by the ICANN Board or ICANN staff upon taking a range of advice even if there is no consensus within the ICANN community.
The paper subsequently notes:
In ICANN’s multi-stakeholder bottom-up policy development structures, the inability to reach consensus on key issues could produce stalemates that by default preserve the “status quo’ instead of enabling badly needed changes.
We agree that a certain dilemma exists. On the one-hand, ICANN’s credibility depends upon operating as an open, transparent, and multi-stakeholder organization. On the other hand, if there is no consensus among the stakeholders ICANN can become paralyzed and fail to carry out necessary functions relating to the technical management of the DNS.
We would propose that this challenge be approached in the following manner:
- · Where an entirely new policy, or a highly significant alteration of an existing policy, is under consideration then the bias should be against its adoption when no clear consensus exists within the ICANN community. The Board should proceed with its adoption in such circumstances only by supermajority vote and with an accompanying explanation as to why its adoption is required for ICANN to carry out its core functions relating to the DNS and, further, is consistent with the public interest and other ICANN commitments to the global Internet community.
- · When an already adopted policy is being implemented, the bias should be in favor of implementation even when there is a lack of community consensus on all details of the implementation. In such instances, ICANN staff should provide a clear explanation in advance of implementation, and subject to some additional public comment and potential modification, explaining why a particular implementation method has been adopted notwithstanding substantial opposition. (Our position on this element is subject to our prior observations that ICANN should formally recognize that some implementation of policy may raise new and subsidiary policy matters, and that there should be some finality to both the policy and implementation phases.)
Conclusion
We hope that ICANN finds our views useful in its efforts to more clearly delineate policy develop
ment and adoption from the implementation of existing policy. We look forward to reviewing revised staff recommendations and analysis once all comments on this matter have been considered.
Thank you for considering our views in this important matter.
Sincerely,
Philip S. Corwin
Counsel, Internet Commerce Association