Constituency & Stakeholder Group Ops Work Team Task 1 Subtask 3

1. Recommendations for database architecture and alternatives.

Members (Krista Papac--RrSG and Tony Harris--ISPCPC) of the OSC CSG WT subtask 3 group discussed the idea of creating and maintaining a database of all stakeholder group and constituency members and others not formally a part of any stakeholder group and constituency that is up-to-date and publicly accessible with those constituencies in existence at the time of our conversation: ISPCPC (Tony Holmes), CBUC (Philip Shephard), IPC (J.Scott Evans and Kristina Rosette), RySG (Chuck Gomes), RrSG (Mason Cole) and NCSG (Robin Gross).All those we spoke with felt the database was a good idea and would be useful in the ICANN community. The major concern expressed was with maintaining an adequate amount of privacy for members. The ICANN community spans the globe and privacy laws and concerns vary considerably. Therefore the database must allow members to control the amount of private data they provide and that can be viewed by others.
Also, while it is important to protect community member privacy there must also be mechanisms in place to validate members are real people or companies.
We did not develop alternative recommendations to a database because those we spoke with were supportive of the concept as long as privacy concerns are addressed. Note: referring to an entire contact management system as a “database” is somewhat confusing and misleading. Henceforth “database” in this document will be replaced with either “system”, or “contact management system”.
General guidelines we suggest for the architecture are:
§ This system must allow users a reasonable level of privacy they desire tand/or that is required by their local governments.
§ The data scheme/relationship should segment database in a hierarchical fashion with segmentation based on various Communities, Stakeholder Groups (SG) and Constituencies. This should also include Working Groups, drafting teams and other groups that may be used in the GNSO policy development process herein after referred to as “GNSO Groups”.
§ Access to the system could be a link that takes you to a landing page which looks similar to the diagram included in this document as Figure 1. As users click on the various boxes they will be taken to the associated member list.
§ Each category of GNSO Group will be represented by a link on the main portal contact page. When a link is clicked the user will be taken to another landing page where the various options for that GNSO Group are represented. Depending on the number of layers associated with a given GNSO Group there will be additional landing pages one is directed to, eventually reaching a page containing all member participants for that GNSO Group.
§ A systems operator (OPERATOR) and maintenance resource, as well as abackup should be provided by ICANN and will be responsible for adding and/or deleting members from the various GNSO Group members list. The OPERATOR will be responsible for validating, to the best of his/her ability, the existence of GNSO Group members.
§ Individuals and organizations who wish to be a member of a GNSO Group can notify the OPERATOR of their member status for a given GNSO Group. The OPERATOR will then verify the member’s membership. Once member’s membership is confirmed, the OPERATOR will send a notification to member providing access to the member database (similar to what we see today on websites such as LinkedIn or Facebook).
§ Once notified by the OPERATOR, members can enter their contact details. Contact details will vary based on the type of member (individual or entity), and member type should be one of the details noted in the database. Examples of contact details are: member type (individual or organization), company name, family name, given name, address, telephone, fax, email, etc.
§ To respect member privacy, the system will allow members to select what information is visible to the public. There should be a minimum amount of information available such as member name, whether they are a voting member, and how they are affiliated with the respective Community, SG or Constituency, except in those cases where doing so creates a hardship or dangerous circumstances for the member (to be determined by the privacy policy).
§ The system should also indicate member’s status in the GNSO Group they are a part of including: whether they hold an Executive, Council, Board, NomCom position and if so what it is; whether they are an active or inactive member, a voting member, an interested party; and what working groups--if any--they are participating in.
§ The system must also provide features for members to self-select communications and alerts they wish to receive and the frequency.
§ The system should be as scalable as possible, so future functionalities can be added. For example: ability to upload a profile picture, chat, etc.
§ The system’s architecture/design should tie back to other OSC initiatives related to communications.
These suggestions were discussed with Ken Bour, ICANN Policy Staff, in Sydney. Ken felt all of the suggestions were implementable. It is recommended that ICANN IT staff take these basic suggestions for the database and create an outline for the community to comment on.

2. Recommendations for current methods to store and update membership records.

Membership systems of GNSO Groups must ensure appropriate privacy measures for those individuals and organizations that are members.
Membership records should be updated by the members themselves, and as stated in 1. above – membership in a particular GNSO Group would be granted by the OPERATOR. The OPERATOR should also have the ability to set a member to inactive. Updates to those holding an executive position in an ICANN community should be made by the OPERATOR.

3. Recommendations to create a “GNSO-discussion list” where participants from constituencies, working groups, and other GNSO processes have posting rights and emails are publicly posted.

The system should include a discussion list, however a generic “GNSO-discussion list” is not recommended as it has been tried in the past and was abused to the extent that most members of the ICANN community discontinued their use of it.
We recommend a discussion list format similar to the one we have today, where discussion lists have permissioning at the various Community, SG and Constituency levels with rights only extended by invitation from the OPERATOR.
Further it is recommended that ICANN will provide the infrastructure and documented requirements should be provided by an IT specialist that will organize it.

4. Coordinate with OSC Communications Work Team efforts to improve communications between ICANN structures via ICANN websites and other methods.

We had initial idea-sharing discussions with the Chair, Mason Cole, of the OSC Communications Work Team regarding our recommendations. His feedback was the suggestions sounded plausible.
Once our recommendations were drafted we asked the Chair, Mason Cole, of the OSC Communications Work Team to review our recommendations. His feedback was:
These suggestions are sensible and look to be easily implemented. The CCT’s effort toward improved GNSO communications is meant to ensure interested parties can easily understand how ICANN’s work impacts them and can learn about relevant information and procedures more quickly than is possible now. The idea of a constituency database is good---it will allow those in the community to find parties relevant to their own work.
The CCT looks forward to working more with this group to improve GNSO communications. Thanks for including our feedback.__