Re: FW: [802SEC] The 802.20 election procedure for July
Matt,
In the ideal scenario, every company would only send
experts to a dot group and then I doubt we would see the
number of members per company being so large as to
alter results.
I would argue then that using single votes per company
or voting by individual would have the same result
the vast majority of the time.
As to it being by company voting all the time,
I would expect the elected chair of WG to monitor the
attendance at a particular meeting, monitor each vote
(by member) and determine if bias could occur and then
act accordingly. Unfortunately, based on the current
5.1.4.4.e this brings the SEC back into the fray and
a delay of at least the time to the next plenary.
Assuming we can alter the membership aging rules, I
believe the problem will fix itself. Or we can be a
little more radical and change 5.1.4.4.e.
mike
> From: Sherman,Matthew J (Matthew)
> Sent: Saturday, April 05, 2003 4:19 PM
> To: 'Mike Takefman'; stds-802-sec@cisco.com
> Subject: RE: [802SEC] The 802.20 election procedure for July
>
> Mike,
>
> First off, I'm not saying I would not support what you suggest. I'm
> fishing to see if there are any other ideas. The only thing that I am
> uncomfortable with is that really it is voting per company all the time,
> and never per an individual. If you check both ways and get the same
> answer, then you keep it. But when you check both ways and get
> different answers, the company way always wins. So really you are
> always voting per company since that way is the only way that is always
> right. Strictly speaking, I'm not sure this is what we want to do.
> Also, sometimes the problem is not individual companies, but rather
> industry organizations. There is no control in what you suggest for
> that.
>
> In my mind, what you propose should be used as a check. If there is a
> "problem", you evaluate the situation to see if you can work it out. If
> not, you bump it up to the LMSC and let them evaluate the situation.
> Possibly you decide the first voting process was fine (confirm) or
> possibly you decided there was a potential problem (don't confirm).
> Then you may take any of several approaches, including design of a more
> rigorous voting process. I lean toward modeling something after the
> sponsor ballot process which is very open as to the approach used.
> Maybe up to two votes per company. Maybe have participants state their
> involvement in other organizations. Anyway, I'm on a fence about
> exactly what to do. Nothing I see right now is perfect, which is why
> I'm trying to set back and see what people suggest. Then go with the
> best suggestion (even if it isn't perfect).
>
> By the way, what happens with your process if a single company has
> multiple votes on both sides?
>
> Mat
>
> Matthew Sherman
> Vice Chair, IEEE 802
> Technology Consultant
> Communications Technology Research
> AT&T Labs - Shannon Laboratory
> Room B255, Building 103
> 180 Park Avenue
> P.O. Box 971
> Florham Park, NJ 07932-0971
> Phone: +1 (973) 236-6925
> Fax: +1 (973) 360-5877
> EMAIL: mjsherman@att.com
>
> -----Original Message-----
> From: Mike Takefman [mailto:tak@cisco.com]
> Sent: Saturday, April 05, 2003 1:45 PM
> To: Sherman,Matthew J (Matthew); stds-802-sec@cisco.com
> Subject: Re: [802SEC] The 802.20 election procedure for July
>
> Matt,
>
> First let me state that I appreciate the research you've done
> on this and I agree with thrust of it.
>
> I would be interested to know what you don't like about
> my proposal. I put it out before the SEC because no one
> else seemed to be putting forth a possible procedure. I am
> more than willing to consider other proposals and modify
> mine.
>
> Fundamentally, if everyone played by the "rules" and sent
> a single expert, the makeup of the WG would be the same as
> what I proposed after the roll call analysis. Now you
> could argue that it is not reasonable to limit companies
> to a single expert (especially since someone who is expert
> at the PHY layer may not be expert at the MAC etc etc),
> but then you get into the quagmire of is 2, 3, 4, 5 ...
> voters excessive. Instead my proposal assumes that
> people act in good conscience, send an appropriate number of
> experts, but provides a consistency check to insure that
> nothing untoward has happened. Thus it allows the SEC to
> avoid trying to prescreen the make-up of the WG. Whereas
> I believe it is entirely reasonable for the SEC chair to
> screen the makeup of a sponsor ballot group.
>
> I would like to change/strengthen rule 5.1.4.4.e to allow the WG
> chair to address block voting without SEC approval (assuming
> that the chair has proof (like a roll call vote)) and
> instead allow the appeals process to overturn the chair.
>
> I realise that many SEC members will find this too radical
> as 5.1.4.4.e has been used as a threat, and the company in
> question backed off. I suppose I would be willing to wait
> for such a change to see if 5.1.4.4.e ever had to be used,
> and to see if the threat again worked or if it did not that
> the SEC allowed the chair to take action on 5.1.4.4.e.
>
> cheers,
>
> mike
>
> mjsherman@research.att.com wrote:
> >
> > Roger,
> >
> > At the end of this response to your e-mail, I have attached a
> collection
> > of what I feel the relevant rules are in SA and LMSC documents. I
> > invite others to find relevant blurbs I might have missed. I will
> > loosely refer to this collection of relevant snippets as the "block
> > voting" rules, even though the term "block" only occurs once in the
> > whole thing.
> >
> > The term "Block Voting" is in common use within 802, and has been for
> as
> > long as I've been around. I would loosely summarize Block voting as
> > instances where groups of organizationally related individuals vote
> > based on directives from an organization rather than based on their
> > personal professional opinions. I think we all would agree that this
> > would be inappropriate behavior for IEEE 802. It is something we want
> > to avoid and discourage. But as you point out, it can be very hard to
> > detect. The real question is what should we do to avoid this?
> >
> > In general we tend to model our WG voting rules after the sponsor
> ballot
> > rules. While sponsor ballots are pretty much open to any expert who
> > wants to participate (participation includes joining the SA), limits
> may
> > be placed on the number of experts from a specific category or firm
> who
> > can participate. Note that each expert from a category or firm might
> > have voted as an individual, and might have held opinions that were
> > quite different from other experts in that category or firm. But the
> SA
> > chooses not to risk the possibility of abuse which they might have to
> > detect after the fact. Rather they limit the potential for abuse by
> > design and state that participation by "blocks" of experts should have
> > limits. These limits are INDEPENDENT of INTENT! Nobody is asking will
> > the members of these blocks vote an individual or group opinion.
> Rather
> > the possibility of such a thing occurring is limited by design. And
> > while as a whole all the individual experts are welcome to
> participate,
> > it is clear that participation may be curtailed based on what firm
> they
> > work for or organization they belong to - regardless of intent.
> >
> > So I disagree with your suggestion that we are saying there is a
> "burden
> > of proof" on anyone that the rules have or have not been broken.
> Rather
> > there is a burden upon us (the leadership and participants of 802) to
> > set up voting processes such that abuse is discouraged by design. On
> > the sponsor level, there are certain key pieces of information that
> are
> > collected to help design a ballot process that discourages "block"
> > voting. Participants are required to provide information, such as
> their
> > firm, their name, and what interest group they represent in order to
> > participate. This is not to prove or disprove wrong doing. Rather it
> > is to facilitate the design of a process where block voting is
> unlikely
> > to occur.
> >
> > Ultimately, I think it falls to the chair of the WG (perhaps with help
> > for the WG and the EC) to develop processes that implement the intent
> of
> > the LMSC and SA rules. Both sets of rules are quite open on what
> > techniques can be used to achieve the desired goals. I find the
> process
> > Mike suggests to be within those rules, though I'm not sure I support
> it
> > exactly as is for 802.20. But as long as it is stated up front as the
> > process we will follow, I think it is a valid process.
> >
> > Mat
> >
> > "Block Voting" Rules in IEEE SA and LMSC:
> >
> > From the SA Standards Board Bylaws:
> >
> > 5.2.2.3 Sponsor balloting group
> >
> > Potential dominance in sponsor ballots as evidenced by an unduly high
> > proportion of individuals from a single firm and/or organization or
> from
> > a particular balloting classification is unacceptable, counter to open
> > and fair participation by all interested parties, and deprecated by
> the
> > IEEE-SA Standards Board. .............
> >
> > ......... An organization is an entity that represents broad-based
> > membership interest. This includes not only standards-development
> > organizations but also other types of organizations such as a
> government
> > agency (federal, state, provincial, or local), user group, or trade
> > association. It should be noted that individual firms are not
> considered
> > to be organizations.
> >
> > From the SA Standards Board Operations Manual
> >
> > 5.4.1 Balloting group
> >
> > The balloting group shall provide for the development of consensus by
> > all interests significantly affected by the scope of the standard.
> This
> > is achieved through a balance of such interests in the balloting group
> > membership. Balance is defined as the avoidance of dominance by any
> > single interest category. ..............
> >
> > ........ Sponsors are required to classify the relationship of each
> > member of the balloting group relative to the scope of standards
> > activity (for example, producer, user, and general interest). Where
> > appropriate, additional classifications, such as "testing laboratory"
> or
> > "academic," may be used. This decision should be based on the effect
> the
> > standard may have on participants not already recognized by the
> primary
> > classifications. ORs
> > are classified in relation to the interests of their organization.
> > Individuals are classified based on their technical background, which
> > may be related to their employment, job functions, or experience.
> > ..............
> >
> > .......... No group (classification) is permitted to constitute 50% or
> > more of the balloting group membership. Care shall be taken to ensure
> > that all classes of interest are represented to the extent possible.
> >
> > From the LMSC P&P
> >
> > 3.4.1 Voting Guidance
> > It is expected that LMSC Executive Committee members will vote as both
> > professionals and as individual experts, except under the Directed
> > Position provisions of Procedure 8, and not as a member of any
> affiliate
> > block (organization, alliance, company, consortium, special interest
> > group, etc.). If substantive evidence is presented to the LMSC Chair
> > that this provision is violated, the LMSC Executive Committee will
> meet
> > to consider what, if any, action to take on the presented evidence.
> Such
> > action may include any action up to and including a recommendation for
> > removal from office.
> >
> > 5.1.3.1 Establishment
> >
> > ..... Working Group members shall participate in the consensus process
> > in a manner consistent with their professional expert opinion as
> > individuals, and not as organizational representatives.
> >
> > 5.1.4.4 Working Group Chair's Authority
> >
> > ....... the Working Group Chair has the authority to: .........
> >
> > ....... Determine if the Working Group is dominated by an
> organization,
> > and, if so, treat that organizations' vote as one (with the approval
> of
> > the Executive Committee).
> >
> > Matthew Sherman
> > Vice Chair, IEEE 802
> > Technology Consultant
> > Communications Technology Research
> > AT&T Labs - Shannon Laboratory
> > Room B255, Building 103
> > 180 Park Avenue
> > P.O. Box 971
> > Florham Park, NJ 07932-0971
> > Phone: +1 (973) 236-6925
> > Fax: +1 (973) 360-5877
> > EMAIL: mjsherman@att.com
> >
> > -----Original Message-----
> > From: Roger B. Marks [mailto:r.b.marks@ieee.org]
> > Sent: Friday, April 04, 2003 1:23 AM
> > To: Sherman,Matthew J (Matthew)
> > Cc: stds-802-sec@ieee.org
> > Subject: RE: [802SEC] The 802.20 election procedure for July
> >
> > Mat,
> >
> > We don't have rules against block voting. What we have is a statement
> > that the "Working Group Chair has the authority to Determine if the
> > Working Group is dominated by an organization, and, if so, treat that
> > organizations' vote as one (with the approval of the Executive
> > Committee)."
> >
> > People from the same organization tend to vote alike. Is this a
> > shocking statement? Is this something we need to be embarrassed
> > about? I don't think so.
> >
> > There is no burden of proof on individuals to show that they are
> > voting with an independent mind, and there is no burden of proof on
> > organizations to prove that their members think independently. People
> > from the same organization are allowed to vote the same way. This is
> > not against the rules!
> >
> > A Working Group Chair will not find it easy to conclude that a group
> > is "dominated by an organization". And that's the way it should be.
> > This rule is, and should be, reserved for extraordinary cases. I
> > don't even know what kind of cases they are; I can imagine only a
> > few. Maybe a company gets over 25% of the membership and consistently
> > holds the Working Group over a barrel.
> >
> > And, as I have said before, I still believe that, if we want people
> > to act independently of their organization, we ought not to take roll
> > call votes. People won't cross the boss if there is a written record
> > of it.
> >
> > Roger
> >
> > >Roger,
> > >
> > >I agree as do we all - One member, one vote. The problem is when
> > >members vote as organizations. This is loosely termed in our rules
> as
> > >"block voting". How can this be evaluated without data to do so?
> This
> > >is not about counting votes as organizations. It is about collecting
> > >data so that we know the members are voting as individuals and not
> > >organizations. How do you propose we account for block voting if we
> > >don't know what organizations people represent?
> > >
> > >Mat
> > >
> > >Matthew Sherman
> > >Vice Chair, IEEE 802
> > >Technology Consultant
> > >Communications Technology Research
> > >AT&T Labs - Shannon Laboratory
> > >Room B255, Building 103
> > >180 Park Avenue
> > >P.O. Box 971
> > >Florham Park, NJ 07932-0971
> > >Phone: +1 (973) 236-6925
> > >Fax: +1 (973) 360-5877
> > >EMAIL: mjsherman@att.com
> > >
> > >
> > >-----Original Message-----
> > >From: Roger B. Marks [mailto:r.b.marks@ieee.org]
> > >Sent: Friday, April 04, 2003 12:35 AM
> > >To: stds-802-sec@ieee.org
> > >Subject: Re: [802SEC] The 802.20 election procedure for July
> > >
> > >
> > >I am strongly, stridently, opposed to voting by organization or
> > >asking people to declare allegiance.
> > >
> > >What next: we ask Working Group members to disclose their investment
> > >portfolios, and those of their brother-in-law? Maybe a blue-ribbon
> > >SEC commission (the one that is supposed to "analyze the results")
> > >can interview each working group member and decide what in which
> > >interest group pigeonhole they belong?
> > >
> > >One member, one vote. That's the way we do business in 802.
> > >
> > >Roger
> > >
> > >
> > >>Hi Everyone,
> > >>
> > >>This is an outshoot from my WG initial membership interpretation
> > >>effort. An issue I have heard raised a number of times from LMSC EC
> > >>members is the question of what procedure should be followed for
> > >>elections by 802.20 in July. Personally, I think it is
> > >>inappropriate for us to "force" them to use a specific procedure.
> > >>On the other hand, clearly people in 802.20 are wondering "what they
> > >>can change" that would improve the chances of their officers being
> > >>confirmed next time around. Based on reflector discussions to date,
> > >>the election procedure itself seems to have been a concern at least
> > >>to some EC members. Given that, I think it might make sense if we
> > >>"recommend" a procedure that might address the concerns of these EC
> > >>members. In my mind we could make a motion recommending a
> > >>particular procedure, and have this presented to 802.20 at the
> > >>upcoming interim. Mike Takefman has put forward the most detailed
> > >>election procedure I have seen suggested to date. Extracting from
> > >>one of Mike's recent e-mails that procedure would be:
> > >>
> > >>Everyone who attended 75% of the initial session gets to vote in
> > > >July. All consultants should declare who their client is. The
> > > >elections (and probably every other vote) should be by roll call.
> > > >The SEC should then analyze the results as both 1 organization 1
> > > >vote and straight and determine if any difference in result would
> > >>occur. If the vote is reverse on a 1 company 1 vote basis, then
> > >>that vote should be taken as final.
> > >>
> > >>Personally, I'm okay with everything but the last step. From
> > >>5.1.4.4 of the LMSC P&P I believe the WG Chair's job is to:
> > >>
> > >> "Determine if the Working Group is dominated by an
> > >>organization, and, if so, treat that organizations' vote as one
> > >>(with the approval of the Executive Committee)."
> > >>
> > >>I'm not sure if the last step in Mike's process is the best way to
> > >>do that. What do other people think?
> > >>
> > >>Mat
> > >>
> > >>Matthew Sherman
> > >>Vice Chair, IEEE 802
> > >>Technology Consultant
> > >>Communications Technology Research
> > >>AT&T Labs - Shannon Laboratory
> > >>Room B255, Building 103
> > >>180 Park Avenue
> > >>P.O. Box 971
> > >>Florham Park, NJ 07932-0971
> > >>Phone: +1 (973) 236-6925
> > >>Fax: +1 (973) 360-5877
> > >>EMAIL: mjsherman@att.com
>
> --
> Michael Takefman tak@cisco.com
> Manager of Engineering, Cisco Systems
> Chair IEEE 802.17 Stds WG
> 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> voice: 613-254-3399 cell:613-220-6991
--
Michael Takefman tak@cisco.com
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 cell:613-220-6991