The Non-Commercial Stakeholders Group (NCSG) says ICANN Board-staff violated ICANN Bylaws by adopting the Trademark+50 policy without following the proper policy modification process

The specific policy at issue in this CEP is ICANN staff’s unilateral decision to grant trademark holders significantly greater rights via its “trademark plus 50” (“TM+50”) policy in contradiction to the GNSO Council’s policy recommendations and implementation guidance and the process described in ICANN’s Bylaws that govern its adoption of policy.

NCSG contends that the manner by which ICANN’s Board-staff adopted the TM+50 policy without following the proper policy modification process violates the organization’s Bylaws.

I.  ICANN Bylaws Annex A Mandates Bottom-Up Policy Development Process

ICANN’s Corporate Bylaws require the organization to develop and adopt policy via its Generic Name Supporting Organization (GNSO) in a “bottom up” fashion through the Policy Development Process (PDP) outlined in Annex A of the Bylaws:

“The following process shall govern the GNSO policy development process (“PDP”) until such time as modifications are recommended to and approved by the ICANN Board of Directors (“Board”). The role of the GNSO is outlined in Article X of these Bylaws.”

  – ICANN Corporate Bylaws – Annex A GNSO Policy Development Process  available at: http://www.icann.org/en/about/governance/bylaws#AnnexA and attached in full herewith below.

These Bylaws require ICANN staff to implement GNSO policies that have been approved (voted on) by both the GNSO Council and the ICANN Board of Directors.  They further permit the GNSO to oversee staff’s implementation of its approved policy recommendations and provide further guidance on that policy where appropriate.

Should the ICANN Board wish to adopt policy recommendations that contradict the GNSO Council’s policy recommendations, a process is outlined in Section 9 to permit that divergence should certain conditions be met.

It is precisely this reversal of GNSO negotiated policy by ICANN Board-staff without following proper process that is the heart of this complaint.  ICANN’s Bylaws provide for policy to be made from the bottom-up.  Thus if ICANN’s Board-staff wishes to impose contradictory policy from the top-down, it must adhere to the process in the Bylaws that includes procedural safeguards such as a discussion between the GNSO and the Board to work out policy differences followed by a 2/3^rd vote by the Board to overturn the GNSO’s preferred policy.

That Bylaws-required process was not followed, nor even attempted in this case.  Instead, the GNSO-approved policy was reversed by staff quietly issuing a memo-edict to inform the community that it had changed the previously negotiated GNSO policy on the issue in favor of trademark holders.[2]

II.  GNSO Policy Development Process Advised on Level of Trademark Privileges for New Generic Domains

The Principles and Recommendations contained in the GNSO Final Report of 8 August 2007 was approved with a super-majority vote by both the GNSO Council and the ICANN Board of Directors.  These Principles and Recommendations set forth the initial output of the GNSO’s Policy Development Process for new top-level domains.  Thus it is these GNSO Principles and Recommendations that begin to layout the policies which must be faithfully adhered to by staff in its implementation of policy for new generic top-level domain names.

GNSO Policy Recommendation 3 provides for the adoption of certain protections for trademark rights in new gtld policy.[3]  Specifically, Recommendation 3 provides for creating special privileges for trademark rights in new gtld policy that are enforceable and recognizable under international law.  This policy recommendation was approved by both the ICANN Board of Directors and by the GNSO Council in a super-majority vote.

Through this Recommendation 3, the GNSO and Board made an unambiguous, clear statement as to the degree of protection to be given trademark holders in the new generic top level domain program.  They are to be given privileges that are legally ‘recognized or enforceable under generally accepted and internationally recognized principles of law’.  Thus the privileges granted to trademark holders by the GNSO and Board in this policy recommendation are not without limit.  Staff was not granted carte blanche to invent entirely unprecedented rights for trademark holders at the expense of all others.  An extension of intellectual monopoly rights to include derivatives of trademarks simply is not supported by this recommendation.  Derivative privileges are not ‘recognized or enforceable under generally accepted and internationally recognized principles of law’ and not authorized by this policy recommendation.  Simply labeling this policy change “implementation” does not alter the fundamental fact that the policy to be implemented is “exact match” of trademarks.  It makes no logical sense for staff to claim that the implementation of the GNSO’s “exact match of a trademark only” standard actually means “50 derivations of a trademark”.

