RE: [RPRWG] Voting for proposals
Mike,
I agree with these others, in that voting should be
on a per topic basis. I think this group is already
too polarized, and any document vote would be more
a test of the Cisco/Nortel alliance strengths than
technical judgments by expert contributors.
Harry has referred to the three proposals as the
"good, bad, and the ugly", in reference to a
Clint Eastwood classic western. Now, my perception
was the the "bad" one had better manners and the
"ugly" one was more adaptable under pressure.
I would also propose that we try to generate an
evaluation matrix before the vote. If necessary,
we could force the key proponents to generate this,
during evening sessions if necessary.
An example would be:
Proposal A Proposal B ...
Robustness (:>) (:<)
Priority (:|) (:>)
classes
Guaranteed (:<) (:|)
fairness
...
Legend:
(:>) Outstanding
(:|) Capable
(:<) Defficient
This, of course, looks much better with good
smiley-face fonts.
I tend to believe that voting creates polarization
unless:
1) The proposals are written (not slide-ware).
2) The benefits of each proposal are understood.
We have only marginally completed (1), so I suggest
that we do a bit of work on (2) before voting. And,
for (2) to work, one has to break things down into
subtopics.
I believe this is the best way to progress. I have
generally found that engineers tend to agree once
they understand each others' perspective. So, we
should strive for common understanding as #1 priority.
DVJ
>>-----Original Message-----
>>From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
>>[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Kumar Kovvali
>>Sent: Friday, November 09, 2001 5:17 AM
>>To: 'Pankaj K Jha'; Mike Takefman
>>Cc: Siamack Ayandeh; stds-802-17@xxxxxxxxxxxxxxxxxx
>>Subject: RE: [RPRWG] Voting for proposals
>>
>>
>>
>>I agree with Pankaj and we should vote on issue by issue rather
>>than on the
>>document as a whole.
>>-Kumar
>>
>>-----Original Message-----
>>From: Pankaj K Jha [mailto:pkj@xxxxxxxxxxx]
>>Sent: Thursday, November 08, 2001 5:41 PM
>>To: Mike Takefman
>>Cc: Siamack Ayandeh; stds-802-17@xxxxxxxxxxxxxxxxxx
>>Subject: [RPRWG] Voting for proposals
>>
>>
>>
>>Hi Mike:
>>
>>I fully agree with your approach on focusing on technical issues and not
>>editorial ones. I feel eliminating
>>entire documents through voting until only two remain is not a smart idea.
>>Maybe other dot groups have been
>>doing it for a while, but it still doesn't make it a good idea.
>>
>>What our technical editor should do is to start with an IEEE
>>802.x template
>>document. Then based on votes on
>>individual issues that are represented in different documents and take
>>issues (cut-and-paste them) from those
>>documents and thus complete a baseline. The authors have already used IEEE
>>templates, making it even easier
>>to do a cut-and-paste.
>>
>>Every document has good and bad sections. Eliminating an entire document
>>because it didn't garner enough
>>hands at the voting would be a waste of so much work that had gone behind
>>creating the document. We've this
>>meeting and next meeting and all the time in between to do this
>>editing, and
>>we can easily accomplish this.We
>>only have a handful of documents to look at, so it shouldn't be hard.
>>
>>Then we would've taken the best of the work and have a document that
>>represents consensus work. From then we
>>can work further on the issues to complete a draft standard.
>>
>>Best regards,
>>Pankaj
>>
>>Mike Takefman wrote:
>>
>>> Siamack,
>>>
>>> based on presentation slots requests I believe that there are
>>> three proposals before the WG.
>>>
>>> In terms of how to proceed forward with these documents. It is up
>>> to the WG to determine procedure. Most dot groups work on the
>>> method of eliminating proposals one by one. Once down to two
>>> proposals, they see how much support each proposal garners
>>> and go from there.
>>>
>>> At the end of the day, when there are two proposals where
>>> neither can garner the required support a compromise is
>>> found.
>>>
>>> I think it is important that the writers of all of these
>>> contributions get feedback as to how much support their
>>> documents have of WG members. There are any number of ways
>>> of doing this.
>>>
>>> We have November and then January to get to an intial draft.
>>> Ignoring the issues of technical debate / disagreement, I
>>> suspect any of these drafts can form a baseline to start from.
>>> People should be focusing on the technical comments and
>>> not the editorial ones. That is what we get editors to do.
>>>
>>> We can potentially get agreement on non-contenious issues and
>>> show significant progress. But at the end of the week, if we
>>> want to hit the January date the authors of the drafts need to
>>> learn from people what compromises are needed to reach a
>>> concensus position.
>>>
>>> My view is that people are not voting for the "standard" but
>>> for a baseline document. Then, committees can be formed to
>>> work through the technical details and resolve comments and
>>> flesh out more details and work with the claus editors.
>>> However, this document should spell out some of the major
>>> design decisions that the group wants to follow.
>>>
>>> The WG will eventually ballot the draft so there is always
>>> the opportunity for dissent.
>>>
>>> see you in Austin,
>>>
>>> mike
>>>
>>> Siamack Ayandeh wrote:
>>> >
>>> > Mike,
>>> >
>>> > I have a couple of questions. How many proposals will there
>>be in front
>>of the working group? Is it two
>>> > or four or perhaps a different number? And what is the procedure and
>>purpose of reviewing these
>>> > documents. Is it to converge them somehow to one proposal before it
>>moves forward similar to the T&D
>>> > document.
>>> >
>>> > Siamack
>>> >
>>> > Mike Takefman wrote:
>>> >
>>> > > Dan,
>>> > >
>>> > > Obviously it is unfortunate that you, and people from EMEA
>>> > > are not able to review the material prior to the meeting.
>>> > >
>>> > > However, this is a democratic organization and you need
>>> > > to get a passing vote to change the proceedures.
>>> > > You are certainly free to make the motion again and I
>>> > > encourage another debate on the topic.
>>> > >
>>> > > With regard to voting at this meeting, I believe it is
>>> > > reasonable to delay voting until later in the week
>>> > > to allow people time to review the documents.
>>> > >
>>> > > cheers,
>>> > >
>>> > > mike
>>> > >
>>> > > > "Romascanu, Dan (Dan)" wrote:
>>> > > >
>>> > > > Hi Mike,
>>> > > >
>>> > > > Here came my Thursday evening, which is the last day in my working
>>week, and no presentation is
>>> > > > yet available on the Web site for the meeting next week.
>>No material
>>from the different teams that
>>> > > > announced intentions to work on proposals from San Jose
>>until now is
>>available, with the exception
>>> > > > of the T&D team documents. For me, and other people coming from my
>>area this means that we will
>>> > > > not see these materials before Monday morning - with the exception
>>of the presentations of the
>>> > > > people who did the 'wrong thing' and sent their
>>presentations to the
>>whole list.
>>> > > >
>>> > > > I tried to make a motion in a previous meeting about presentations
>>being made available in advance
>>> > > > for review and examination. Unfortunately, the motion did not make
>>it. I will try to make a case
>>> > > > again for providing the material in advance:
>>> > > >
>>> > > > * There is no reason why a serious technical material cannot be
>>made available one week, or at
>>> > > > least three days in advance to a meeting - at least in a
>>preliminary form. (Does anybody
>>> > > > really believe that a material prepared at the last moment,
>>sometimes during the flight to a
>>> > > > meeting can be solid enough for a serious technical standards
>>work?)
>>> > > > * The current system puts an unfair handicap on individuals who
>>already made relatively higher
>>> > > > efforts in traveling from remote locations to attend the IEEE
>>meetings
>>> > > >
>>> > > > The situation seems to me even more serious before this meeting,
>>when we will be required to vote
>>> > > > on some important decisions.
>>> > > >
>>> > > > Regards,
>>> > > >
>>> > > > Dan
>>> > > >
>>> > > >
>>> > >
>>> > > --
>>> > > Michael Takefman tak@xxxxxxxxx
>>> > > Manager of Engineering, Cisco Systems
>>> > > Chair IEEE 802.17 Stds WG
>>> > > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
>>> > > voice: 613-271-3399 fax: 613-271-4867
>>>
>>> --
>>> Michael Takefman tak@xxxxxxxxx
>>> Manager of Engineering, Cisco Systems
>>> Chair IEEE 802.17 Stds WG
>>> 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
>>> voice: 613-271-3399 fax: 613-271-4867