Re: [STDS-802-11-TGBT] Proposed TGbt procedure for comment resolution

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

Hi, Dan,

Thank you for your reasoned questions. My thoughts and opinions, follow.

What is in scope for a LB comment?

LB comments can be found invalid for a number of reasons, but in the case I think you are asking I see two: 1) The comment is beyond the scope of the PAR; or 2) The commenter failed to provide a Proposed Change that would satisfy the comment.

i. I have to caveat #2 with a note that in 802.11 we have a practice, and plenty of precedent, that we will accept a Proposed Change that is effectively, “A detailed resolution will be provided.” As long as a resolution is provided timely, during the comment resolution, we let this go (although I think it is actually an invalid comment, per the strict rules). And, if a resolution is not provided/agreed by the time the group needs to complete the ballot process, then the comment is considered invalid for lack of identifying a resolution.

In your example, I would personally think that a request to add PAKE is within scope of the PAR. And, as long a detailed proposal to do so is provided and agreed (note: by 75%, like anything else that goes into the draft), then it should be accepted as a valid comment and resolution.
I didn’t put anything about reviewing comments to be valid (including not out-of-scope) in the procedure. Do we think that would be helpful to add? I intended it to be the same process as described in our various OMs and P&Ps (from IEEE SA, LMSC and the 11WG).

The second step, after agreeing the comment is valid, is then for the TG to agree that the comment raises an issue that needs to be addressed in the draft. Does the TG understand the problem that is being indicated? Does the TG agree that the problem needs to be addressed in the amendment? It is best if comments like this come with some clear rationale, such as providing “scenario X” results in “problem Y” or “shortcoming Z”, unless we add a mechanism to deal with it.

I note that there is no clear distinction (or any way to make one, I claim) between “The draft needs to have A because of B” where A is a complete feature, or A is some aspect of an existing feature that is missing, or even that A is something like sufficient management control over a feature (missing from the MIB), etc., etc.

And, then, the TG needs to come to agreement on the solution to the problem, in the form of the detailed spec changes needed to address it. Again, it falls to a vote with 75% support to agree the resolution of the comment and to add the material.
I will explicitly note that things are a little different once we are recirculation balloting. In that case, there are additional constraints on comments, and the TG _can_ find a comment out-of-scope because it is not commenting on draft text or changed text.

On your question about straw polls (as part of the “TTT process” I proposed): It is my intention to agree in our procedures that any work that is done off-line (using the TTT mechanism) should get a straw poll that shows consensus before the Chair takes it to motion. I’m just trying to give the Chair the tools and everyone the clarity of process to make this review/approval step clear. I made this process just slightly heavier than the “REVmf process” only because it is assumed that the material brought in through the “TTT process” will have had more off-line work and discussion and the decision to agree to it will take a bit more consideration for those who didn’t participate. The “REVmf process” CIDs get full discussion (as needed/requested) in the TG itself, so it should be relatively easy for the Chair to judge if we have group consensus to take a resolution to motion. That said, the “REVmf process” can also end up needing a straw poll (or even a motion) for the Chair to come to that conclusion, and it is not prohibited.

TLDR; Yes, I am intentionally suggesting that at least one straw poll be done on any “TTT process” submissions, before the Chair takes them to motion. HOWEVER, I am not suggesting that such a straw poll has a “pass/fail” criteria (I still firmly believe that is an abuse of the straw poll mechanism), but it is a way for the Chair to judge if the TG overall is ready to consider the proposal at a motion.

None of that, just above, says anything about preventing anyone from calling for a straw poll or a motion at any time (that is in meeting order).

And, to the “by the way” – thanks! I did miss spelling out “TTT” anywhere. I’ll fix that (if appropriate in whatever we all end up agreeing as our procedure). And, for completeness, it stands for “topic task team”.

Mark

From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Saturday, 22 August, 2026 9:24
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] Proposed TGbt procedure for comment resolution

Hi Mark,

Comments made in a letter ballot are on the draft in question. Since TGbt’s draft 1.0 does not have a PAKE in it, it doesn’t have any fragmentation text, and it doesn’t deal with PASN then how could we get technical comments from a letter ballot on these topics?

I know in the comment collection period (which is quite unofficial) we entertained comments like “the draft should have a PAKE” and then the commenter would produce a submission addressing his comment with a resolution of “agree in principle with the commenter” (natch) and have text proposing a PAKE as resolution. But we’re not gonna allow stuff like that in a letter ballot, right? Right?

If I am mistaken then please let me know because the ballot is still open and I have not voted yet. If I’m not then maybe remove the topics that are not currently in the draft from your “Incoming CIDs” section.

Also, in your TTT process you mention, "If the Straw Poll result shows consensus on the text, the CIDs are marked as Ready for Motion, Revised, to incorporate the text.” This does not mean that we will be following the 11bn and 11bi convention of requiring a straw poll before being allowed to make a motion. Correct? We’re not going to have straw polls that “pass”, right? We have been operating under the correct 802.11 procedure of anyone who has the floor can make a motion on any topic and straw polls are merely to gauge the opinion of those currently in the room at the time of the straw poll. And that isn’t changing. Right?

By the way, what does TTT stand for?

Regards,

Dan.

“the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane.” – Marcus Aurelius

On 8/21/26, 7:17 PM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:

All,

I have uploaded a proposal for a written procedure for our (TGbt) comment resolution, going forward. I believe this is the topic of discussion on the teleconference on Monday. You can find my proposal here: https://mentor.ieee.org/802.11/dcn/26/11-26-1556-00-00bt-proposed-tgbt-procedure-for-comment-resolution.docx

I took both TGbn’s and REVmf’s process, and sort of merged them (applied one or the other, depending on the type of comment/work to resolve). I also simplified the TGbn process a bit, since we are not nearly as large a group nor working on as large a draft, so I think we can forgo a bit of the process.

Anyway, I welcome comments, and look forward to discussing on Monday’s call.

Mark

To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1