In the staff-developed TM+50 policy there appears to be a basic misunderstanding of trademark law and the role of arbitration rulings and cases in the legal acquis.  Case decisions apply only to the specific fact situation involved and only to specific parties.  Arbitration decisions, such as the UDRP, have the same limitation and as a system of privatized law less generalized applicability.  TM+50’s automated extension of case decisions to unrelated parties or fact patterns not at issue in the specific cases involved is itself contrary to generally accepted and recognized principles of trademark law, both national and international.  Yet this is the method used by the TMCH Validator in determining whether to place trademark derivatives in the TMCH.

Importantly, the GNSO did not approve of this policy; instead ICANN staff invented it out of thin air and is attempting to impose it on the entire world absent any legitimate process or connection to trademark legal principles.  Furthermore, ICANN ignores its obligations under Recommendation 3 to protect the freedom of expression rights of domain name registrants and significantly undercuts those rights by granting excessive and unprecedented privileges to trademark holders at the expense of these other legitimate interests.

III.  GNSO Council Oversight of Implementation of GNSO Approved Policy

Section 10 of ICANN Bylaws Annex A instructs ICANN staff to implement the policy that was adopted by the Board and by the GNSO Council through its PDP process, and importantly, empowers the GNSO Council to provide further guidance to staff in the implementation of the GNSO’s approved policy.

Section 10 of ICANN Bylaws Annex A reads:

Implementation of Approved Policies.

Upon a final decision of the Board adopting the policy, the Board shall, as appropriate, give authorization or direction to ICANN staff to work with the GNSO Council to create an implementation plan based upon the implementation recommendations identified in the Final Report, and to implement the policy. The GNSO Council may, but is not required to, direct the creation of an implementation review team to assist in implementation of the policy.

This important over-sight function empowers the GNSO to ensure that the bottom-up process is followed and that the staff’s implementation efforts remain faithful to the GNSO Council’s intentions in its policy recommendations.  Council’s oversight role over policy implementation is what ensures ICANN is in-fact “bottom up” in its policy development process and that staff cannot simply reverse a GNSO policy decision by labeling it “implementation” of the GNSO’s policy.

A.  GNSO Instructed ICANN Staff Three Times That it Did Not Want Standard Other Than “Exact/Identical Match” of Trademarks

Through the course of staff’s “implementation” of GNSO Policy Recommendation 3, staff created a Trademark Clearinghouse (TMCH) that gives special privileges to trademark holders that have never existed before this policy.  In particular, ICANN staff unilaterally adopted the controversial TM+50 policy, which has no basis in international law and which the GNSO thrice told ICANN staff was not what it meant when it recommended that new GTLD policy should protect trademarks.

On the specific issue of whether to give trademark owners privileges over derivations of their trademarks, on three separate occasions the GNSO Council expressly said that proposals to give more than exact/identical match rights to trademark owners was not acceptable.

In a 12 October 2009 letter to the GNSO Council the Board asked the GNSO to assist “in the implementation of the GNSO recommendation that “strings must not infringe the existing legal rights of others that are recognized or enforceable under generally accepted and internationally recognized principles of law” (GNSO Policy Recommendation 3).   The GNSO subsequently gave such policy implementation guidance to ICANN and that guidance was then directly contradicted by staff.

i)              GNSO’s Special Trademark Issues (STI) Review Team Said “Identical Match” Standard

Although not required to do so, on 28 October 2009 the GNSO Council pursuant to Section 10 of Annex A of the ICANN Bylaws chose to create the Special Trademark Issues Review (STI) team to assist the Board and staff specifically with implementation of Recommendation 3 of the GNSO Final Report of 8 August 2007 (GNSO Council Resolution 20091028-3).  The STI team consisted of 20 members, including alternates, from all component members of the GNSO.  An observer from the Governmental Advisory Committee (GAC) was also part of the STI process.

