GNSO WHOIS Survey Working Group (WSWG) Charter




WG Name:

WHOIS Survey Working Group (WSWG)

 

Section I: Working Group Identification

 

 

Chartering Organization(s):

 

GNSO Council

Charter Approval Date:

 

TBD

Name of WG Chair:

 

Michael Young

Name(s) of Appointed Liaison(s):

 

Wendy Seltzer

WG Workspace URL:

 

https://community.icann.org/display/WSWG/Home

WG Mailing List:

 

gnso-whoissurvey-WG@icann.org

Important Document Links:

 
  • GNSO WHOIS Service Requirement Final Report (PDF)
  • WHOIS Service Requirement – Possible Next Steps (Chuck Gomes) (LINK)

Section II: Mission, Purpose, and Deliverables

 

 

Mission & Scope:

 

 


The Working Group aims to draft, implement, and analyze the results of a survey measuring the level of support for various technical requirements outlined in the GNSO WHOIS service requirement report (http://gnso.icann.org/issues/whois/whois-service-requirements-final-report-29jul10-en.pdf).

 

 

Objectives & Goals:

 

 


To produce a Report to be delivered to the GNSO Council describing the results of the survey and recommendations for next steps for the GNSO Council's consideration concerning the WHOIS service requirements.

 

 

Deliverables & Timeframes:

 

 


The WSWG is expected to carry out the activities identified in this Charter in order to produce a Final Report to the GNSO Council by the October 2012 ICANN Meeting.

Projected Work and Project Elements:

Overall Milestones:

The WSWG is expected to carry out the activities identified in this Charter in order to produce a Final Report to the GNSO Council by the October 2012 ICANN Meeting. In order to meet this timeframe, the WSWG shall endeavor to meet the following milestones:

  • Draft survey and present to the GNSO Council for approval by 1 March 2012
  • Conduct survey for a period of not less than thirty (30) days by 30 May 2012
  • Publish Initial Report reporting survey results and recommended next steps for public comment by August 2012
  • Publish Final Report by October 2012


    Part A
    # Subgroup 1 – Drafting survey questions:


    There are two tasks included in Part A #1. The first is to write the actual survey questions in consideration of the existing requirements, the guidance provided by Chuck Gomes, of Verisign and member of the Registry Stakeholder Group, and further guidance from stakeholders who the WG will be reaching back out to. Note that in creating these questions, relevant question tally mechanisms in the survey should be included to allow respondents to prioritize the requirements.
    The second task is to create and implement a test plan for the draft questions to be sure they are phrased clearly and understandably for a broad and diverse audience. Before administration, the WG should have the final survey candidate reviewed by a qualified independent third party and tested for comprehensiveness, clarity, and general applicability to the subject matter. Part of the review should include guidance, by the independent party, in developing a mechanism to determine if questions were comprehended by recipients as intended when reviewing the survey results. If the results for a particular question fail that test, the WG should discount the results from that question. Additionally, the WG should request volunteers from the stakeholders for "beta" testers when developing the survey to ensure the greatest success at full survey recipient comprehension.
    This subgroup will define the process for selecting a qualified independent third party, including making a determination of the budget amount to request to cover the costs of this review, and how a reviewer should be selected.
    # Subgroup 2 – Survey Tool and Survey recipient selection


    This task is to identify and prepare the survey delivery tool/mechanism and determine the recipient list for the survey. Again the WG should consider the stakeholders named in the original GNSO resolution that resulted in the Whois Requirements Report, and new stakeholders identified by the WG. Lastly the WG should consider stakeholders outside the sphere of ICANN related communities and their possible participation in the survey process.
    # Subgroup 3 – Requirements verification


    This task is to check with stakeholders to see if they want to either add clarification and/or support to existing proposed requirements or suggest additional ones. The WG will touch base with the stakeholders that were already consulted in creating the Whois requirements report and also consider other interested stakeholders. For example, should the stakeholders include IETF representatives?
    Milestone and Project Timeline Development for Part A:
    The WG is in support of operating a sub-group for each of the tasks in Part A. Each sub-group will be led by a WG co-Chair. Each team's first meeting should be to derive scope of work, task assignment, and project timelines for their area. The Chair will volunteer to write a consolidated project plan for Part A based on the individual group project plans. Consistent cross-communication is important and reflected in the proposed meeting process developed by the WG.
    Part B:
    The working group will participate together to complete the following deliverables:
    Administer the survey and gather results.
    Assess and process survey results:
    * Review tallies from survey results and prioritize requirements based on those tallies.
    * Gather and add comments from the WG on the initial survey results,
    * Identify and document recommendations from the teams in respect of survey findings.
  • Post for public comment and compile responses into the final report.
  • Compile next step recommendations into the final report that WG members bring forward.

    Milestone and Project Timeline Development for Part B:
    The first meeting for Part B work will be to assess with the team the amount of material resulting from the survey, and confirm or adjust milestones/dates for the Part B tasks listed.
    Meeting Schedule (Informational only – may change to support optimization):
    Part A
  • Sub-groups will meet every two weeks to proceed with work elements
  • Chairs will meet alternate weeks to update, communicate and feed cross-dependent results to one another's teams. Standard project management meeting as well, verify milestones and progress toward achieving those milestones.
  • Every third Chair Meeting will be a full WG meeting (every 6 weeks) so all members can be updated to the overall progress.


    Part B
  • Establish a standard meeting schedule to work through the review and recommendation processes every two weeks until all material to feed the final report is complete.
  • Schedule a break in meetings during the public comment period.

 

 

Section III: Formation, Staffing, and Organization

 

 

Membership Criteria:

 

 


The WSWG will be open to all interested in participating. New members who join after work has been completed will need to review previous documents and meeting transcripts.

 

 

Group Formation, Dependencies, & Dissolution:

 

 


This WG shall be a standard GNSO Working Group.

 

 

Working Group Roles, Functions, & Duties:

 

 


The ICANN Staff assigned to the WSWG will fully support the work of the committee as requested by the Chair including meeting support, document drafting, editing and distribution and other substantive contributions when deemed appropriate.

Staff assignments to the WSWG :

•GNSO Secretariat
•1 ICANN policy staff member- (Steve Sheng)

The standard WG roles, functions & duties shall be applicable as specified in Section 2.2 of the Working Group Guidelines.

 

 

Statements of Interest (SOI) Guidelines:

 

 


Each member of the WSWG is required to submit an SOI in accordance with Section 5 of the GNSO Operating Procedures.

 

 

Section IV: Rules of Engagement

 

 

Decision-Making Methodologies:

 

 

{Note: The following material was extracted from the Working Group Guidelines, Section 3.6. If a Chartering Organization 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}.

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 (info) and (ii) should continue until the Chair/Co-Chairs make an evaluation that is accepted by the group.
  1. 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 (see Note 1 below) 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:
  2. Send email to the Chair, copying the WG explaining why the decision is believed to be in error.
  3. 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.
  4. 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 (see Note 2 below).


    Note 1: 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.

    Note 2: 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.

 

 

Status Reporting:

 

 

As requested by the GNSO Council, taking into account the recommendation of the Council liaison to this group.

 

 

Problem/Issue Escalation & Resolution Processes:

 

 

{Note: the following material was extracted from Sections 3.4, 3.5, and 3.7 of the Working Group Guidelines and may be modified by the Chartering Organization at its discretion}

The WG will adhere to ICANN's Expected S http://www.icann.org/transparency/acct-trans-frameworks-principles-10jan08.pdf    tandards of Behavior as documented in Section F of the ICANN Accountability and Transparency Frameworks and Principles, January 2008.

If a WG member feels that these standards are being abused, the affected party should appeal first to the Chair and Liaison and, if unsatisfactorily resolved, to the Chair of the Chartering Organization or their designated representative. It is important to emphasize that expressed disagreement is not, by itself, grounds for abusive behavior. It should also be taken into account that as a result of cultural differences and language barriers, statements may appear disrespectful or inappropriate to some but are not necessarily intended as such. However, it is expected that WG members make every effort to respect the principles outlined in ICANN's Expected Standards of Behavior as referenced above.

The Chair, in consultation with the Chartering Organization liaison(s), is empowered to restrict the participation of someone who seriously disrupts the Working Group. Any such restriction will be reviewed by the Chartering Organization. Generally, the participant should first be warned privately, and then warned publicly before such a restriction is put into place. In extreme circumstances, this requirement may be bypassed.

Any WG member that believes that his/her contributions are being systematically ignored or discounted or wants to appeal a decision of the WG or CO should first discuss the circumstances with the WG Chair. In the event that the matter cannot be resolved satisfactorily, the WG member should request an opportunity to discuss the situation with the Chair of the Chartering Organization or their designated representative.

In addition, if any member of the WG is of the opinion that someone is not performing their role according to the criteria outlined in this Charter, the same appeals process may be invoked.

 

 

Closure & Working Group Self-Assessment:

 

 





 

 

Section V: Charter Document History

 

 

Version

Date

Description

1.0

19 July 2011

First Draft (Steve Sheng)

1.1

29 July 2011

2nd Draft (Michael Young)

1.2

11 August 2011

3rd Draft (Liz Gasster)

1.3

23 August 2011

4th Draft (Liz – incorporating Don's and Avri's comments)

1.4

24 August 2011

5th Draft (Liz – accepting previous edits and adding red line regarding the independent review of draft questions)

1.5

30 August 2011

6th draft (Liz – group renamed as a WG)

1.6

12 September 2011

Final for GNSO Council consideration (Liz)

 

 

 

 

Staff Contact:

Steve Sheng

steve.sheng@icann.org

 

 



Translations: If translations will be provided

please indicate the languages below:

 

 

 

 

 

 

 

 

 

 

 

n/a