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

Re: [802SEC] +++30 day EC pseudo-ballot+++ Signs of Dominance document



Hi Geoff,
   In reviewing the document in question, it was a set of descriptions that a WG/TG/TF chair could use to help identify potential dominance.
The document did not offer a remedy that differs from the one that is quoted as the "one company - one vote" remedy that is in the P&P now.

I think that as we look at the things that the chairs should be aware of to help in their detection of dominance as a first step.
We can debate how to stem the behavior secondarily.
Often just making a group aware of the perception of bad behavior is enough to have self correction take place.
Ideally, we all come and work as individuals and are able to provide that "best" of ourselves in making a good standard better.
When we forget ourselves, a reminder is hopefully all that is needed to return to better behavior.

I have no immediate comments on this version as I helped in earlier drafts, but look forward to others insight on if we are marking observed behaviors as signs of dominance where it really is just some other form of consensus or lack there of.

FWIW,
Jon



-----------------------------------------------------------------------------
Jon Rosdahl                 Engineer, Senior Staff
office: 801-492-4023      Qualcomm Technologies, Inc.
cell:   801-376-6435      10871 North 5750 West
                                   Highland, UT 84003

A Job is only necessary to eat!

A Family is necessary to be happy!!

On Thu, Jul 20, 2017 at 5:17 PM, Geoff Thompson <thompson@ieee.org> wrote:
Andrew-

I was not suggesting that we reopen the 11ax matter.
Please excuse me if that seemed to be the case.
Rather, I thought what was asked for was a critique of the process 
as a basis for dealing with dominance issues in the future.

My point is that we want a well-known system that keeps it from happening again.

Geoff

 
On Jul 20, 2017, at 3:51 PMPDT, Andrew Myles (amyles) <amyles@cisco.com> wrote:

G’day Geoff
 
Your comment focuses on the need for punishment as a mechanism for deterring dominant behaviour. I agree that punishment is sometimes appropriate.
 
We could have a discussion about punishment in the context of the recent 11ax issue. However, I would strongly recommend against it on the grounds that it would require re-litigating and re-opening an issue that was resolved appropriately, and very recently, according to our processes. We should let it lie for a while rather than reopening fresh wounds on an issue that is not quite as black and white as you might think.
 
I am also not sure that we need to discuss punishment in the context of the document that Adrian sent out. The document focuses on ways to avoid dominance in the first place by recognising signs of dominance and ensuring it goes no further. If we get that right there is no need for punishment.
 
Andrew
 
From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-SEC@ieee.org] On Behalf Of Geoff Thompson
Sent: Friday, 21 July 2017 3:50 AM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] +++30 day EC pseudo-ballot+++ Signs of Dominance document
 
Adrian-
 
My problem with your process can be categorized as a general overall comment.
 
You restored each individual's full voting rights rights as soon as they made a statement renouncing their membership in the cabal.
The alternative would have been to keep them in the single vote "dominance" group for some greater length of time.
 
The problem with this remedy is that it is a "no lose" scenario for the offender.
There is effectively no penalty for the collusion.
If you get away with it then that is great.
If you get caught then you just renounce it immediately so no big loss.
 
What is called for in SA procedure is for the group to be reduced to just one vote.
As I recall, it is not specified when that penalty is to be lifted.
If the penalty is held in place too long then it is too draconian
If not held in place long enough then there is no disincentive.
 
In this case, in my opinion (but then I wasn't in the middle of it at all) it was too much on the side of providing no disincentive for taking another whack at it in the future.
 
Best regards,
 
            Geoff
 
 
On Jul 17, 2017, at 2:16 AMPDT, Adrian Stephens <adrian.p.stephens@ieee.org> wrote:
 
Dear EC,

I was tasked with running a "pseudo-ballot" on the signs of dominance document that was presented (briefly) at the EC closing plenary.   Having determined that the P&P documents contain no guidance,  I examined the closest entrails to discover a process
The purpose of this "pseudo-ballot" is to collect comments,  not to determine approval.   If you have no comments,  you do not need to respond.

There will be a 30-day comment collection period, during which you can send in comments on the document.
At the end of that period,  I will collate the comments and attempt to provide a resolution.  I might bring in other EC members to assist at that point.

Please provide comments using only the attached spreadsheet.

The document under review is:  
https://mentorieee.org/802-ec/dcn/17/ec-17-0083-01-00EC-signs-of-dominance-toolkit.pdf

This is the same as presented,  with the exception of added line numbers,  and conversion of format to .pdf (to prevent letter->A4 repagination).

The close date is 2017-08-16.  I will send out a reminder 2 days early

-- 
Best Regards,
 
Adrian Stephens
IEEE 802.11 Working Group Chair
mailto: adrian.p.stephens@ieee.org
Phone: +1 (971) 203-2032
Phone: +447342178905
Skype: adrian_stephens
---------- This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv. <signs of dominance doc comments.xlsx>
 
---------- 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.