After extensive work and deliberation, the STI Report was sent to the GNSO Council on 11 December 2009.  The STI had fully considered and debated the exact match standard, along with other options.  Section 4 of the STI Trademark Clearinghouse Proposal is titled ‘Marks Eligible for Inclusion in the TC.’ Section 4.3 of the recommendations, titled ‘Conversion of Mark into TC Database’ clearly states:

“The TC Database should be structured to report to registries strings that are considered an “identical match” with the validated trademarks. “Identical match” means that the domain name consists of the complete and identical textual elements of the Mark. In this regard: (a) spaces contained within a mark that are either replaced by hyphens (and vice versa) or omitted, (b) only certain special characters contained within a trademark are spelt out with appropriate words describing it (@ and &.), (c) punctuation or special characters contained within a mark that are unable to be used in a second-level domain name may either be (i) omitted or (ii) replaced by spaces, hyphens or underscores and still be considered identical matches, and (d) no plural and no “marks contain” would qualify for inclusion.”

This is a strict exact match standard.

On 17 December 2012 the GNSO Council resolved that it “hereby approves the overall package of recommendations contained in the STI Report, and resolves that the STI proposal to create a Trademark Clearinghouse and a Uniform Rapid Suspension procedure as described in the STI Report are more effective and implementable solutions than the corresponding staff implementation models that were described in memoranda accompanying the Draft Applicant Guidebook Version 3.”

Staff was asked to forward the GNSO recommendations to the Board.  It should be noted that the resolution approving the contents of the STI Report, including the exact match standard, was passed unanimously by a role call vote of all GNSO Councilors present and voting.

ii)            Implementation Recommendation Team (ITR) Said “Identical” Term Standard for Trademarks

The Board had previously received a recommendation for an exact match standard from another implementation review team consisting of GNSO members. The exact match standard was recommended to the Board earlier in the year by the Intellectual Property Constituency’s (IPC) Implementation Recommendation Team (IRT). The IRT was formed by the IPC in response to a Board request of 6 March 2009 seeking “solutions for potential risks to trademark holders in the implementation of new gTLDs.”

In it’s Final Report to the Board of 29 May 2009 the IRT recommended:

“A Pre-Launch IP Claims Service that will notify new gTLD applicants and trademark owners that a current validated right exists for the identical term being applied for at the second level.”  The Pre-Launch IP Claims Service became the Trademark Clearinghouse during the subsequent STI process.

Even the IRT Report, which was the most privileging of trademark holders’ rights during ICANN’s new GTLD policy development process, was still an identical term / exact match standard for inclusion into the TMCH.

iii)          GNSO Council Letter to CEO Expressed Disapproval of TM+50 Policy and Expanding Scope of Trademark Rights

On 28 February 2013, GNSO Council Chair Jonathan Robinson sent a letter to ICANN CEO Fade Chehade regarding staff’s proposed adoption of the TM+50 policy and other changes to new gtld policy.[4]  On the issue of the TM+50 policy, the GNSO Council expressly instructed staff that “the proposals on changes to the TMCH implementation amount to an expansion of trademark scope.”  The GNSO Council elaborated further on its lack of support for expanding trademark rights as proposed by staff’s TM+50 policy:

“We believe that this, together with the potential impact of such proposals on the full community, make them a matter of policy, not implementation. The majority of the Council believes – consistent with what the Council unanimously agreed previously – that protection policies for new gTLDs are sufficient and need not be revisited now. If the community seeks to augment existing RPMs, they are appropriately the subjects of future Council managed GNSO policy activity.

Indeed, ICANN Chairman Steve Crocker and other Board members set an expectation in Toronto that new RPM proposals should have the Council’s support to be considered now:

“Three more items. The rights protection in new gTLDs. The Intellectual Property Constituency and business constituency reached consensus on further mechanisms for new gTLD rights protection and agreed to socialize these to the rest of the GNSO and the Board looks forward to receiving input on these suggestions from the GNSO. So that is our plan, so to speak, which is we will continue to listen and wait for this to come up. “

