Re: [802SEC] RE: [802SEC] +++ LMSC P&P Revision Ballot +++ WG Voting Procedures
Just to clarify, in my "I agree with Bob's comments" I was referring to Bob
Grow's comments ...
Carl
> -----Original Message-----
> From: owner-stds-802-sec@ieee.org
> [mailto:owner-stds-802-sec@ieee.org] On Behalf Of Sherman,
> Matthew J. (US SSA)
> Sent: Sunday, October 01, 2006 8:18 AM
> To: STDS-802-SEC@listserv.ieee.org
> Subject: [802SEC] 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.
>
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.