[Internal-cg] Consensus building process
WUKnoben
wolf-ulrich.knoben at t-online.de
Fri Aug 15 06:03:46 UTC 2014
Thanks Alissa,
I understand your concerns
- avoid deadlocks
- be clear in where and when a discussion should end with a recommendation
- detail the communication modalities
- make the distinction between substantive/non-substantive issues clear
It should be discussed on Tuesday next week since in parts it is related to
the chair's power in driving the process.
Re the communication modalities during the process I'd like to see it
practically. As we intend to hold conference calls at least every 2 weeks
decisions should be taken just there, and it should appear in advance under
the related agenda item. The designation process can run in between via
email etc.
A quorum (for "substantive issues") could be simple majority (secretariat to
evaluate!) including a simple majority attendance of the "customer groups".
Let me think about a little more and come up with suggestions. But it seems
the more we dive into the details the more complex the process shall evolve
since everybody tends to cover eventualities.
Best regards
Wolf-Ulrich
-----Ursprüngliche Nachricht-----
From: Alissa Cooper
Sent: Friday, August 15, 2014 2:05 AM
To: joseph alhadeff ; internal-cg at icann.org
Subject: Re: [Internal-cg] Consensus building process
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
_______________________________________________
Internal-cg mailing list
Internal-cg at icann.org
https://mm.icann.org/mailman/listinfo/internal-cg
More information about the Internal-cg
mailing list