Re: [802SEC] +++ LMSC P&P Revision Ballot +++ WG Voting Procedures
All,
I forgot to tally the votes. Please see correction below....
Matthew Sherman, Ph.D.
Senior Member Technical Staff
BAE Systems Network Enabled Solutions (NES)
Office: +1 973.633.6344
email: matthew.sherman@baesystems.com
-----Original Message-----
From: ***** IEEE 802 Executive Committee List *****
[mailto:STDS-802-SEC@ieee.org] On Behalf Of Sherman, Matthew J. (US SSA)
Sent: Saturday, September 30, 2006 11:12 PM
To: STDS-802-SEC@listserv.ieee.org
Subject: Re: [802SEC] +++ LMSC P&P Revision Ballot +++ WG Voting
Procedures
Dear EC members,
Below you will find the current results on this ballot. The ballot
closes 0n 10/3/2006 @ 11:59 PM EDT. The comments are included below the
vote counts. Please let me know if you see any errors in the
accounting.
If you have not already done so, please respond with votes / comments.
Thanks & Regards,
Mat
Voters DNV DIS APP ABS Comments Provided?
---------------------------------------------------------
00 Paul Nikolich APP Yes
01 Mat Sherman DNV
02 Pat Thaler DIS Yes
03 Buzz Rigsbee DNV
04 Bob O'Hara DNV
05 John Hawkins DNV
06 Tony Jeffree DIS Yes
07 Bob Grow DIS Yes
08 Stuart Kerry DNV
09 Bob Heile DNV
10 Roger Marks DNV
11 Mike Takefman DIS Yes
12 Mike Lynch DNV
13 Steve Shellhammer DIS Yes
14 Vivek Gupta DNV
15 Carl Stevenson DIS Yes
---+++---+++---+++---+++---+++---+++---+++---+++---+++---
TOTALS DNV DIS APP ABS
total: -09- -06- -01- -00-
Ballot Comments:
------------------------------------------------------------------------
----------------------------------------
------------------------------------------------------------------------
----------------------------------------
Paul Nikolich [paul.nikolich@att.net]
Tue 9/5/2006 11:20 AM
I vote approve.
My editorial non-binding comments on the ballot:
1) 7.2.3.4.g Rights--upon reading this one could take the interpretation
that the combined membership of the WGs (exclusive of TAGs) could force
resolution implementation. What is meant, I believe, is the combined
membership of WGs and TAGs. This doesn't require a change--I am just
alerting you to a change that may be needed in the future.
2) 7.2.4.2.2 -- I would remove the specific sub-clause reference to the
IEEE-SA SBOM - leave it general so we don't have to worry about how SBOM
may be restructured
3) 7.2.4.4 -- I would remove the specific sub-clause reference to the
IEEE CS SAB P&P--leave it general, or better yet, refer to the
appropriate IEEE SA document to eliminate the dependancy on CS SAB.
------------------------------------------------------------------------
----------------------------------------
Shellhammer, Steve [sshellha@qualcomm.com]
Wed 9/6/2006 3:26 PM
I vote NO but will change my vote to YES if the following
changes are made.
1. In Section 7.2.4.3 (Chair's Function) change "output documents
of the Working Group" to "either a PAR or a draft." The phrase "output
documents" is too vague for my taste. Since those are the two output
documents of a working group I think it is better to list them than to
use such a vague phrase.
2. In Section 7.2.4.2.1 drop the sentence "Non-technical motions,
when allowed, are determined in accordance with parliamentary
procedure." Once again the phrase "parliamentary procedure" is way too
vague. If the working groups want to describe how they hold these
non-technical motions using specific language that would be fine, but
this vague statement does not work.
3. In Section 7.2.4.2.1 drop the phrase "at least." A majority is
well defined and does not require that phrase, since it is included
within the definition.
Just one observation. In this document the section entitled
"Chair's Function" is numbered 7.2.4.3, but that section number is also
used later. I thin there is a small typo in the section number.
------------------------------------------------------------------------
----------------------------------------
Mike Takefman (tak) [tak@CISCO.COM]
Wed 9/6/2006 4:46 PM
I also vote NO and I'll come up with a list of my concerns. But reading
Steve's comments made me think and I feel it necessary to comment
immediately.
While I agree with Steve that "output document" seems vague, the set
"PAR and Draft" is merely a subset of useful documents that a WG or TAG
could produce that require 75% approval (IMO).
WG's produce liaisons both internal to 802 and external to IEEE, press
releases etc. So an output document (to me, and I'd think the majority
of people), means anything that leaves the WG, and I see that as the
minimum acceptable set.
WGs produce documents for their own internal use that are technical in
nature and affect a draft and so I'd personnaly want to see the bar set
at 75% for those documents too.
For example, in 802.17 there was a lot of discussion on simulation
requirements and methods for benchmarking proposals. The phrase output
document doesn't include a document that would specify how simulations
should be run, nor the minimum acceptable performance, yet it is clearly
an important document, technical in nature as it will affect the draft.
Imagine the host of appeals that would insue if such a document was
classified as procedural as it wasn't an output document and then
someone objects to the draft moving forward when its technical content
was based on simulation requirements that couldn't achieve 75%
concensus.
Our old language was much more open, but that might not be a bad thing
since once you try to restrict things, you end up risking creating the
wrong set of limitations.
I'll think some more about a better phrase then merely output document
but I think a more inclusive term would be better.
------------------------------------------------------------------------
----------------------------------------
Shellhammer, Steve [sshellha@QUALCOMM.COM]
Wed 9/6/2006 5:15 PM
Mike,
Thanks for thinking of other "output documents" the only ones I
could think of were the PAR and draft. Those were the technical ones I
could think of.
I think you bring up some other good points about the problems
with attempting to define "what is technical." Before we left it to the
chair to make the determination on whether something is technical or
not. If we attempt to give a precise definition of what is technical we
may have difficulty in generating such a definition. But a phase like
those issues that "can impact the substance of an output document" may
not work. We have in essence replaced "technical" with "substance."
And of course what we my by "substance" is something technical.
------------------------------------------------------------------------
----------------------------------------
Al Petrick [apetrick@WIDEFI.COM]
Thu 9/7/2006 6:07 AM
Mike/Steve
Both of you have very good questions!
Let me try to help clarify the issues that were raised by Steve and
yourself, as I was worked with a small Ad-Hoc group inside 802.11 that
came up with the suggested recommended changes. This should help clarify
your concerns.
Clarification: Clause 7.2.4.3;
* The WG Chair (as well as the TG,SC,SG Chairs) decides what is
technical and non-technical wrt issues and motions on the floor. This is
the first determination. Procedure is the next step.
o It was recommended to change "procedural" to "non-technical"
because the chair then applies parliamentary rulings to motions on the
floor to seek proper "procedure". Some motions under parliamentary
procedure require 50% approval, while others require, 2/3 or a majority
approval.
* Sentence: "Technical issues are those that can impact the
substance of "output documents" of the Working Group.
o "Output documents" are those that leave the WG and passed on to
the IEEE 802 hierarchy seeking approval or to bodies (liaisons, stds
organizations, or other entities) outside the IEEE. Such output
documents include specifically PARs, Drafts, but may include for example
letters to outside bodies that has technical content (substance). For
this reason, "Output documents" was specified.
------------------------------------------------------------------------
----------------------------------------
Tony Jeffree [tony@JEFFREE.CO.UK] Thu
9/7/2006 7:12 AM
Steve -
PARs and drafts are NOT the only output documents of a WG. We also
generate liaisons and position papers to other organizations, and
meeting minutes, for example; I believe that motions approving these are
rightly considered to be technical motions also.
I agree that "output documents" is vague, but the way to fix that is to
add a definition of what the list of things that constitute "output
documents"
actually is, and then use the term. However, the list of things that
need to be decided by a "technical" (75% approval) vote of the WG is
ABSOLUTELY NOT IMHO restricted to output documents; for example, a
motion to impose a directed position on a Chair, or a motion to remove a
Chair from office, should very definitely be considered to be
"technical" votes as opposed to procedural (decided by the Chair)
matters! So I think the fundamental problem with this change to defining
the "procedural/technical" distinction only in terms of output documents
is that in doing so, there is a class of decisions that must be made by
the WG that fall outside the (current) definition of "Technical" and
that should have been included.
------------------------------------------------------------------------
----------------------------------------
Mike Takefman (tak) [tak@CISCO.COM] Thu
9/7/2006 9:37 AM
Al,
Was there a specific problem or concern that prompted the Ad-Hoc group
to go about suggesting these changes?
------------------------------------------------------------------------
----------------------------------------
Tony Jeffree [tony@jeffree.co.uk] Thu
9/7/2006 10:49 AM
I vote Disapprove.
Nits:
There is something screwed up about the subclause numbering (there are
two instances of 7.2.4.3 and one of them precedes 7.2.4.2).
Substantive issues:
As Steve Shellhammer has pointed out, and as amplified in my response to
his comments, the whole issue of Technical vs Procedural in this set of
rules is somewhat screwed up.
Firstly, it makes no sense at all to say that the Chair decides
procedural (sorry, non-technical) issues, and then to go on to say that
when the Chair decides to use the WG's help in determining a procedural
issue by taking a vote of the WG, that it should be done in a particular
way. For example, if I decide that an issue is procedural (choosing the
venue for the next interim, maybe), but that I want the WG to assist me
in that decision by running a straw poll, I don't want the P&P to impose
rules on how that straw poll is conducted, and I absolutely DO NOT want
that informal mechanism suddenly to be subject to parliamentary
procedure. That is just plain nuts. Either an issue is procedural, and
the Chair gets to decide the outcome (including taking advice/help from
the WG, if he/she feels it appropriate, and in any way that he/she may
choose), or it is not procedural, and the WG gets to vote, and with the
outcome subject to 75% approval. So introducing the concept of some
other kind of "non-technical motion" into the vocabulary, surrounded
with wooly words about them being subject to parliamentary procedure,
isn't helpful and simply allows us to continue to get wrapped around
this particular axle.
Secondly, as I pointed out in response to Steve, the set of issues that
require a 75% approval certainly include drafts and PARs, but is very
much NOT restricted to those two items.
So, what I would like to see an alternative approach along these lines:
- That we only ever talk about one form of "Voting in meetings" - and
that one form requires 75% approval to pass.
- That the set of things that we absolutely require to be decided by a
WG vote (75% approval) gets clearly stated, along with the principle
that lies behind it, so that if we've missed anything from the set then
it is as clear as possible how the set would be populated.
- That the question of how the Chair might run a non-technical "motion",
or any other kind of procedure for that matter, in order to assist in
the determination of a procedural issue, doesn't get discussed in the
P&P at all, as it is all covered under the blanket statement that "The
Chair decides procedural issues".
If I get time in the next few days I will propose some wording changes.
------------------------------------------------------------------------
----------------------------------------
Tony Jeffree [tony@JEFFREE.CO.UK] Thu
9/7/2006 10:48 AM
Roger -
At 15:30 07/09/2006, Roger B. Marks wrote:
>Tony,
>
>Of the items you suggested should be on the 75% list, several of them
>are already addressed by existing P&P clauses that specify 75%:
> 9.1 Procedure for Establishing a Directed Position
> 7.2.4.4 Removal of Working Group Chairs or Vice Chairs
> 14.2 Procedure for Communication with Government Bodies
That's fine - what I suggested doesn't contradict that. However (and I
have fleshed this out a bit in my comments - you will see them shortly)
we could very easily make this all a lot clearer just by saying that
there is only one type of "voting in (WG) meetings" and that it requires
75%. Then there would be no need to re-state the 75% threshold
everywhere.
>The procedure for liaisons does not specify 75%:
> 14.1 Procedure for Coordination with Other Standards Bodies
I believe that should be 75%.
>I don't think the threshold for meeting minutes is currently
>established.
Similarly, I think that should be 75%. If 49% of my WG (or even 95% come
to
that) didn't want to approve the minutes, then I would suspect that
there might just be something wrong with them.
------------------------------------------------------------------------
----------------------------------------
Roger B. Marks [r.b.marks@IEEE.ORG] Thu
9/7/2006 11:26 AM
Tony,
I agree 100%.
I'd just like to add a note. You propose that the rules should be such:
-That we only ever talk about one form of "Voting in meetings" - and
that one form requires 75% approval to pass.
The point I'd like to make is that this is exactly what the rules say
and have always said (since I've been around).
------------------------------------------------------------------------
----------------------------------------
Tony Jeffree [tony@JEFFREE.CO.UK]
Thu 9/7/2006 11:38 AM
Roger -
Absolutely. I can see no good reason to move away from that, other than
to clarify and reinforce what that actually means.
------------------------------------------------------------------------
----------------------------------------
Pat Thaler [pthaler@broadcom.com]
Thu 9/7/2006 5:57 PM
I vote disapprove primarily due to 7.2.4.3
7.2.4.3 I agree with Mike Takefman's comments on the attempt to define
"technical issues." I don't think that the definition of "technical
issues" clarifies the boundary between technical and procedure much. Is
adoption of a down select process a technical or non-technical vote?
With no definition some say it is and some say it isn't. With this
definition, some would say that it does not impact the substance of
output documents because it doesn't directly say what goes into the
draft, others would say that in defining how the material to go into the
draft is selected it does impact the substance of the draft. Grey area
remains grey. I don't understand why "procedural" became
"non-technical."
I think the section was better before we touched it. Chair's discretion
included the choice on the chair's part to put a procedural issue to a
50% vote.
The one problem I see with the section is that there are various things
that aren't technical like directed positions or waiving of term limits
that are required to have votes. WGs may also have Working Group rules
that require votes on some non-technical issues. Perhaps "non-technical
issues" should be "non-technical issues that are not covered by other
voting rules in the LMSC or Working Group P&P." (substitute what ever
you usually use for self-refering ot the P&P.)
Some picky points:
7.2.4.3 1st sentence might read better: "The Chair of the Working Group
may decide non-technical issues or may allow a non-technical issue to be
decided by a motion.
7.2.4.2.1 increases the quorum requirement for any group with an even
number of members by one member (changes a greater than or equal to half
requirement to majority which is greater than one half).
The text of 7.2.4.2.3 says the WG chair has discretion on what can be
decided by electronic ballot which isn't quite consistant with other
parts of the rules that require certain votes to take place at a
plenary. Text of 7.2.4.2.3:
"7.2.4.2.3 Voting by Electronic Ballots
Other matters may also be decided by an electronic ballot at the
discretion of the Working Group Chair.
The response time for these ballots shall be at least fifteen days."
For example, 7.2.2 says that WG chairs are elected at plenary sessions.
Possibly we should add: "Except for votes that are explicitly required
to take place at a meeting,"
------------------------------------------------------------------------
----------------------------------------
Grow, Bob [bob.grow@intel.com] Tue
9/19/2006 8:21 PM
Colleagues:
I opted to eliminate all of the previous discussion from this message,
but I may reference some of it.
Though I support much in this ballot, I vote Disapprove.
The primary textual problems are 7.4.2.3 and one issue related to
7.4.2.1. I also vote disapprove because changes in this area are
premature based on active work at the IEEE-SA and IEEE levels.
1. Disapprove, General -- There is currently a Voting ad-hoc committee
working to refine IEEE requirements for IEEE-SA standards development
needs. One item of discussion is if our letter ballot process is
consistent with IEEE Bylaws. LMSC representatives at the Standards
Board have argued that it is because it really isn't a "vote". The
action is taken by the LMSC EC which is consistent with IEEE Bylaws
requirements for electronic process.
This work also could also affect quorum and "voting in a meeting"
requirements. Though the major issue is with electronic voting which
includes our "letter ballots".
We should wait to see what is resolve here before we start fixing
language about what votes are required, the process required for those
votes and the language used to describe them.
2. Disapprove, p.2, l.4 -- I agree with others that 7.4.2.3 is totally
messed up. The lack of parallel construction (issues v. motions) is
very broken. Should use parallel construction.
3. p.2, l.3 -- While these changes attempt to remove the non-parallel
procedural and technical, the use of procedural was useful in refining
what is appropriately considered non-technical.
4. Disapprove, p.2, l.4 -- I agree with others that attempting to
define "technical" is an ill-advised "rat hole". I could live with
language that is inclusive rather than definitive "(e.g., actions that
affect the content of a draft)".
5. Disapprove, p.2, l.3 -- The old language allowed the Chair to decide
a procedural issue, to put a procedural issue to some kind of decision
process consistent with open, fair and democratic process, or even (as
some might wish to be the only alternative) to be decided via motion and
Robert's Rules of Order.
6. Disapprove, p.2, l.15 -- The added second sentence to 7.2.4.2.1 give
far too much weight to RROR as it is now the recommend guide for
parliamentary procedure. Remove it.
7. p.2, l.28 -- Inconsistent capitalization of Voter. Make consistent.
8. p.4, l.4 -- With changes, should also include electronic ballots.
------------------------------------------------------------------------
----------------------------------------
Bob O'Hara (boohara) [boohara@cisco.com]
Tue 9/19/2006 10:05 PM
I disapprove on this motion.
Comments that must be satisfied for my vote to change to approve:
7.2.4.3: I think that the change of the chair deciding procedural issues
to deciding non-technical issues is wrong. In particular for those
groups operating with treasury, expending money from the treasury should
be decided by the group and not the chair alone.
7.2.4.3: The rest of this clause is a hash. I would prefer the
following:
"The Chair of the Working Group decides procedural issues. The Chair
decides which issue are procedural. The Chair may seek the guidance of
the Working Group before deciding procedural issues. The method and
choice of seeking guidance on a procedural issue is solely at the
discretion of the Chair."
7.2.4.2: There needs to be a statement here on what must be voted upon.
I would suggest:
"Decisions on all issues that are not procedural are decided by a vote
of the Working Group."
7.2.4.2.1: Delete "technical" from the first sentence. Delete the
sentence beginning "Non-technical motions".
7.2.4.2.2: Delete the two paragraphs beginning "The Working Group Chair
determines if and how negative votes...". Replace them with the
following:
"The processing of the comments received from a letter ballot shall be
done in accordance with the procedures for Sponsor Ballots, as described
in the IEEE-SA Operations Manual."
------------------------------------------------------------------------
----------------------------------------
Carl R. Stevenson [wk3C@WK3C.COM]
Fri 9/22/2006 1:27 PM
I agree with Bob's comments and also vote Disapprove.
Matthew Sherman, Ph.D.
Senior Member Technical Staff
BAE Systems Network Enabled Solutions (NES)
Office: +1 973.633.6344
email: matthew.sherman@baesystems.com
-----Original Message-----
From: ***** IEEE 802 Executive Committee List *****
[mailto:STDS-802-SEC@ieee.org] On Behalf Of Sherman, Matthew J. (US SSA)
Sent: Sunday, September 03, 2006 11:16 PM
To: STDS-802-SEC@listserv.ieee.org
Subject: [802SEC] +++ LMSC P&P Revision Ballot +++ WG Voting Procedures
Dear EC members,
Attached you will find the text for an LMSC P&P revision ballot titled
'WG Voting Procedures'. This ballot was approved at the Friday July
21st, 2006 EC meeting. The text is identical to that presented at the
meeting. The purpose and rationale for the ballot are as given in the
attached ballot document.
Ballot Duration: 9/3/2006 - 10/3/2006 @ 11:59 PM EDT
WG/TAG chairs, please distribute this P&P revision ballot to your
groups, and invite them to comment through you. Please direct any
comments on this revision to the reflector, myself, and Al Petrick (
apetrick@widefi.com) for collection. A ballot resolution teleconference
will be scheduled for sometime prior to the November 2006 Plenary
Session.
Thanks & Regards,
Mat
Matthew Sherman, Ph.D.
Senior Member Technical Staff
BAE Systems Network Enabled Solutions (NES)
Office: +1 973.633.6344
email: matthew.sherman@baesystems.com
----------
This email is sent from the 802 Executive Committee email reflector.
This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector.
This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.