NCSG Position on ICANN Board-Staff Violation of Corporate Bylaws
by Imposing ÒTM+50 PolicyÓ on GNSO
7 November 2013
At the request
of ICANN legal staff as per its Cooperative Engagement Process (CEP), the
Non-Commercial Stakeholders Group (NCSG) provides this further explanation of our
complaint regarding the ICANN Board-staffÕs violation of the Corporate Bylaws
in its adoption of a policy that expressly contradicts the clearly enunciated
GNSO policy preference on that issue.[1]
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/3rd 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.
[1] We have a number of areas of concern and
believe that several sections of the Bylaws have been violated during this
process. The procedural inequities
and unequal representation in the staff created ÒStrawman
modelÓ that played into the TM+50 policy clearly violate subsections 4, 7 and 8
of section 2 of ICANNÕs Bylaws. The changes from an exact match to a TM+50
policy are not in compliance with GNSO Recommendations 1, 9 and 12 contained in
the GNSO Final Report of 8 August 2007 (GNSO Final Report) and its
implementation violates sections 9 and 10 of Annex A of the Bylaws. We reserve
the right to bring these and other issues before the Independent Review Panel
(IRP) should this CEP not fully resolve the matter at hand. Recognizing, however, that one of the
goals of the CEP is to narrow the issues under discussion weÕd like to focus
this brief on the most egregious of the Board-StaffÕs Bylaws violations, that
of sections 9 and 10 of Annex A of the Bylaws caused by the Board-StaffÕs
rejection of Recommendation 3 of the GNSO Final Report.
[2] Further background on this complaint and
NCSGÕs Reconsideration Request of staff adoption of TM+50 is available at:
https://community.icann.org/display/gnsononcomstake/ICANN+Unaccountability
[3] GNSO Policy Recommendation 3: ÒStrings
must not infringe the existing legal rights of others that are recognized or
enforceable under generally accepted and internationally recognized principles
of law. Examples of these legal
rights that are internationally recognized include, but are not limited to,
rights defined in the Paris Convention for the Protection of Industry Property
(in
particular trademark rights), the Universal Declaration of Human Rights
(UDHR) and the International Covenant on Civil and Political Rights (ICCPR) (in
particular freedom of expression rights).Ó
[4] http://www.gnso.icann.org/en/correspondence/robinson-to-chehade-28feb13-en.pdf