| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Steve - it seems that important context has been removed from your email below - almost to the point where it appears a constructed argument, aimed at the pending appeal. I hope not, and trust that you're trying to get to understanding here.
Please bear in mind that the opinions below are mine based on reading the superior rules. My responses add in the context to minimize misunderstanding.
The LMSC chair and the LMSC will ultimately weigh in on how they bear in any appeal.
See below for detailed responses, again, my personal opinions based on reading the superior rules.
-george
From: Steve Shellhammer <sshellha@xxxxxxxxxxxxxxxx>
Sent: Monday, October 12, 2026 13:57 To: STDS-802-LMSC@xxxxxxxxxxxxxxxxx <STDS-802-LMSC@xxxxxxxxxxxxxxxxx>; George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> Cc: Menzo Wentink <mwentink@xxxxxxxxxxxxxxxx> Subject: Re: [802-LMSC] Revised review draft of FAQ of 'technical vs. procedural considerations..." Hi George, Thanks for preparing the draft FAQ on Procedural versus Technical. We had a few questions on the FAQ. Question 4 In the answer the document states “… or if it makes no change to the draft without a technical statement as to why no change is necessary, the group has not actually taken a technical action.” Is that suggesting that if a Technical Comment is submitted, that it can be rejected without a technical reason to reject the comment? Is that lack of consensus based on the group’s technical opinion? Does approval of that resolution require 50% or 75% approval?
GZ>> Q4 is about whether a response to a comment always requires a 75% vote. The rules for requiring a 75% vote, which is what Q4 is about, relate to a technical change to the draft, or "any other technical matter". The superior rules (WG P&P, and IEEE
SASB Ops Manual) do not treat comments that a commenter has designated "Technical", "Editorial", or "General" any differently - they simply say "all comments shall be considered", and hence, there is no different treatment of a "Technical comment" under them.
When a change is made (such as an "ACCEPT" or "REVISED") it may be a technical change to the draft, and hence under the WG P&P require a 75% vote. When no change is made, however, the only option is "REJECT". A "Reject" needs to provide a reason, and
it may or may not contain a technical statement of the group's consensus. Revcom guidelines provide valid reasons for rejecting a comment, and ultimately, Revcom reviews these. Valid reasons can be disagreement (technical), and technical disagreements, such
as "CRG disagrees with the commenter, a nurgle is not needed, and a flange is sufficient", would fall under 'other technical matters'. However, the reject could be editorial - the formatting is correct - note, usually the commenter marks these "editorial",
but not always - and again, the superior rules don't differentiate. However, revcom guidelines also give examples of rejections that aren't technical such as items in the structure of the comment (for example, a comment lacking sufficient detail to understand
the change that would satisfy the commenter, or that there is an issue with attachments making the comment invalid), or a reject could simply be a statement that the CRG lacks consensus on a change to satisfy the commenter. When that happens, the GROUP does
not "have a technical opinion" as you suggest because there is lack of consensus. If they were, there would be consensus on reasons to disagree. In these cases, the SASB Ops manual requires evidence that the comment was considered. But given lack of consensus,
any opinion is of individuals. Individuals may have differing reasons for not having consensus - but the statement of lack of consensus is merely a statement of fact - to do more would be putting words in people's mouths. It would, in my opinion, be impossible
to say this is "based on the group's technical opinion" - since the group, as a body, has stated no technical opinion - it is merely stating a procedural fact about the state of the group. Given that the 'no consensus' makes no change, it doesn't fall under
the "any technical change" either, and the SASB Ops Manual requires evidence to be provided that the comment was considered, such as would be suitable for inclusion in minutes (e.g., failed motions or straw polls) - it is reasonable that a decision on 'minuting'
such evidence requires 50% as in the WG P&P.
Question 5 In the answer it states: “consensus on the reason doesn’t matter, only consensus on the change.” Does that mean that the CRG can provide a resolution (since there is a consensus) without a reason (since there is no consensus)?
GZ>> Q5 is about what the CRG is required to do on each comment. They are required to consider. (not close, resolve, etc.)... The sentence you quote is made in connection with a comment response of ACCEPTED or REVISED. In the ACCEPT case, no additional text
is even allowed - so that group has no opportunity to voice an opinion on why to make the verbatim change - only that they would make the verbatim change. In the REVISED case, the only thing required by the rules is an explanation for why the verbatim remedy
wasn't made - not whether the group agreed with the commenter's argument. SO yes, as long as the group has consensus on the change to make they can provide a resolution. The are either forbidden from recording the reason (ACCEPT), or not required to (REVISED),
but rather just on why the change differs from the commenters.
Now, you seem to try to extend that to a situation of a "REJECT - no consensus for change". In that case, under the SASB Ops Manual, the group is required to provide evidence that the comment was considered (SASB Ops Manual 5.4.3.3). In this case, the most
relevant evidence would be a record of failed attempts at a consensus resolution.
Question 8 The answer indicates that if there is no consensus to approve or reject a comment then it is to be rejected with the reason being “no consensus.” Is there a reference to where this is stated in the rules? One of the valid reasons given in Revcom guidelines is for a reject "a statement that the CRG could not reach consensus on the changes necessary to address the comment;" I Summary Could the FAQ essentially be summarized to say that 75% motions are tried on comments and when they fail, this is recorded in the minutes, and the default disposition is rejected for lack of consensus (without a vote). The chair may decide when sufficient 75% votes have been tried. Regards, Steve and Menzo
GZ>> I wouldn't summarize it that simply. As is often the case, many issues would get lost. There are several issues addressed, and I won't rehash.
You seem to be referring again to the process on lack of consensus, and the Chair's power. Under the WG P&P, the chair has a number of obligations and responsibilities to balance. In this case, that includes prioritizing work to best serve the Working Group
and its goals, entertaining motions, seeking consensus as a means of resolving issues, and allowing all parties to express their views. Balancing those responsibilities without bias is part of the process. Chairs may use their knowledge of parliamentary procedures
to help balance prioritization with seeking consensus and open discussion. For example, setting time limits on discussion or rules for debate to prevent continued rehashing of positions. So, as you say, at some point there is a judgement call - often by
the chair, but in most cases I've seen, with prior announcement or consent of the group. If a new consensus resolution truly came up, such consensus should have sufficient support to reopen discussion or add an item to the agenda even if the chair had moved
on.
I hope this helped,
-george
From: ***** IEEE 802 LAN-MAN Standards Committee ***** <STDS-802-LMSC@xxxxxxxxxxxxxxxxx> on behalf of George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, October 7, 2026 7:47 AM To: STDS-802-LMSC@xxxxxxxxxxxxxxxxx <STDS-802-LMSC@xxxxxxxxxxxxxxxxx> Subject: [802-LMSC] Revised review draft of FAQ of 'technical vs. procedural considerations..."
All - I made a number of revisions to include formatting and references as requested, as well as additional matter which had been suggested by reviewers, which I had verbally mentioned during yesterday's LMSC call.
I have additionally included in the header that this is still a review draft, as our chair, Mr. Gilb noted he had not yet accepted it as an interpretation, and, of course, that the source documents, and in some cases RevCom/SASB review will govern.
The revised draft for review can be found at
https://mentor.ieee.org/802-lmsc/dcn/26/lmsc-26-0248-01-LMSC-faq-on-procedural-vs-technical-considerations-specifically-with-regards-to-comment-resolution.pdf
I will note that this is getting about as long and deep as I would like - and I would suggest resisting efforts to get more lengthy, as one can just go and read the referenced sections of the source documents - which are the primary material anyways.
George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860
To unsubscribe from the STDS-802-LMSC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-LMSC&A=1 To unsubscribe from the STDS-802-LMSC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-LMSC&A=1 |