Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.