Updated GNSO Working Group Charter Template

Version Date: 14 January 2020

WG Name:	TBD
Section I: Working Group Identification
Chartering Organization(s):	Generic Names Supporting Organization (GNSO) Council
Charter Approval Date:	<Enter Approval Date>
Name of WG Leadership:	<Enter Elected WG Leadership)>
Name(s) of Appointed Liaison(s):	<Enter Liaison>
WG Workspace URL:	<Enter Active Project URL from GNSO Site>
WG Mailing List:	<Enter Mailman archive link>
GNSO Council Resolution:	Title:	<Enter Resolution Title>
Ref # & Link:	<Enter Resolution link>
Important Document Links:
Section II: Mission, Purpose, and Deliverables
Mission & Scope:
Background At its meeting on DD MONTH YYYY, the GNSO Council unanimously adopted the initiation of a Working Group to deliberate the issues of topic X [.......TO BE COMPLETED BY CHARTER DRAFTING TEAM……] Mission and Scope This Working Group (WG) is tasked to provide the GNSO Council with policy recommendations regarding whether to [.......TO BE COMPLETED BY CHARTER DRAFTING TEAM……] As part of its deliberations, the PDP WG should, at a minimum, consider the following issues detailed in the [Final Issue Report – CHARTER DRAFTING TEAM TO INSERT LINK]. These are: Issue 1 Issue 2 Issue 3 Issue 4 As a result, the WG should deliberate and consider the following Charter questions: Charter Question A Charter Question B Charter Question XX [.......TO BE COMPLETED BY CHARTER DRAFTING TEAM……] For purposes of this PDP, the scope of this WG is limited to [.......TO BE COMPLETED BY CHARTER DRAFTING TEAM……]
Deliverables:
To develop, at a minimum, an Initial Report and a Final Report regarding the WG’s recommendations on issues relating to the [.......TO BE COMPLETED BY CHARTER DRAFTING TEAM……], following the processes described in Annex A of the ICANN Bylaws and the GNSO PDP Manual. If the WG concludes with any recommendations, the WG shall (or recommend the subsequent policy Implementation Review Team to) conduct a policy impact analysis and identify a set of metrics to measure the effectiveness of the policy change, including source(s) of baseline data for that purpose: Identification of policy goals Identification of metrics used to measure whether policy goals are achieved Identification of potential problems in attaining the data or developing the metrics A suggested timeframe in which the measures should be performed Define current state baselines of the policy and define initial benchmarks that define success or failure Metrics may include but not limited to (Refer to the Hints & Tips Page): ICANN Compliance data Industry metric sources Community input via public comment Surveys or studies
Data and Metric Requirements:
The WG should as soon as practicable: Determine a set of questions which, when answered, provide the insight necessary to achieve the policy goals. Determine whether certain data is required to help understand a specific issue or answer a charter question. Determine a set of data and metrics which can be collected and analyzed to help answer the specific question. Submit a Working Group Metrics Request Form (see GNSO Working Group Guidelines Section 4.5), if data gathering at the charter drafting phase or during the working phase is deemed necessary. WG leaders shall review the Guidance document below to understand the need for performing due diligence before submitting a data gathering request to the GNSO Council. Guidance: Checklist: Criteria to Evaluate Request for Data Gathering Instruction for Charter Drafting Team Please include the Working Group Metrics Request Form if data gathering during the chartering phase is required Example: Request Form submitted by the GNSO Review of All Rights Protection Mechanisms in All gTLDs PDP Working Group
Section III: Project Management
Work Product Requirement:
The WG shall respect the timelines and deliverables as outlined in Annex A of the ICANN Bylaws and the PDP Manual. The WG leadership, in collaboration with the WG support staff and GNSO Council liaison, shall use a standard set of project management work products that help plan, guide, track, and report the progress of the WG from start to finish, and include the necessary data and information to assess the progress of the WG. These work products include: Summary Timeline Project Situation Report Project Plan Work Plan Action Items Guidance: GNSO Project Work Product Catalog Instruction for Charter Drafting Team Please include any work products that can be presented during the chartering phase. Example: Work products from the EPDP Team on the Temporary Specification for gTLD Registration Data
Project Status & Condition Assessment:
The WG leadership, in collaboration with the WG support staff and the GNSO Council liaison, shall assess the Status and Condition of the project at least once a month. Such frequency is required in preparation for the GNSO Council monthly meeting, where At-Risk or In-Trouble projects are subject to review by GNSO Council leadership, and in some instances may be deliberated by the full GNSO Council. The WG leadership, in collaboration with the WG support staff and the GNSO Council Liaison, shall use an escalation procedure (see Guidance documents below), which defines specific conditions that trigger the execution of a repeatable mitigation plan. The objective of this exercise is to return the project to an acceptable state ultimately achieving its planned outcomes. Guidance: Project Status and Condition Change Procedure
Project Change Request:
The WG shall submit a Project Change Request (PCR) Form to the GNSO Council when its deliverable and baseline delivery date are revised. The PCR shall include a rationale for why these changes were made, their impacts on the overall timeframe of the PDP or any other interdependencies, and a proposed remediation plan. The use of the PCR mostly occurs when primary deliverable dates are changed due to unforeseen or extreme circumstance. However, it can also be used to document changes in the deliverable requirements that may not have been identified in the chartering process. When the PCR is required, it should be completed by the WG leadership team and it will likely be presented to the GNSO Council for approval. Guidance: Project Change Request Form Example: Project Change Request Form submitted by the EPDP Team on the Temporary Specification for gTLD Registration Data
Resources Tracking:
The purpose for resource tracking is to deliver its work according to the work plan and be responsible for managing these resources. For projects where dedicated funds are provided outside of budgeted policy activities, the WG shall provide regular budget versus actual expense reporting updates using a GNSO approved tool to allow for a better tracking of the use of resources and budget. Guidance: GNSO Project Work Product Catalog Instruction for Charter Drafting Team Upon project scope definition, the Charter Drafting Team shall estimate the community resources and financial budget, if applicable (for example, external legal advice or mediation services, face-to-face meetings, etc.), that the WG needs. Note, however a completed project plan will not usually occur until after a working group has performed a cursory review of the in-scope issues and confirmed its work plan. Therefore, the formal project plan should be returned back to the GNSO Council for final confirmation and formal initiation of the project Status, Condition, and Delivery Date. Please include any work products for resource tracking purposes that can be produced during the chartering phase.
Section IV: Formation, Staffing, and Organization
Working Group Model:
Instruction for Charter Drafting Team Please specify which model the WG will use, with options including but not limited to: Open Model Representative Model (Full Community) Representative & Open Model Please provide detailed rationale for the chosen Working Group model. Guidance: A Comparison Table of Working Group Models
Membership Structure:
Instruction for Charter Drafting Team Please provide a detailed description of the composition of the working group membership, including members, participants, and/or observers, as applicable. Please specify how an observer becomes a member, if applicable. Guidance: A Comparison Table of Working Group Models Example: Charter of the EPDP Team on the Temporary Specification for gTLD Registration Data Additional Notes - Consider for Inclusion by Charter Drafting Team The GNSO Secretariat should circulate a ‘Call For Volunteers’ in accordance with the group structure determined by the GNSO Council or this Charter drafting team: Publication of announcement on relevant ICANN web sites including but not limited to the GNSO and other Supporting Organizations and Advisory Committee web pages; and Distribution of the announcement to GNSO Stakeholder Groups, Constituencies and other ICANN Supporting Organizations and Advisory Committees The standard WG roles, functions & duties shall be applicable as specified in Section 2.2 of the Working Group Guidelines.
Membership Criteria:
A. Expected Skills for Working Group Members WG members shall review the full text of the Guidance document below to understand the responsibilities and skills that they are expected to have in order to fully participate in the WG activities. Guidance: Working Group Member Skills Guide Instruction for Charter Drafting Team Please provide a description of expected responsibilities for WG members that need to be highlighted in the charter, including associated skills required and available resources to carry out these responsibilities. If specific expertise is needed or required for members, please specify whether any independent evaluation needs to be carried out to confirm that members have required expertise. B. Joining of New Members After Project Launch The existing practice as stated in the Working Group Guidelines is that anyone can join a WG at any point as long as they get up to speed and do not reopen previously closed topics, unless they provide new information. Nonetheless, the Working Group Guidelines do not prevent WG leadership from deciding, in consultation with the WG, whether new members can be accepted after the start of the WG effort. Guidance: Criteria for Joining of New Members After a PDP Working Group is Formed or Rechartered Instruction for Charter Drafting Team If applicable, please specify: The circumstances that new membership may be suspended; The exceptional cases that new members can join after the WG is formed. C. Experts Contributors Expert contributors are not expected to participate in any consensus designation process, but provide perspective/expertise/knowledge to the PDP WG. The Council may be able to use an independent evaluation process (e.g., GNSO Council Standing Selection Committee) to confirm whether those individuals have demonstrated the expertise/knowledge/perspective. Instruction for Charter Drafting Team Please specify if the GNSO Council wishes to run an open call for expert contributors in order to recruit individuals who have expertise, knowledge, and/or perspective that otherwise would not be present in the PDP.
Leadership Structure:
Instruction for Charter Drafting Team Please provide a description of the leadership structure of the WG, including the mechanism for selecting/confirming the Chair/Vice-Chair(s)/Co-Chairs(s), as applicable. Guidance: A Comparison Table of Working Group Models Example: Charter of the EPDP Team on the Temporary Specification for gTLD Registration Data
Leadership Criteria:
WG leaders shall review the full text of the Guidance document below to understand the expectations for WG leaders, including their role & responsibilities as well as minimum skills/expertise required. In short, a WG leader is expected to: Encourage representational balance Encourage adherence to ICANN’s Expected Standards of Behavior & Community Anti-Harassment Policy Ensure WG documents represent the diversity of views Make consensus designation on working group recommendations Handle working group complaint process Be versed in GNSO Operating Procedures Assume a neutral and impartial role Build consensus Balance working group openness with effectiveness Make time commitment Guidance: Expectations for Working Group Leaders that Outline Role & Responsibilities as well as Minimum Skills / Expertise Required Instruction for Charter Drafting Team Please provide a description of role & responsibilities and skills/expertise required for WG leaders that need to be highlighted in the charter. If Expressions of Interest will be sought for WG leaders, please include the relevant text in the request for Expressions of Interest in this section. Example: Charter of the EPDP Team on the Temporary Specification for gTLD Registration Data
Leadership Review:
WG leadership shall review the full text of Guidance documents below to understand the regular review of WG leadership performance by the GNSO Council, as well as the member survey that feeds into the review. Guidance: Regular Review of PDP Working Group Leadership by GNSO Council & PDP Working Group Member Survey on Leadership Performance Instruction for Charter Drafting Team Please provide the expected frequency and timeframe for the WG leadership review, including the expected timeframe for the PDP WG member survey on leadership performance. Additional Notes - Consider for Inclusion by Charter Drafting Team The review of PDP WG leadership provides a regular opportunity for the GNSO Council to check in with PDP WG leadership and liaisons to identify resources or input that Council may need to provide, as well as opportunities for the leadership team to improve. The review also enables the GNSO Council to work with the PDP WG leadership and Council liaison to develop and execute a plan to address possible issues/opportunities identified. The schedule of reviews will be established in the charter of each PDP WG and will likely be different for each depending on the length, complexity, and structure of the PDP. Reviews may also be initiated by Council leadership and/or the Council liaison to the WG in response to circumstances indicating that a review is necessary. The following is a non-exhaustive list of issues that Council leadership and Council liaison could seek to address in the review process. There is substantial evidence that the PDP WG leadership team or an individual on the PDP WG leadership team: Has difficulty facilitating goal-oriented WG meetings aligned with the requirements of the WG’s charter and workplan. Is unable to effectively manage WG members’ disruptive behaviors, and this is negatively impacting the ability of the WG to complete its work or is discouraging participation by a diverse set of members. Is consistently unable to keep the WG on track to meet target deadlines. Does not communicate effectively with WG members or respond to concerns raised by members. Does not act in a neutral, fair, and objective manner in the context of the WG, for example by advocating for his or her own agenda or discouraging perspectives with which he or she disagrees. The Council leadership and Council liaison may further want to consider whether members of the PDP WG leadership team are able to work together effectively in a collegial manner as they manage the WG and communicate with members. Feeding into the regular review of PDP WG leadership by the GNSO Council, an anonymous survey will be conducted in advance of the scheduled review so that the results can be taken into account. The survey will be distributed electronically at regular intervals by the GNSO Council to PDP WG members. The survey will be open for at least one week. The exact interval at which the survey is conducted will be different per WG and may be tied to the length of the WG’s timeline or specific milestones included in the charter. Specific triggers may also be identified that will result in the launch of a survey.
GNSO Council Liaison
The GNSO Council shall appoint a liaison who is accountable to the GNSO. The liaison must be a member of the Council, and the Council recommends that the liaison should be a Council member and be able to serve during the life of this WG. The liaison shall review the Guidance documents below. Guidance: New Liaison Briefing and Liaison Handover & GNSO Council Liaison Supplemental Guidance Instruction for Charter Drafting Team Please provide a description of role & responsibilities for GNSO Council liaison to the WG that need to be highlighted in the charter here. Example: Charter of the EPDP Team on the Temporary Specification for gTLD Registration Data Additional Notes - Consider for Inclusion by Charter Drafting Team The liaison shall complete the following actions for onboarding purposes: Review the GNSO Council liaison to the WGs - Role Description; Review the New Liaison Briefing and Liaison Handover document; Consult the supplemental guidance developed to provide more precision in their responsibilities and the frequency in which they must be carried out; Familiarize with the provisions of the GNSO Operating Procedures relevant to liaisons; Subscribe to the PDP mailing lists and relevant sub teams; Subscribe to the PDP Leadership mailing list(s), if applicable. In addition, add o the PDP Leadership Skype chat (or other communication channel) if applicable; Consider requesting a catch up call with the relevant GNSO policy support staff. This call should clarify the role of the liaison in terms of PDP conference call attendance, expected responsibilities and an update as to the current status of the PDP if already in operation (milestones and anticipated hurdles); Review links to the wiki workspaces and mailing list archives via email; (If the PDP is already in operation) Consider requesting that PDP Leadership and the outgoing liaison(s) share relevant briefing documents specific to the PDP, to highlight the scope of the PDP charter, current status, timeline, milestones, problem areas/challenges, anticipated hurdles, etc; (If the PDP is already operation) Participate in an onboarding conference call with the incoming and outgoing liaisons as well as PDP Leadership; GNSO policy support staff will also be present on the call. Importantly, the liaison is expected to fulfil his/her role in a neutral manner. This means that everything the liaison does during his/her tenure, including but not limited to participating in WG calls, reporting status, conveying information, and escalating issues, should be done in that neutral manner. In short, the GNSO Council liaison is expected to: Fulfill liaison role in a neutral manner Be a regular participant of WG meetings Participate in regular meetings with WG leadership Report to Council on the WG progress Serve as an interim WG Chair until a Chair is named Convey to Council on WG communications, questions, concerns Inform WG leadership about Council activities impacting the WG Refer to Council questions related to WG Charter Assist or engage when WG faces challenges Assist in case of abuse of ICANN’s Expected Standards of Behavior Assist with knowledge of WG processes and practices Facilitate when there is disagreement regarding consensus designation Facilitate when a Section 3.7 Complaint Process is invoked
Support Staff:
The ICANN Staff assigned to the WG will fully support the work of the Working Group as requested by the Chair including meeting support, document drafting, editing and distribution and other substantive contributions when deemed appropriate. Staff assignments to the Working Group: GNSO Secretariat ICANN policy staff members
Section V: Rules of Engagement
Statements of Interest (SOI) Guidelines:
Each member of the WG is required to submit an SOI in accordance with Section 5 of the GNSO Operating Procedures.
Statement of Participation:
Each member of the WG must acknowledge and accept the Statement of Participation (as provided below), including ICANN’s Expected Standards of Behavior, before he/she can participate in the WG. Statement of Participation As a member of the [name of group]: I agree to genuinely cooperate with fellow members of the [group] to reach consensus on the issues outlined in the Charter. I understand this does not mean that I am unable to fully represent the views of myself or the organization I represent but rather, where there are areas of disagreement, I will commit to work with others to reach a compromise position to the extent that I am able to do so; I acknowledge the remit of the GNSO to develop consensus policies for generic top level domains. As such, I will abide by the recommended working methods and rules of engagement as outlined in the Charter, particularly as it relates to designating consensus and other relevant rules in GNSO Working Group Guidelines; I will treat all members of the [group] with civility both face-to-face and online, and I will be respectful of their time and commitment to this effort. I will act in a reasonable, objective, and informed manner during my participation in this [group] and will not disrupt the work of the [group] in bad faith; I will make best efforts to regularly attend all scheduled meetings and send apologies in advance when I am unable to attend. I will take assignments allocated to me during the course of the [group] seriously and complete these within the requested timeframe. [If applicable] As and when appropriate I shall seek to be replaced by my designated Alternate in accordance with the wishes of my appointing organization; I agree to act in accordance with ICANN Expected Standards of Behavior, particularly as they relate to: Acting in accordance with, and in the spirit of, ICANN’s mission and core values as provided in ICANN's Bylaws; Listening to the views of all stakeholders and working to build consensus; and Promoting ethical and responsible behavior; I agree to adhere to any applicable conflict of interest policies and the Statement of Interest (SOI) Policy within the GNSO Operating Procedures, especially as it relates to the completeness, accuracy, and timeliness of the initial completion and maintenance of my SOI; and I agree to adhere to the ICANN Community Anti-Harassment Policy and Terms of Participation and Complaint Procedures. I acknowledge and accept that this Statement of Participation, including ICANN’s Expected Standards of Behavior, is enforceable and any individual serving in a Chair role (such as Chair, Co-Chair, or Acting Chair or Acting Co-Chair) of the [group] and GNSO Council Leadership Team have the authority to restrict my participation in the [group] in the event of non-compliance with any of the above.
Problem/Issue Escalation & Resolution Process:
Please reference Sections 3.4 and 3.5 of the Working Group Guidelines and the Guidance document below. Guidance: Guidelines Concerning ICANN Org Resources for Conflict Resolution and Mediation Instruction for Charter Drafting Team As the GNSO Council may modify the problem/issue escalation & resolution process at its discretion, please include additional resources and mechanisms, if any.
Formal Complaint Process:
Please reference Section 3.7 of the Working Group Guidelines and the Guidance document below. The Complaint Process may be modified by the GNSO Council at its discretion. Guidance: Clarification to Complaint Process in GNSO Working Group Guidelines
Section VI: Decision Making Methodologies
Consensus Designation Process:
Section 3.6 of the GNSO Working Group Guidelines, as included below, provides the standard consensus-based methodology for decision making in GNSO WGs. Section 3.6 notably refers to the ‘Chair’ (singular) of a WG, which does not conform to the reality of current PDP WG leadership structures. References to ‘Chair’ shall include PDP WG Co-Chairs and/or Vice Chair(s) that form the WG leadership, if applicable. WG leaders, members and liaison shall review the Capture vs. Consensus Playbook (Guidance document below) which provides a structured approach for consensus building and providing behavior insights, tools, and techniques to bridge differences, break deadlocks, and find common ground. Guidance: Consensus Playbook 3.6 Standard Methodology for Making Decisions The Chair will be responsible for designating each position as having one of the following designations: Full consensus - when no one in the group speaks against the recommendation in its last readings. This is also sometimes referred to as Unanimous Consensus. Consensus - a position where only a small minority disagrees, but most agree. [Note: For those that are unfamiliar with ICANN usage, you may associate the definition of ‘Consensus’ with other definitions and terms of art such as rough consensus or near consensus. It should be noted, however, that in the case of a GNSO PDP originated Working Group, all reports, especially Final Reports, must restrict themselves to the term ‘Consensus’ as this may have legal implications.] Strong support but significant opposition - a position where, while most of the group supports a recommendation, there are a significant number of those who do not support it. Divergence (also referred to as No Consensus) - a position where there isn't strong support for any particular position, but many different points of view. Sometimes this is due to irreconcilable differences of opinion and sometimes it is due to the fact that no one has a particularly strong or convincing viewpoint, but the members of the group agree that it is worth listing the issue in the report nonetheless. Minority View - refers to a proposal where a small number of people support the recommendation. This can happen in response to a Consensus, Strong support but significant opposition, and No Consensus; or, it can happen in cases where there is neither support nor opposition to a suggestion made by a small number of individuals. In cases of Consensus, Strong support but significant opposition, and No Consensus, an effort should be made to document that variance in viewpoint and to present any Minority View recommendations that may have been made. Documentation of Minority View recommendations normally depends on text offered by the proponent(s). In all cases of Divergence, the WG Chair should encourage the submission of minority viewpoint(s). The recommended method for discovering the consensus level designation on recommendations should work as follows: After the group has discussed an issue long enough for all issues to have been raised, understood and discussed, the Chair, or Co-Chairs, make an evaluation of the designation and publish it for the group to review. After the group has discussed the Chair's estimation of designation, the Chair, or Co-Chairs, should reevaluate and publish an updated evaluation. Steps (i) and (ii) should continue until the Chair/Co-Chairs make an evaluation that is accepted by the group. In rare case, a Chair may decide that the use of polls is reasonable. Some of the reasons for this might be: A decision needs to be made within a time frame that does not allow for the natural process of iteration and settling on a designation to occur. It becomes obvious after several iterations that it is impossible to arrive at a designation. This will happen most often when trying to discriminate between Consensus and Strong support but Significant Opposition or between Strong support but Significant Opposition and Divergence. Care should be taken in using polls that they do not become votes. A liability with the use of polls is that, in situations where there is Divergence or Strong Opposition, there are often disagreements about the meanings of the poll questions or of the poll results. Based upon the WG's needs, the Chair may direct that WG participants do not have to have their name explicitly associated with any Full Consensus or Consensus view/position. However, in all other cases and in those cases where a group member represents the minority viewpoint, their name must be explicitly linked, especially in those cases where polls where taken. Consensus calls should always involve the entire Working Group and, for this reason, should take place on the designated mailing list to ensure that all Working Group members have the opportunity to fully participate in the consensus process. It is the role of the Chair to designate which level of consensus is reached and announce this designation to the Working Group. Member(s) of the Working Group should be able to challenge the designation of the Chair as part of the Working Group discussion. However, if disagreement persists, members of the WG may use the process set forth below to challenge the designation. If several participants in a WG disagree with the designation given to a position by the Chair or any other consensus call, they may follow these steps sequentially: Send email to the Chair, copying the WG explaining why the decision is believed to be in error. If the Chair still disagrees with the complainants, the Chair will forward the appeal to the CO liaison(s). The Chair must explain his or her reasoning in the response to the complainants and in the submission to the liaison. If the liaison(s) supports the Chair's position, the liaison(s) will provide their response to the complainants. The liaison(s) must explain their reasoning in the response. If the CO liaison disagrees with the Chair, the liaison will forward the appeal to the CO. Should the complainants disagree with the liaison support of the Chair’s determination, the complainants may appeal to the Chair of the CO or their designated representative. If the CO agrees with the complainants’ position, the CO should recommend remedial action to the Chair. In the event of any appeal, the CO will attach a statement of the appeal to the WG and/or Board report. This statement should include all of the documentation from all steps in the appeals process and should include a statement from the CO. Instruction for Charter Drafting Team If the GNSO Council wishes to deviate from the standard methodology for making decisions or empower the WG to decide its own decision-making methodology, this section should be amended as appropriate.
Who Can Participate in Consensus Designation:
Instruction for Charter Drafting Team Please specify who from the WG membership can participate in the consensus designation process, including appropriate weight to the position held by such member(s), if applicable, and any factors that the WG leadership shall consider in assessing consensus. Guidance: A Comparison Table of Working Group Models Example: Charter of the EPDP Team on the Temporary Specification for gTLD Registration Data
Termination or Closure of Working Group:
Typically, the WG will close upon the delivery of the Final Report, unless assigned additional tasks or follow-up by the GNSO Council. The GNSO Council may terminate or suspend the WG prior to the publication of a Final Report for significant cause such as changing or lack of community volunteers, the planned outcome for the project can no longer be realized, or when it is clear that no consensus can be achieved. Guidance: Project Status and Condition Change Procedure
Section VII: Change History
Instruction for Charter Drafting Team Please document any significant changes to the WG charter in this section, including, but not limited to: Mission, purpose & deliverable Formation, staff & organizational
Section VIII: Charter Document History
Version Date Description 1.0
Staff Contact:	<Enter staff member name>	Email:	Policy-Staff@icann.org

Translations: If translations will be provided please indicate the languages below:

Any Working Group member may raise an issue for reconsideration; however, a formal appeal will require that that a single member demonstrates a sufficient amount of support before a formal appeal process can be invoked. In those cases where a single Working Group member is seeking reconsideration, the member will advise the Chair and/or liaison of their issue and the Chair and/or liaison will work with the dissenting member to investigate the issue and to determine if there is sufficient support for the reconsideration to initial a formal appeal process.

It should be noted that ICANN also has other conflict resolution mechanisms available that could be considered in case any of the parties are dissatisfied with the outcome of this process.