Re: [802SEC] +++ LMSC P&P Revision Ballot - Proposed Resolution +++ AudCom
Concerning the level of detail in my responses to you: Uncle! I'll try
and do a better job next time. It's been a long week, and I was tired.
However, all my new changes are clearly marked in a different color
(green) from the original changes, and I encourage you to review all the
comments and all my changes regardless.
Concerning the EC's ability to consider technical matters: I'm afraid
we must agree to disagree for now. We can debate it at the Sunday
meeting, and my goal is consensus so at that meeting (which is really a
comment resolution meeting) I'll go with the majority opinion. However,
I don't see how the EC can give 'technical advice' without a technical
vote on that advice, and I believe we are required to entertain
technical appeals (although we could rewrite our appeals rules in the
future so we don't have to). So I maintain my position that we must be
able to consider technical matters (though such situations should be
Concerning me being an 'editor': Many editor's I know offer proposed
resolutions on some matters independent of the groups they represent.
Consider this my 'comments' on the ballot having heard what everyone
else has to say. Yes, sometimes (usually after debate by the group)
bracketed text of multiple options will be brought to the group for
individual votes. I have not normally done that in the past. But I
will consider that approach in the future. For now please take my
'proposed resolution' as my comments on the ballot. Sunday I will
formulate a group opinion focused on achieving concensus.
Looking forward to further disucussions in San Francisco.
Matthew Sherman, Ph.D.
BAE Systems - Network Systems (NS)
Office: +1 973.633.6344
Cell: +1 973.229.9520
From: ***** IEEE 802 Executive Committee List *****
[mailto:STDS-802-SEC@ieee.org] On Behalf Of Tony Jeffree
Sent: Wednesday, July 11, 2007 9:36 AM
Subject: Re: [802SEC] +++ LMSC P&P Revision Ballot - Proposed Resolution
At 13:17 11/07/2007, you wrote:
>I believe I tried a more formal ballot / resolution form in the past,
>and did not have much success. But I'd be happy to try again. I agree
>that my summaries are a bit brief, and really directed to the
>balloter rather than the EC as a whole.
Be that as it may - in the case of my comments, you didn't direct
your summary to me at all - it effectively just said "Go look at the
resolutions of the other comments". I didn't find that very helpful.
>Regarding the basic issue of the EC providing technical guidance; I
>don't know how to develop such guidance on behalf of the EC without
>having 'technical' votes. This is why my personal opinion (in
>opposition of yours, Pat's, Roger's, and Steve's) is that we cannot
>formally limit ourselves to procedural votes at this time. If at some
>point we change the rules so that we can't deal with technical issue,
>then I'd happily clarify that we only do procedural votes.
I believe the piece that I quoted from (existing) 7.1.1 already
states that we only do procedural. I'm not clear what there is about
the proposal I made below that is problematic. Maybe you could
explain. It isn't inconsistent with our existing approved (at least
by us) P&Ps as far as I can tell.
>Regarding my 'recommended resolution' I hope people understand that
>is just my opinion as a single participant of the EC based on what I
>hear others say. Anyone on the EC can put forward a recommended
>resolution (and I encourage them to do so). I have an opinion on this
>matter, but frankly I'm more interested in resolving the ballot then in
>seem my opinion preside. The one thing I really do care about is that
>we don't introduce more inconstancies into our rules than we already
>have. So when I oppose you on this matter, it is as an individual (as
>we are supposed to do) based on my desire to have a consistent
>not because I have an opinion on technical vs procedural decisions in
Again, taking the model of WG ballot resolutions, whatever the
personal opinion of the Editor (who is of course entitled to express
them in the form of a vote and comments of his/her own), the Editor's
job is to get consensus on how to address the comments received, and
in the cases where that consensus is not obvious or apparent,
identify it as an issue to resolve, not to take a position of "I
believe this is the right thing to do, therefore I will ignore the
comments made" which is how your treatment of those three comments
came across. If I took that approach in my working group ballots, I
would rightly expect to be given a very hard time.
>For the record, my personal opinion on the matter is that while
>we limit ourselves to procedural issues (and we should) that we not
>formally rule out the possibility of making technical decisions. I
>believe many matters can arise (such as an appeal) where we need to
>consider and make decisions on technical issues. While I think we
>should avoid such situations like the plague, I don't think we should
>legislate them as impossible because unfortunately I think even the
>question of whether a particular WG should consider a particular PAR or
>it should be considered in an new group could be construed as a
IMHO, the single worst technical decision taken in 802's history (the
decision to reverse the bit ordering of the DA and SA relative to the
bit ordering of data in 802.5 frames) was a result of the EC imposing
the idea that the address "bits on the wire" (and I still don't know
what that means) be consistent across 802. That decision, which was
totally unnecessary in the first place, caused considerable and
continuing pain for 802.1 in developing interworking between 802 MACs
(and also of course for the implementors of our standards); the fact
that 802.5 is now effectively obsolete at last means that we can
start to unpick some of the arcane pieces of specification that we
had to invent to fix the problem.
So for me, the sooner we legislate to prevent the possibility of
decisions of that kind being handed out by the EC, the better.
>Anyway I look forward to discussing things further.
>Matthew Sherman, Ph.D.
>BAE Systems - Network Systems (NS)
>Office: +1 973.633.6344
>Cell: +1 973.229.9520
>From: ***** IEEE 802 Executive Committee List *****
>[mailto:STDS-802-SEC@ieee.org] On Behalf Of Tony Jeffree
>Sent: Wednesday, July 11, 2007 6:15 AM
>Subject: Re: [802SEC] +++ LMSC P&P Revision Ballot - Proposed
>I believe that the existing P&P state, in 7.1.1 Function [of the EC]:
>c) Provide procedural and, if necessary, technical guidance to the
>Working Groups and Technical Advisory Groups as it relates to their
>That is a far cry from the EC making technical decisions. So, while
>agreeing with you that 188.8.131.52 a) should stand as in your proposed
>draft, I believe that c) should be re-numbered as b), and read:
>"b) Place procedural matters to a vote by EC members"
>and there is an extra bullet needed, after c), of the form:
>"c.5) Put technical matters to the EC so that technical guidance can
>be offered to working groups. Where appropriate in order to determine
>consensus on the guidance offered, place the guidance to a vote by EC
>members. Such guidance is not binding on the WGs."
>By the way, I notice that Steve, Roger, Pat, and now me, have
>objected to your assertion that the EC makes technical decisions. How
>many of us does it take for you to take it on board as an issue that
>needs to be resolved by a larger group than just yourself?
>The EC makes procedural decisions on technical matters where the
>technical decision has already been taken by a WG or TAG. For
>example, approving a PAR or a RevCom submission. The only other part
>it plays in technical matters is offering technical guidance, if
>necessary. If the EC were actually to make technical decisions, there
>would/should be provision under existing 7.1.1 that such votes are
>subject to the same rule as in WGs, namely a 75% approval. I don't
>recall any such rule being applied in the EC hitherto, and I would
>strongly resist its inclusion in the future.
>The EC is not constituted as a technical body; notwithstanding the
>undeniable technical expertise of individual EC members, it is not
>competent as a body to make technical decisions on behalf of 802 or
>its WGs, that os fundamentally the job of the WGs (jointly or
>severally). It is a bit questionable as to whether it is really
>competent to offer technical advice either, but as long as it isn't
>binding, that doesn't give me too much discomfort.
>I know ballot resolutions are time consuming, but proposed
>resolutions of the form you have offered here are pretty much
>impossible to parse, as they require the reader to find, and then
>juggle with, the proposed text, the original comment emails, and your
>rather cryptic summary of how they have been dealt with. I would very
>much appreciate these summaries being presented in the kind of form
>that we expect in WG ballot resolutions, where in one document you
>can see each comment along with the proposed resolution and the
>rationale for it. 802.3 and 802.16 have developed some useful tools
>that simplify this process - I would suggest that you take a look at
>At 05:51 11/07/2007, Sherman, Matthew J. (US SSA) wrote:
> >As a reminder we will hold the usual LMSC P&P review meeting this
> >night. Attached is a proposed resolution to comments on the AudCom
> >ballot as a starting point for discussions on Sunday. The primary
> >agenda item for Sunday will be to come to consensus on a resolution
> >the AudCom ballot. If you can't make the meeting and have comments
> >the proposed resolution please forward them to the reflector for
> >discussion. I will consider all comments circulated during the
> >P&P review. Also, please be prepared to discuss the issues on the
> >Chair's Guide as well on Sunday. We will discuss that topic as time
> >allows after we complete discussions on the AudCom revision ballot.
> >As much as possible, I have accepted the comments people made. In
> >cases, I tried to improve upon the desired changes a bit. In a few
> >cases, I did not accept the requested change as I did not beleive
> >the rationale provided was valid. Here is a short list of the
> >sets and key differences in my proposed resolutions:
> >Stuart's comments - Fully incorporated
> >Steve's comment - I disagree that EC cannot make technical decisions.
> >adopted your other changes.
> > Added Parliamentarian as non-voting, but
> >may make Bob O'Hara want to reconsider being parliamentarian...
> > I snuck in emeritus. Perhaps it is time
> >officially recognize Geoff's non-voting status....
> >John Lemon's comments - Adopted all except
> > I believe it is common parliamentary
> >for the chair not to make motions
> >Roger's comments
> > Once again, yes, the EC CAN DEAL WITH
> > See 7.1.1 Function 'Provide
> >procedural and, if necessary, technical guidance to the
> >Working Groups and Technical Advisory Groups as it relates to their
> > Non members can't formally be entitled to
> >things considered. But I agree on right of Appeal for everyone
> >Pat's comments
> > Again, we can deal with technical issues!
> > Since some 'procedural votes' such as call
> >question are 66%, let's just reference Roberts Rules.
> > Your thoughts on appointed positions not
> >conflicts with other EC members
> > For now I've gone with the other
> >view point
> > I don't understand your comment on moving
> >Chairs serving as Chairs.
> >Tony's comments
> > See alternate resolutions based on comments
> >other EC members
> >Mike Lynch
> > See Alternate resolutions
> >Thanks and Regards to all,
> >Matthew Sherman, Ph.D.
> >Engineering Fellow
> >BAE Systems - Network Systems (NS)
> >Office: +1 973.633.6344
> >Cell: +1 973.229.9520
> >email: email@example.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.
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.