http://toronto45.icann.org/meetings/toronto2012/transcript-public-forum-18oct12-en.pdf, at p.12.

The Council has carefully considered and reviewed these proposals and most do not have the support of the Council’s majority.”

IV.  Board-Staff Ignored Bylaws Procedure in Modification of GNSO Policy Advice

As stated above, the Board is not required to accept policy recommendations developed through the GNSO policy development process in all circumstances.  If the Board believes following a particular piece of GNSO policy advice will harm the community, the Bylaws includes a provision to modify the GNSO-approved advice.

Thus if the Board wanted to expand trademark privileges beyond those recommended by the GNSO in its Final Report and as explained in Council’s subsequent implementation guidance, the Board simply needed to follow the policy modification procedure outlined in Annex A, Section 9 of the Bylaws:

a.  Any PDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of the ICANN community or ICANN.

b. In the event that the Board determines, in accordance with paragraph a above, that the policy recommended by a GNSO Supermajority Vote or less than a GNSO Supermajority vote is not in the best interests of the ICANN community or ICANN (the Corporation), the Board shall (i) articulate the reasons for its determination in a report to the Council (the “Board Statement”); and (ii) submit the Board Statement to the Council.

c. The Council shall review the Board Statement for discussion with the Board as soon as feasible after the Council’s receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board will discuss the Board Statement.

d. At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation, and communicate that conclusion (the “Supplemental Recommendation”) to the Board, including an explanation for the then-current recommendation. In the event that the Council is able to reach a GNSO Supermajority Vote on the Supplemental Recommendation, the Board shall adopt the recommendation unless more than two-thirds (2/3) of the Board determines that such policy is not in the interests of the ICANN community or ICANN. For any Supplemental Recommendation approved by less than a GNSO Supermajority Vote, a majority vote of the Board shall be sufficient to determine that the policy in the Supplemental Recommendation is not in the best interest of the ICANN community or ICANN.

ICANN’s Board did not follow any of the above Bylaws-required processes to alter the GNSO’s policy recommendation and expand the scope of trademark privileges beyond what the community was willing to grant to trademark holders in its bottom-up process.  The mere issuance of a memo from ICANN staff is insufficient authority to change a policy that was approved by the GNSO Council and Board of Directors via the PDP process.

 V.  Conclusion:  ICANN Violated Bylaws by Imposing TM+50 Policy Against GNSO’s Advice and Bottom-Up Process

This unilateral staff decision announced via a memo edict is an illegitimate process for modifying the policy approved by the GNSO Council and Board of Directors.  The Board could have agreed with staff’s preferred policy and modified GNSO policy by following Section 9 of the Bylaws Annex A, but it did not do so.

Section 10 furthermore protects the integrity of ICANN’s bottom-up policy development process by authorizing the GNSO Council to oversee staff’s implementation of the GNSO’s policy recommendations.  Both Sections 9 and 10 of ICANN’s Bylaws Annex A were improperly ignored by the unilateral imposition of the TM+50 policy on the GNSO against the community’s expressly stated wishes.  This violation of ICANN’s Bylaws, which are meant to ensure ICANN will remain faithful to a bottom-up process for developing policy is the harm NCSG hopes to correct through this action.  These Bylaws violations need to be reversed, either voluntarily by the Board or through the outcome of an Independent Review Process.

It is without doubt that in terms of policy recommendations and implementation guidance the GNSO has without deviation or ambiguity supported an exact match requirement for mark inclusion in the Trademark Clearinghouse.  We need not repeat the more generalized argumentation here we have already presented to the Board in Reconsideration Request 13-3.  We merely state the obvious:

In adopting the staff-created TM+50 proposal the Board has ignored all GNSO policy advice and implementation guidance on the subject.  It instead chose to allow staff to create it’s own (unprecedented) policy and terms of implementation in order to appease insatiable trademark holders at the expense of all other interests.   In doing so, ICANN’s Board has made a mockery of the bottom-up multi-stakeholder model it claims ICANN represents.

---

ICANN Bylaws

 Annex A:  GNSO Policy Development Process

