DRAFT Singapore Document
Based on CENTR Principles Document
1 March, 1999
Paris Participants - Comments
BMW participants - Comments
- The DNSO
- The Domain Name Supporting Organisation, ('DNSO') is an open consensus based expert policy advisory and recommending body within the Internet Corporation for Assigned Names and Numbers ('ICANN'). The DNSO is not an ICANN decision making body.
Concern about "expert"
- The objectives for DNSO are as defined in article VI of the ICANN bylaws; that is, to develop and recommend substantive policies and procedures regarding TLDs, including operation, assignment and management of the domain name system and other related subjects.
- Decisions on DNSO Recommendations are made by ICANN.
- The DNSO has the internal decision making powers necessary to manage its consensus-based processes.
- Legal Status
- The DNSO is NOT a separate legal entity - it is a part of ICANN.
- DNSO Names Council members and "Officers" (undefined for the moment) in the DNSO are protected / indemnified by ICANN.
The DNSO has no role in funding ICANN.
The only costs attributable to the DNSO are those pertaining to a DNSO secretariat.
Operations rather than secretariat
The DNSO Secretariat is funded
- either by ICANN
- or by contributions (to ICANN for the DNSO) from the DNSO Constituencies.
A General Assembly - an open forum for individual expert participation and work - open to all who are willing to contribute effort to the work of the DNSO
Should they be ICANN members ?
Real work to take place in working groups rather than the full GA
A Names Council - the Steering Committee for the DNSO comprised of individuals appointed by the DNSO Constituencies - responsible for managing consensus and making recommendations to ICANN
DNSO Constituencies - a number of groupings of organisations and/or individuals with interest in and expertise in DNSO matters (e.g. Domain Name Registries, Businesses, etc. - see below) who will have the right to nominate members to the Names Council
Need to consult
Vote rather than "nominate"
Representatives rather than "members"
DNSO Appointed ICANN Board Members - three individuals selected by the DNSO Names Council to sit on the ICANN Board.
Paris draft has membership electing ICANN Board
No two from the same Constituency
The General Assembly is an open, consensus based, assembly which is process oriented rather than member oriented.
A Polling process might be useful/necessary to determine a sense of the GA
The participants in the General Assembly are individuals who have a knowledge of and an interest in issues pertaining to achievement of DNSO objectives, who are willing to contribute time, effort and expertise in DNSO work items, including work item proposal and development, discussion of work items, draft document preparation, participation in working groups and steering committees, etc.
Careful not to slow down
Amadeu: Cannot support the idea of work being done by large group of people
The proposed General Assembly will hold formal meetings at regular intervals, and will conduct its work between these meetings by means of electronic communications.
Meetings to be held in conjunction with other important meeting to get better attendance
The General Assembly will require processes for a variety of activities including:
- convening and conducting meetings,
- proposing and recognising new DNSO work items / work areas,
- progressing work,
- developing consensus
- reporting its proceedings.
General Assembly conference costs shall be covered by an equitable charge on attendees. Conferences and meetings shall be held online whenever possible.
There shall be no General Assembly membership fees.
May need to invite experts
Costs may be paid by the DNSO
The Chair of the Names Council shall chair the General Assembly.
Perhaps the Names Council should appoint the Chair
DNSO Constituencies will be self-defining and may adopt their own structures, as long as they comply with ICANN bylaws and the criteria established by the DNSO.
There shall be Names Council processes for recognising additional Constituencies which shall require approval by ICANN.
Process require approval
Criteria required as well
Constituencies must apply for recognition to ICANN.
Note Paris draft criteria for Constituencies
ICANN Board rather than ICANN
Constituencies decide on their own representatives for the Names Council, using a process in accordance with the ICANN bylaws. Each Constituency shall have a number of Names Council members, no two of whom may come from the same region (where regions are as defined in the ICANN by-laws).
Or the same organisation (e.g. international organisations)
Using a process of their own devising
N.B. The same number of Names Council members for each Constituency
Query is geographical diversity a requirement of a Constituency ?
Perhaps include a process to ensure geographical diversity ?
MORE WORK NEEDS TO BE DONE
Individuals in multiple Constituencies ?
Each constituency shall source its own sponsorship/funding (if required).
Amadeu: Get rid of sponsorship ?
Hall: Bad idea to require each constituency to raise funding
Howard: For constituency activities
Perhaps Shall should be May
There are a number of Initial Constituencies:
There are a number of other possible Constituencies:
- The gTLD Registries
Amadeu: Constituency for 1 company ?
Hall: What about .int ?
If only one company only one member of Names Council
- The ccTLD Registries
Some objections to separate Constituency for ccTLDs
Perhaps a separate Constituency later ?
- Commercial and Business Interests
- Trade Mark and Intellectual Property Interests
- ISP and Communication Provider Interests
- The Registrars (when defined)
- Public and Academic Information Providers
- The national Domain Name Policy Organisations
- Individual Domain Name Holders
Kovack: Leave out the options
Fenello: Must have Individual Domain Name Holders
Hall: Any objection to adding individual Domain Name Holders as initial Constituencies ?
Some people think we must have a firm starting point some that we should have a list of possible Constituencies.
The Names Council
The Names Council is the Steering Committee for the DNSO, dedicated to facilitation, administration and management of consensus building for each of the DNSO processes.
Consensus based DNSO policy and standards proposals, developed by the General Assembly, shall be forwarded to ICANN as recommendations through the Names Council.
N.B. Working Groups
Names Council members are selected and appointed by the Constituencies.
The Names Council shall make any necessary decisions on internal DNSO processes in a manner that shall ensure consensus and fairness.
The Names Council shall be responsible for a variety of processes and activities, including:
- Managing the consensus processes in the General Assembly,
- Managing the consensus processes in the Constituencies,
- Acceptance of requests from within the DNSO and from ICANN for work areas,
- Making policy recommendations to the ICANN Board (either on its own initiative or in - response to issues referred for its attention by the ICANN Board),
- Convening and conducting meetings,
- Regulating the voting strength of the constituencies,
- Appointing a chair,
- Reporting its proceedings,
- Establishing new processes as required from time to time,
Recommendations see earlier paragraphs
Fenello: Objection to regulating voting strengths
Kovack: Facilitation rather than Management of processes
Constituencies e.g. the appointment
Constituencies - facilitation
- DNSO Appointed ICANN Board Members
- The General Assembly shall nominate individuals as candidates for election to the ICANN Board under procedures to be established by the Names Council and approved by the ICANN Board.
- Where there are more candidates proposed than there are vacancies for DNSO appointed Board Members, the Names Council shall vote using procedures to be established by the Names Council and approved by the ICANN Board.
Voting by the members of the Constituencies ? Probably a bad idea ?
Clarification as written anyone can be nominated.
DNSO Recommendations to ICANN
Shall be based on majority voting by the Names Council.
Fenello: Transmittal vote by super majority
Consensus Recommendations must be forwarded whether voted by Names Council or not.
Distinction between policy recommendations an internal processes requiring ICANN approval ?
Names Council voting shall ensure that recommendations that affect minority constituencies have the acquiescence of those minority constituency Names Council members.
Meaning is needed to take Names Council members objections into account minority reports ?
Recognising that some proposals for policy recommendations may have a potential for impact on the members of a constituency or constituencies that is significant from the standpoint of such proposals having the potential for an effect on:
i. existing contracts with the Corporation [i.e.ICANN]; or
ii. other existing contracts or business relationships; or
iii. compliance with applicable law, including, without limitation, anti-trust or competition laws;
the Names Council shall, upon request of (a) a majority of members of any such constituency or constituencies, or (b) a majority of the Names Council representatives of any such constituency or constituencies, request such members to prepare an implementation statement explaining the significance of the proposed recommendation. The implementation statement shall be identified as such and shall accompany any recommendation by the Names Council that is adopted and transmitted to the Corporation.
Context Any recommendation that does not have supermajority support
Comments in addition an ability for transmission of minority views should go to IACNN especially when a recommendation is supported by less than a supermajority vote.
Should not need a majority vote to file an implementation statement.
Comment would like to transmit the sense of the DNSO
Further, recognising that some proposals for policy recommendations may have a potential for impact on the country code (ISO 3166) top level domain registries (the "ccTLD registries"), the Names Council shall, upon the request of at least xx% of the ccTLD registries, refer the proposed policy recommendation to the Government Advisory Committee of ICANN ( GAC) and shall request the GAC to prepare an implementation statemenent regarding the impact of the proposed recommendation. The implementation statement shall be identified as such and shall accompany any recommendation by the Names Council that is adopted and transmitted to the Corporation.
Comments Operate under current RFCs
The formal Work of the DNSO shall be done in the DNSO General Assembly (this does not preclude preliminary work being done elsewhere of course (e.g. in Constituency assemblies).
N.B. Through working groups, etc.
Done by rather than done in e.g. on-line work.
Not formal policy formulation
Processes for bringing forward work items (or aggregates of work items into work areas) shall require minimal Names Council support to ensure that new (even radical) items can get on the work agenda of the DNSO.
With due reference to costs
Names Council members are not precluded from participating in the work of the DNSO.
GA not DNSO
As the DNSO provides a policy and advice service to ICANN, ICANN shall furnish an appeals process for entities who may wish to record dissatisfaction with aspects of DNSO. By bringing this Appeals Process above internal DNSO processes, openness and fairness is ensured for those entities who, may remain unconvinced regarding internal DNSO process impartiality.
What about internal appeals processes ?
Fair Hearing Panels ?
Minority Reports ?
Requirement for publication for period of time for public comment ?
Starting point for discussion within the DNSO will be that the current registries operate under the current RFCs ?
Scribe Singapore Meeting 2 March, 1999.