[Internal-cg] Consensus building process
Alissa Cooper
alissa at cooperw.in
Fri Aug 15 00:05:03 UTC 2014
I think I have the opposite opinion on this. I think letting any group
continue to object still allows the hold-out problem to cause us to result
in deadlock. I think it would be preferable to set a deadline at which the
final recommendation level designation will be made, and at that point if
there are minority opinions, from a group or from an individual, those
should be documented and published along with the main document. I don’t
think any other option safeguards us from deadlock, whether it be
inflicted by a group or an individual. And in particular for the case of
sending a transition plan to NTIA, I don’t think deadlock is an option.
Moreover, I don’t see how the “recommended method for discovering the
recommendation level designation,” as outlined in Wolf-Ulrich’s draft,
necessarily terminates. Step (iii) seems to allow individuals to make the
process go in a circle repeatedly by objecting to the recommendation
designation. Step (iv) discusses the use of polls, but does not specify
how they should be used to arrive at a final outcome.
Also, the document does not specify how consensus should be determined
within our different modalities of communication — email, conference call,
in person. Can we set comment periods with deadlines and, with no
objections raised, make a recommendation designation via this mailing
list? Can we do the same on a voice call — ask for objections and, hearing
none, proceed? Can we hum when we’re in person? ;) Do we need to confirm
hums on the mailing list (this is what we do in the IETF)? From an
operational perspective, I was hoping this document would provide answers
to these questions.
I think it would also be helpful for the document to describe what is
meant by “non-substantive” issues. From my perspective, I have no problem
with us moving fairly quickly to a vote on personnel matters — chairs, who
we choose for the secretariat, who will speak to the press, etc. — and
deciding by simple majority. For documents we have to agree to publish or
send (including the transition plan), I think we need a method that we
know will terminate for agreeing on a recommendation level designation,
and that allows for dissenting opinions to be simultaneously published.
Those are the only two categories that I think we need.
Finally, I think the most we can require as far as participation levels
(quorum for decision-making) is simple majority. This is a volunteer
activity, people will be busy at various times, and there may be some
decisions where certain ICG participants have reasons for not engaging in
the discussion. We shouldn’t set a standard for participation that we
might not be able to meet.
Alissa
On 8/14/14, 12:19 PM, "joseph alhadeff" <joseph.alhadeff at oracle.com> wrote:
>
>
>
>
>
> Milton:
>
> I agree with the first bullet points, but have reservations on the
> last. I agree that no customer stakeholder objection related to the
> proposal can exist and still have a consensus, but I also think that
> we cannot have a consensus if a number of the non-customer
> stakeholders object.
>
> Best-
>
> Joe
> On 8/14/2014 2:49 PM, Milton L Mueller
> wrote:
>
>
>
>
>
>
>
> Keith
> On
> the “holdout” problem, I think Martin’s principles
> addressed your concerns. To reproduce them here:
>
>
>
> ·
> The aim of the discussion should be to try to
> find a solution where *no member of the ICG still
> maintains serious opposition to the outcome.* Reasons
> for objections should be given, allowing the ICG wherever
> possible to try to address those concerns.
>
> ·
> *Recourse to any form of voting should be
> the exception.* Its use might be fine for
> non-substantive issues. For substantive issues, at least
> none of the “customer groups” (numbers, protocols, gTLDs or
> ccTLDs) of the IANA remains strongly opposed.
>
> ·
> Group members who still have problems with the
> evaluation should be invited to *identify possible ways
> in which the proposal could be modified to make it
> acceptable to them.*
>
> ·
> Discussions should continue until *no “IANA
> customer” group is firmly opposed.*
>
>
> Note
> these two things:
>
>
> 1)
> If
> there really is no consensus (and that DOES mean no one
> objects, even if they don’t fully agree) then we are
> reverting to a kind of supermajority voting or decision rule
> as outlined in the GNSO rules. Purists like me refuse to
> call this “consensus.” It doesn’t mean that we are “stuck”
> or blocked, it just means that we really don’t have
> something that conforms to the classical meaning of
> consensus. I think we should not play verbal games and call
> this “consensus.”
> 2)
> IANA
> customer groups (groups, not individuals) have a kind of
> special status in Martin’s principles, given their direct
> stake in how IANA is managed. Even though I am not
> representing a customer group, I think this is fair. If
> everyone in a particular customer group cannot live with a
> decision, it is certainly not consensus and we probably
> shouldn’t force such a decision on them, no matter how much
> everyone else supports it. We might extend the same kind of
> protection to other groups; e.g., if none of the user
> representatives (NCSG and ALAC) agree, it would seem
> unreasonable to claim that an outcome has even “rough”
> consensus. But if one particular individual within that user
> group can’t be swayed, then it should not be considered the
> same kind of obstacle to an outcome.
>
>
> Hope
> this is clear
>
>
> Milton
> L Mueller
> Laura
> J and L. Douglas Meredith Professor
>
> Syracuse
> University School of Information Studies
> http://faculty.ischool.syr.edu/mueller/
>
>
>
>
>
>
>
> From:
> internal-cg-bounces at icann.org
> [mailto:internal-cg-bounces at icann.org]
> On Behalf Of Drazek, Keith
> Sent: Thursday, August 14, 2014 2:10 PM
> To: Coordination Group
> Subject: Re: [Internal-cg] Consensus building
> process
>
>
>
> Just
> so I’m clear…
>
> Looking
> ahead….if we end up with 29 ICG reps in favor of a final
> recommendation and one person who unreasonably refuses to
> compromise, will that be deemed “consensus” or “no
> consensus?”
>
> Hypothetically
> speaking, if one holdout among us can obstruct a decision
> that has received support from all other members, and
> would prevent delivery of a recommendation….I find that
> very troubling.
>
> Keith
>
>
>
>
>
> From:
> internal-cg-bounces at icann.org
> [mailto:internal-cg-bounces at icann.org]
> On Behalf Of WUKnoben
> Sent: Thursday, August 14, 2014 1:47 PM
> To: Kavouss Arasteh
> Cc: Coordination Group
> Subject: Re: [Internal-cg] Consensus building
> process
>
>
>
>
>
>
> Dear
> Kavouss,
>
>
>
>
>
> you
> make the same point I expressed by saying that “I’m
> still uncertain with “non-substantive” issues which
> level of substance may depend on different views”. I
> would welcome you providing other more useful
> criteria to decide in which rare cases a “poll” or
> “voting” could apply.
>
>
>
>
>
> As
> you may have seen in my latest draft I removed the
> “adjectives” from consensus. So I would appreciate
> your written suggestion for an acceptable text that
> I could better understand your disagreement with the
> present proposal.
>
> Best regards
>
> Wolf-Ulrich
>
>
>
>
>
>
>
>
> From:
> Kavouss
> Arasteh <mailto:kavouss.arasteh at gmail.com>
>
>
>
> Sent:
> Thursday, August 14, 2014 7:22 PM
>
>
> To:
>
> WUKnoben
><mailto:wolf-ulrich.knoben at t-online.de>
>
>
> Cc:
> Milton L Mueller <mailto:mueller at syr.edu>
> ;
> Martin Boyle
><mailto:Martin.Boyle at nominet.org.uk> ;
> Coordination Group
><mailto:internal-cg at icann.org>
>
>
> Subject:
> Re: [Internal-cg] Consensus building process
>
>
>
>
>
>
>
>
>
>
> Dear
> All,
>
>
> I
> am not comfortable to any of these measures.
>
>
> The
> more we discuss and analyze ,the more problem is
> created.
>
>
> I
> strongly disagree to make any discrimination
> among the contstituent groups in ICG ,WHEN IT IS
> PROPOSED qUOTE
>
>
> "For substantive issues, at least
> none of the “customer groups” (numbers,
> protocols, gTLDs or ccTLDs) of the IANA remains
> strongly opposed"
>
>
> What is considered by someone "
> substantive" may be considered by others " non
> substantive,
>
>
> NO ADJECTIVE FOR OPPOSITION .NO
> ADJECTIVE FOR SCONSENSUS.
>
>
> If you want instead of making
> progress to draft another chatter or convention
> for decision making ,I disagree with that .
>
>
> It ios incumbent to the chair and
> the two vice chairs to make utmost efforts to
> build consensus-
>
>
> Pls end this discussion
>
>
> Regards
>
>
> Kavouss
>
>
>
>
>
>
>
>
>
>
>
>
> 2014-08-14
> 18:32 GMT+02:00 WUKnoben
><wolf-ulrich.knoben at t-online.de>:
>
>
>
>
> Thanks
> all for your valuable input.
>
>
>
>
>
> Milton
> is right calling for verbal clarity. But
> differentation is also needed and there
> are different approaches to achieve it.
> And as I said before the suggestion so
> far was based on GNSO habit.
>
>
>
>
>
> I
> tried to accomodate the discussion and
> therefore suggest to differentiate
> between “recommendation by consensus”
> (highest level, 100%) and
> “recommendation” (all remaining
> discussion results leading to a
> recommendation).
>
>
>
>
>
> I
> agree to all basic principles Martin
> came up with and incorporated them.
>
>
> I’m
> still uncertain with “non-substantive”
> issues which level of substance may
> depend on different views.
>
>
>
>
>
> I
> would appreciate further fruitful
> discussion on the list and we will
> hopefully see an end at our call next
> week.
>
>
>
>
>
> See
> my edits attached.
>
> Best regards
>
> Wolf-Ulrich
>
>
>
>
>
>
>
>
> From:
> Milton L
> Mueller <mailto:mueller at syr.edu>
>
>
>
> Sent:
> Tuesday, August 12, 2014 8:12 PM
>
>
> To:
>
> 'Martin Boyle'
><mailto:Martin.Boyle at nominet.org.uk> ;
> Coordination Group
><mailto:internal-cg at icann.org>
>
>
>
>
> Subject:
> Re: [Internal-cg] Consensus
> building process
>
>
>
>
>
>
>
>
>
>
>
>
>
> I
> think Martin makes very good
> points here.
>
> I
> like his proposed principles,
> every one of them.
>
>
> I
> must confess that I have been
> wincing at the way the word
> “consensus” is (ab)used routinely
> in these circles. Either it is
> truly consensus, and everyone
> either agrees or agrees not to
> object, or it is _something else_.
> Will we please stop trying to
> apply the term “consensus” to
> supermajority voting processes? My
> academic commitment to verbal
> clarity and directness is
> screaming at me that this is
> wrong.
>
> The
> IETF concept of “rough” consensus
> is an informal mechanism that is
> suitable for a more homogeneous
> environment in which adherence to
> standards is voluntary anyway, but
> in an environment with binding
> outcomes and political factions,
> it can and, in the ICANN context,
> frequently HAS merely provided a
> rationalization for ignoring
> significant minority points of
> view.
> --MM
>
>
>
>
> From:
> internal-cg-bounces at icann.org
>
>[mailto:internal-cg-bounces at icann.org]
> On Behalf Of Martin
> Boyle
> Sent: Tuesday, August
> 12, 2014 1:24 PM
> To: Coordination
> Group
> Subject: Re:
> [Internal-cg] Consensus
> building process
>
>
>
> Hi All,
>
> First thanks to
> Wolf-Ulrich for his paper. I
> greatly like the idea of
> standards of good behaviour and
> mutual respect – and I’m pleased
> to see that this is already very
> much the framework for the way
> that the ICG works. I’d also
> note that the analysis of shades
> of grey in levels of support is
> interesting – was it Patrik who
> first noted the two extremes
> (non-substantial and substantial
> issues) and the level of
> consensus that might be needed?
> I’m just not sure I know how to
> use them…
>
> I’d firmly endorse
> the aim that “the ICG … reach at
> least Consensus on the Proposal
> for the IANA Stewardship
> Transition to be forwarded to
> the NTIA” subject to our
> continued effort to try to
> achieve full/unanimous consensus
> or (at least) to have addressed
> address points of concern.
>
> However, I do not
> like processes that are supposed
> to be by consensus being
> resolved by voting (cf WCIT):
> voting leaves winners and
> losers. It also means that
> people get lazy and fail to look
> for compromise or common ground
> or ways to address “reasonable”
> concerns. That aversion is not
> really addressed by
> supermajorities: even at an 80%
> supermajority, all the domain
> name registries or all the
> government representatives or
> all GNSO members could be
> overruled. At 85% all the ccTLD
> registries, at 90% all the gTLD
> registries could be ignored.
>
> I do recognise the
> need for a mechanism that allows
> us to come to a final
> recommendation and I’m afraid
> that I do not see any magic
> wand. But I would suggest a
> number of basic principles:
>
> ·
> The aim of the
> discussion should be to try to
> find a solution where *no
> member of the ICG still
> maintains serious opposition
> to the outcome.* Reasons
> for objections should be given,
> allowing the ICG wherever
> possible to try to address those
> concerns.
> ·
> *Recourse to any
> form of voting should be the
> exception.* Its use might
> be fine for non-substantive
> issues. For substantive issues,
> at least none of the “customer
> groups” (numbers, protocols,
> gTLDs or ccTLDs) of the IANA
> remains strongly opposed.
> ·
> Group members who
> still have problems with the
> evaluation should be invited to
> *identify possible ways in
> which the proposal could be
> modified to make it acceptable
> to them.*
> ·
> Discussions should
> continue until *no “IANA
> customer” group is firmly
> opposed.*
>
>
> One final point: I
> would be willing to allow anyone
> who feels that they have not
> been heard to put a minority
> view into the final report. I’d
> rather that did not happen, but
> if the views are strong enough,
> it would be best to have then
> documented in the report than to
> be first aired in the discussion
> that follows the publication of
> our final report.
>
> Cheers
>
> Martin
>
>
>
>
> From:
> internal-cg-bounces at icann.org
>
>[mailto:internal-cg-bounces at icann.org]
> On Behalf Of Kavouss
> Arasteh
> Sent: 11 August 2014
> 20:48
> To: Drazek, Keith
> Cc: Coordination Group
> Subject: Re:
> [Internal-cg] Consensus
> building process
>
>
>
>
> Dear All,
>
>
> Undoubtedly, it
> would be super majority
> either 2/3 or 4/5 .
>
>
> Kavouss
>
>
>
>
>
>
> 2014-08-11
> 18:18 GMT+02:00 Drazek,
> Keith <kdrazek at verisign.com>:
> I agree that we
> will need a clear process
> for determining consensus
> that falls somewhere on the
> spectrum between humming and
> requiring a unanimous vote.
>
> If we get in to discussions
> of voting, we'll also need
> to address the thresholds
> required to establish
> consensus. Is it a simple
> majority? Super-majority?
> Unanimous voting is an
> unhelpful requirement that
> would likely obstruct our
> work and our ability to
> deliver, so I believe that
> should be a non-starter for
> the ICG. We need to avoid
> the possibility of one
> dissenting vote undermining
> an otherwise strongly
> supported recommendation
> that represents broad
> community consensus.
>
> However, if/when there is
> not full consensus, it will
> be important that we have a
> mechanism for expressing
> dissenting opinions. The
> GNSO Registries Stakeholder
> Group employs a "minority
> statement" mechanism to
> allow for all views to be
> expressed when there is
> consensus but not unanimity
> on a particular topic.
> Perhaps we should consider a
> similar mechanism for the
> ICG.
>
> Keith
>
>
>
> -----Original
> Message-----
> From:
>internal-cg-bounces at icann.org
>
>[mailto:internal-cg-bounces at icann.org]
> On Behalf Of Subrenat,
> Jean-Jacques
> Sent: Monday, August 11,
> 2014 6:09 AM
> To: Kavouss Arasteh
> Cc: Coordination Group
> Subject: Re:
> [Internal-cg] Consensus
> building process
>
> Hello Colleagues,
>
> From the experience of
> the past few weeks,
> unfortunately we can
> conclude that the
> current process is not
> successful. Rather than
> meting out blame or
> praise, we need to
> understand why it's not
> working. Group dynamics
> and a bit of sociology
> can help.
>
> Our Coordination Group
> is different from what
> some of us/you have come
> to consider as "normal".
> The technical bodies
> (IETF, IAB) have
> developed an efficient
> process where "rough
> consensus" is understood
> and accepted. But other
> components of the ICG
> have different habits,
> and also a different
> accountability
> mechanism: however
> attractive "rough" may
> be, it is insufficient.
> For example, the GAC has
> its own rules (a joint
> position can only be
> reached by unanimity),
> and the ALAC routinely
> conducts all its votes
> on a full-membership
> basis (each member has
> to say ay, nay, abstain,
> or be noted down as not
> having cast a vote).
>
> So the challenge is
> this: is the "rough
> consensus" really
> adapted to all the needs
> of our group? With the
> experience gained
> collectively in London,
> and especially since
> then, I would recommend
> a dual approach:
>
> A/ MATTERS REQUIRING ALL
> MEMBERS TO VOTE
> (typically, to be
> decided as soon as
> possible, with the
> exception of our
> Transition plan)
> - Chair structure and
> membership,
> - Charter of the ICG,
> - choice of
> Secretariat (ICANN or
> outside of ICANN, or a
> mixture of both),
> - choice of
> near-final drafts and
> approval of final draft
> of our Transition plan,
> before presentation to
> the NTIA.
>
> B/ MATTERS WHERE OTHER
> FORMS OF DECISION-MAKING
> ARE ACCEPTABLE
> - Appraisal of
> specific community
> input, as a contribution
> to the ICG's recommended
> plan (e.g. ALAC should
> appraise input from its
> own community before
> submitting it to the
> whole ICG),
> - external relations
> and communications of
> the ICG (once the Chair
> structure has been
> chosen and populated, it
> may wish to ask Chair,
> or another of its
> members, to be the point
> of contact),
> - administrative
> & logistic matters,
> in conjunction with the
> chosen Secretariat (here
> too, delegation would be
> possible).
>
> I'm prepared to provide
> a more detailed proposal
> for the above items.
>
> Best regards,
> Jean-Jacques.
>
>
>
> ----- Mail original
> -----
> De: "Kavouss Arasteh"
>
><kavouss.arasteh at gmail.com>
> À: "Patrik Fältström"
> <paf at frobbit.se>
> Cc: "Coordination Group"
> <internal-cg at icann.org>
> Envoyé: Lundi 11 Août
> 2014 10:40:08
> Objet: Re: [Internal-cg]
> Consensus building
> process
>
>
>
>
> Dear Wolf
> Thank you very much for
> reply
> My point is that if one
> or more ICG Mmember(s)
> is7are againszt the
> ruling of the Chir ,They
> could raise their issue
> and the matter must be
> settled by simple
> explanation or if not
> resolved by voting .
> I.E. CHAIR DOES NOT HAVE
> DECISION MAKING POWER ON
> HE OR HIS OWN WISHES
> RATHER TO TAKE INTO
> ACCOUNT VIEWS OF MEMBERS
> Regards KAVOUSS Regards
>
>
>
>
>
> 2014-08-11 8:33
> GMT+02:00 Patrik
> Fältström <
> paf at frobbit.se
><mailto:paf at frobbit.se>
> > :
>
>
>
>
> On 11 aug 2014, at
> 08:09, WUKnoben <
>wolf-ulrich.knoben at t-online.de <mailto:wolf-ulrich.knoben at t-online.de> >
>wrote:
>
> > The chair’s
> designation that
> consensus is reached is
> not her/his own decision
> rather than a wrap-up of
> extensive discussions.
> Of course this
> designation can be
> challenged by members.
> And this is what
> triggers your question
> about “If several
> participants in the ICG
> disagree with the
> designation given ...”.
> I’m open to any helpful
> suggestion on how we
> could procede in such a
> case.
> > In the end
> consensus - as defined –
> has to be achieved.
>
> Let me emphasize what
> you say here, which I
> strongly agree with.
>
> We must deliver.
>
> This implies we must be
> able to reach consensus.
>
> The last couple of weeks
> discussions on various
> topics makes me a bit
> pessimistic on the
> ability for us to reach
> consensus, but I am
> optimistic, always
> optimistic, on peoples
> ability and interest in
> actually deliver.
>
> Remember that the chair
> is calling on the
> consensus question, not
> the substance. That way
> the power of the chair
> is decreased to a
> minimum and process
> issues.
>
> Patrik
>
>
>
>_______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
>
>https://mm.icann.org/mailman/listinfo/internal-cg
>_______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
>
>https://mm.icann.org/mailman/listinfo/internal-cg
>_______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
>
>https://mm.icann.org/mailman/listinfo/internal-cg
>
>
>
>
>
>
>
>
>
>
> ________________________________________
>
>
>
>_______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
>
>https://mm.icann.org/mailman/listinfo/internal-cg
>
>
>
>
>
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>Internal-cg mailing list
>Internal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg
>
>
>
>
>
>_______________________________________________
>Internal-cg mailing list
>Internal-cg at icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg
More information about the Internal-cg
mailing list