The following process shall govern the GNSO policy development process (“PDP”) until such time as modifications are recommended to and approved by the ICANN Board of Directors (“Board”). The role of the GNSO is outlined in Article X of these Bylaws. If the GNSO is conducting activities that are not intended to result in a Consensus Policy, the Council may act through other processes.

Section 1. Required Elements of a Policy Development Process

The following elements are required at a minimum to form Consensus Policies as defined within ICANN contracts, and any other policies for which the GNSO Council requests application of this Annex A:

a. Final Issue Report requested by the Board, the GNSO Council (“Council”) or Advisory Committee, which should include at a minimum a) the proposed issue raised for consideration, b) the identity of the party submitting the issue, and c) how that party Is affected by the issue;

b. Formal initiation of the Policy Development Process by the Council;

c. Formation of a Working Group or other designated work method;

d. Initial Report produced by a Working Group or other designated work method;

e. Final Report produced by a Working Group, or other designated work method, and forwarded to the Council for deliberation;

f. Council approval of PDP Recommendations contained in the Final Report, by the required thresholds;

g. PDP Recommendations and Final Report shall be forwarded to the Board through a Recommendations Report approved by the Council]; and

h. Board approval of PDP Recommendations.

Section 2. Policy Development Process Manual

The GNSO shall maintain a Policy Development Process Manual (PDP Manual) within the operating procedures of the GNSO maintained by the GNSO Council. The PDP Manual shall contain specific additional guidance on completion of all elements of a PDP, including those elements that are not otherwise defined in these Bylaws. The PDP Manual and any amendments thereto are subject to a twenty-one (21) day public comment period at minimum, as well as Board oversight and review, as specified at Article X, Section 3.6.

Section 3. Requesting an Issue Report

Board Request. The Board may request an Issue Report by instructing the GNSO Council (“Council”) to begin the process outlined the PDP Manual. In the event the Board makes a request for an Issue Report, the Board should provide a mechanism by which the GNSO Council can consult with the Board to provide information on the scope, timing, and priority of the request for an Issue Report.

Council Request. The GNSO Council may request an Issue Report by a vote of at least one-fourth (1/4) of the members of the Council of each House or a majority of one House.

Advisory Committee Request. An Advisory Committee may raise an issue for policy development by action of such committee to request an Issue Report, and transmission of that request to the Staff Manager and GNSO Council.

Section 4. Creation of an Issue Report

Within forty-five (45) calendar days after receipt of either (i) an instruction from the Board; (ii) a properly supported motion from the GNSO Council; or (iii) a properly supported motion from an Advisory Committee, the Staff Manager will create a report (a “Preliminary Issue Report”). In the event the Staff Manager determines that more time is necessary to create the Preliminary Issue Report, the Staff Manager may request an extension of time for completion of the Preliminary Issue Report.

The following elements should be considered in the Issue Report:

a) The proposed issue raised for consideration;

b) The identity of the party submitting the request for the Issue Report;

c) How that party is affected by the issue, if known;

d) Support for the issue to initiate the PDP, if known;

e) The opinion of the ICANN General Counsel regarding whether the issue proposed for consideration within the Policy Development Process is properly within the scope of the ICANN’s mission, policy process and more specifically the role of the GNSO as set forth in the Bylaws.

f) The opinion of ICANN Staff as to whether the Council should initiate the PDP on the issue

Upon completion of the Preliminary Issue Report, the Preliminary Issue Report shall be posted on the ICANN website for a public comment period that complies with the designated practice for public comment periods within ICANN.

The Staff Manager is responsible for drafting a summary and analysis of the public comments received on the Preliminary Issue Report and producing a Final Issue Report based upon the comments received. The Staff Manager should forward the Final Issue Report, along with any summary and analysis of the public comments received, to the Chair of the GNSO Council for consideration for initiation of a PDP.

Section 5. Initiation of the PDP

The Council may initiate the PDP as follows:

Board Request: If the Board requested an Issue Report, the Council, within the timeframe set forth in the PDP Manual, shall initiate a PDP. No vote is required for such action.

GNSO Council or Advisory Committee Requests: The Council may only initiate the PDP by a vote of the Council. Initiation of a PDP requires a vote as set forth in Article X, Section 3, paragraph 9(b) and (c) in favor of initiating the PDP.

Section 6. Reports

An Initial Report should be delivered to the GNSO Council and posted for a public comment period that complies with the designated practice for public comment periods within ICANN, which time may be extended in accordance with the PDP Manual. Following the review of the comments received and, if required, additional deliberations, a Final Report shall be produced for transmission to the Council.

Section 7. Council Deliberation

Upon receipt of a Final Report, whether as the result of a working group or otherwise, the Council chair will (i) distribute the Final Report to all Council members; and (ii) call for Council deliberation on the matter in accordance with the PDP Manual.

The Council approval process is set forth in Article X, Section 3, paragraph 9(d) through (g), as supplemented by the PDP Manual.

Section 8. Preparation of the Board Report

If the PDP recommendations contained in the Final Report are approved by the GNSO Council, a Recommendations Report shall be approved by the GNSO Council for delivery to the ICANN Board.

Section 9. Board Approval Processes

The Board will meet to discuss the GNSO Council recommendation as soon as feasible, but preferably not later than the second meeting after receipt of the Board Report from the Staff Manager. Board deliberation on the PDP Recommendations contained within the Recommendations Report shall proceed as follows:

a. Any PDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of the ICANN community or ICANN.

b. In the event that the Board determines, in accordance with paragraph a above, that the policy recommended by a GNSO Supermajority Vote or less than a GNSO Supermajority vote is not in the best interests of the ICANN community or ICANN (the Corporation), the Board shall (i) articulate the reasons for its determination in a report to the Council (the “Board Statement”); and (ii) submit the Board Statement to the Council.

c. The Council shall review the Board Statement for discussion with the Board as soon as feasible after the Council’s receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board will discuss the Board Statement.

d. At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation, and communicate that conclusion (the “Supplemental Recommendation”) to the Board, including an explanation for the then-current recommendation. In the event that the Council is able to reach a GNSO Supermajority Vote on the Supplemental Recommendation, the Board shall adopt the recommendation unless more than two-thirds (2/3) of the Board determines that such policy is not in the interests of the ICANN community or ICANN. For any Supplemental Recommendation approved by less than a GNSO Supermajority Vote, a majority vote of the Board shall be sufficient to determine that the policy in the Supplemental Recommendation is not in the best interest of the ICANN community or ICANN.

Section 10. Implementation of Approved Policies

Upon a final decision of the Board adopting the policy, the Board shall, as appropriate, give authorization or direction to ICANN staff to work with the GNSO Council to create an implementation plan based upon the implementation recommendations identified in the Final Report, and to implement the policy. The GNSO Council may, but is not required to, direct the creation of an implementation review team to assist in implementation of the policy.

Section 11. Maintenance of Records

Throughout the PDP, from policy suggestion to a final decision by the Board, ICANN will maintain on the Website, a status web page detailing the progress of each PDP issue. Such status page will outline the completed and upcoming steps in the PDP process, and contain links to key resources (e.g. Reports, Comments Fora, WG Discussions, etc.).

Section 12. Additional Definitions

“Comment Site”, “Comment Forum”, “Comments For a” and “Website” refer to one or more websites designated by ICANN on which notifications and comments regarding the PDP will be posted.

“Supermajority Vote” means a vote of more than sixty-six (66) percent of the members present at a meeting of the applicable body, with the exception of the GNSO Council.

“Staff Manager” means an ICANN staff person(s) who manages the PDP.

“GNSO Supermajority Vote” shall have the meaning set forth in the Bylaws.

Section 13. Applicability

The procedures of this Annex A shall be applicable to all requests for Issue Reports and PDPs initiated after 8 December 2011. For all ongoing PDPs initiated prior to 8 December 2011, the Council shall determine the feasibility of transitioning to the procedures set forth in this Annex A for all remaining steps within the PDP. If the Council determines that any ongoing PDP cannot be feasibly transitioned to these updated procedures, the PDP shall be concluded according to the procedures set forth in Annex A in force on 7 December 2011.