ICANN ICANN Email List Archives

[gnso-consensus-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-consensus-wg] Some Thoughts on the Bicameral Model

  • To: <gnso-consensus-wg@xxxxxxxxx>
  • Subject: [gnso-consensus-wg] Some Thoughts on the Bicameral Model
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Sun, 20 Jul 2008 15:46:33 -0400

Attached and copied below are some thoughts I want to share regarding
the bicameral model.  I am not presenting them as a holistic proposal so
much as I am trying to share some of my ideas that could be considered
together or separately.  I hope it at least helps us as we further delve
into this model.
 
Chuck
 
 
GNSO Structure - Thoughts on the Bicameral Model

 

Literal bicameral model vs. '1-house divided' model

*       I agree with others that what I am calling a 'literal bicameral'
model would add lots of complexity and maybe extend the times it takes
to do our work.  I believe it would require separate house meetings and
joint house meetings in addition to meetings by constituencies within
each house.  And each of those probably requires separate leadership and
coordination.
*       I prefer what someone I think called the '1-house divided' model
that I understand to mean the following: We still function as one
Council but votes on the Council are counted by houses.

 

'1-house divided model'

*       The GNSO consists of two houses: 1) contracted stakeholders; 2)
non-contracted stakeholders.

        *       The Contracted Stakeholders have two Stakeholder Groups
that each has equal votes excluding any voting NomCom reps: 1)
Registrars; 2) Registries.
        *       The Non-Contracted Stakeholders have two Stakeholder
Groups each having equal votes excluding any voting NomCom reps: 1)
Non-Commercial Users; 2) Commercial Users.

*       Each house determines for itself how many Council
representatives it will have with a general goal to keep the size of the
Council to a minimal size as recommended by the BGC WG.

        *       Avri proposed an example of a possible model in this
regard:

                *       Contracted Stakeholders:

                        *       4 Registrar Reps
                        *       4 Registry Reps
                        *       1 NomCom Rep

                                *       My suggestion would be that the
NomCom select someone who is not currently associated with a registrar
or registry but who has good understanding of registry and registrar
businesses.

                        *       Note that other variations of this could
work, e.g., 3-3-1.

                *       Non-Contracted Stakeholders:

                        *       8 Non-Commercial Reps
                        *       8 Commercial Reps
                        *       2 Nom-Com Reps

                                *       My suggestion would be that the
NomCom select one rep each from the Non-Commercial and Commercial
communities who are not currently associated with any Non-Contracted
Stakeholder Groups.

                        *       I personally think that 8-8-2 would
create two large of a Council so I would prefer smaller numbers but I
believe this should primarily be the decision of the Non-Contracted
Stakeholders House.

        *       An alternative to Avri's model would be to seat NomCom
reps at the Council level as we do now rather than at the house level; I
am not sure that is any different but I suppose it depends on how we
structure it.

*       It seems to me that it is difficult to discuss this model
without talking about voting thresholds because I believe the thresholds
will be critical to getting agreement to support the model.
*       Proposed voting thresholds:

        *       All policy work - 60% of both houses; this includes but
is not necessarily limited to consensus policies as defined in
registry/registrar agreements, best practice positions, and GNSO
responses to direction requested from the Board or other ICANN entities
(e.g., New gTLD policy, ICANN Travel policy, etc.).

                *       My basic assumption is that a simple majority
for any policy decisions of the Council is unacceptably low to call
consensus.
                *       At the same time, I don't think we want to
create grid-lock either.
                *       A 60% threshold would not allow any Stakeholder
Group in either House to veto anything and it would require support from
at least a portion of 3 of 4 Stakeholder Groups.

        *       All elections - simple majority of both houses.
        *       Initiating a PDP: Some level of support from each House
(e.g., simple majority, 1/3, etc.)
        *       Other votes: TBD (always requiring some level of support
for each House.

*       Council leadership

        *       Independent, non-voting chair

                *       I prefer the approach of the NomCom providing a
slate of possible chairs and the Council selects the chair from that
slate.
                *       The NomCom role in this regard could be combined
with identifying possible chairs for working groups.

                        *       This would mean that the slate could
serve more than one purpose.
                        *       Candidates not selected by the Council
for one leadership role could still be considered for other roles.

        *       Two vice chairs, one each elected by each of the two
Houses.
        *       The chair and vice chairs would serve together as the
leadership team working with ICANN staff in leading the GNSO activities.

*       Director Elections

        *       I still like the proposal that Jon put forward: "At the
end of the current term for Seat 14, Seats 13 and 14 both may not be
held by individuals who are employed by, an agent of, or receive any
compensation from an ICANN-accredited registry or registrar, nor may
they both be held by individuals who are members of or directly involved
in one of the GNSO user stakeholder groups."

                *       I believe this approach encourages selection of
candidates that are most beneficial to the GNSO as whole rather than
being too narrowly focused toward one of the Houses, while at the same
time it ensures that we will never have two directors at the same time
who are directly associated with one House.
                *       I think it also is less like a quota system.

*       PDP Revision

        *       I recognize that issues of revision of the PDP are
really separate from the work of this group but I sincerely believe that
it would be helpful at this stage to at least commit to support for the
following principles in the PDP:

                *       A clear determination regarding whether or not a
proposed policy area is within the registry contract picket fence should
be made prior to initiation of a PDP.  This would not preclude the
initiation of a PDP but would inform the Council decision process. 
                *       For all policy, process or procedure development
activity, the extent of outreach and the level of representativeness of
constituency and/or stakeholder positions should be documented. 
                *       Procedures for developing policy should ensure
that policies, processes and procedures are consistent with and pertain
to ICANN's core value of preserving and enhancing the operational
stability, reliability, security, and global interoperability of the DNS
and respecting the creativity, innovation, and flow of information made
possible by the Internet by limiting ICANN's activities to those matters
within ICANN's mission requiring or significantly benefiting from global
coordination.

 

Attachment: GNSO Structure - Thoughts on the Bicameral Model - 20 July 08.doc
Description: GNSO Structure - Thoughts on the Bicameral Model - 20 July 08.doc



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy