Thanks for the suggestion, Dave. I think my response is that I encourage anyone with ideas to make a contribution. However, I have to say that your spreadsheet sounds rather like the tables at the end of the current issues tracking document, but with (personal) opinion about whether the proposed solutions apply to each use case. I think the group ran out of momentum, or maybe it is just consensus, as we started in that direction. My best guess is that we would debate the details in such a spreadsheet forever, going in circles, again. But, as I say, I am very open to suggestions and contributions, if you or anyone would like to give it a try. I will say that I think we need to discuss the concern about our scope head-on, separately, though, and I still propose we at least work on that part of my proposal, if not the down-selecting (yet). Let’s see what the will of the group is on how to proceed. Mark From: David Halasz <dave.halasz@xxxxxxxx>
Sent: Friday, February 10, 2023 2:59 PM
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh - Chair's plan/proposal My 2 cents, - Create a spreadsheet, which has the proposals as rows. - And then we have columns for the Use Case, from the issues tracking document - Another column entry for proposal/option base presentation(s). These are also in the issues tracking document - Another column for notes. Example. This option presented to go along with proposal X. - We then fill out the spreadsheet and mark if the Use Case, is satisfied by the proposal/option. I realize this would push the date out. Just a suggestion. Sid, I’m open to wording suggestions… I am cautious, however, that we don’t mix up the PAR wording updates topic with the way forward on the proposals we have. In particular, I think the proposals are fairly clear in terms of how/when they would be used. Is that not sufficient as is, that to support a proposal, you are supporting that it be used as described (without getting wrapped up in more “pre-association” wording added to the straw poll itself)? Mark Mark Assuming the Feb 14th straw poll is for the pre-association use case. If so, can I request we add that qualifier to the straw polls please? So, given the below, and the discussion on the reflector following that email, here is my plan (open to comments, of course): - Do NOT try to run any motions on Feb 21.
- Instead, on Feb 14, have a discussion about proposed wording updates to the PAR that would clarify the scope confusion. Shoot for a motion on Feb 28 to approve updated wording to bring to the Working Group during the March plenary. If the WG agrees to the updated wording (or agrees to some other wording with different intent), then we have our answer as to what we’ve been directed to do.
- Also, on Feb 14, run a series of Straw Polls, to down-select the proposals we have under consideration. I’d like to confirm that we think this is the complete list of options:
- SMA
- MAAD
- IRM
- Non-encrypted ID in IE (AP allocates)
- Non-encrypted ID in IE (STA allocates )
- IRMA
- RRCM
- e-RRCM
- ID encoding
- ID Query in PASN
If anyone thinks anything is missing from this list (or is in error to be on the list) please let me know. - The straw polls would be something of the form: “Which of the following can you support (in concept – perhaps after some technical clean-up) for inclusion in TGbh?” with a multiple choice answer (vote for zero, one, or more). The proposal with the fewest votes in support gets dropped, and we repeat the straw poll with the shorter list. We keep going until we have 1 left, or until we have only a few (2? 3?) that all have at least majority support.
- From the result of the down-select, we work on a motion for Feb 28 to include that 1 (or 2-3) into the draft.
- Between Feb 14 and Feb 28 we work on technical details to clean up the proposal(s) that will be motioned.
Comments? Other suggestions? Some of my thoughts – flame away in response! - The scope of our work is set by the Working Group (with EC approval, of course) through the PAR. As there seems to be some disagreement about what the PAR meant by the words that are there, it seems that getting/confirming clarification from the Working Group is in order. I’m very sensitive to the comments Mike M made on the recent call, that we should not waste time fine tuning PAR language, but rather get on with finding an agreed scope and doing the work to support that scope. That said, I also note that we will soon (I hope!) be asking the entire Working Group for review, comment, and approval of our draft through the WG LB process. If the WG does not have an agreed scope for our activity, the LB process is going to go in circles just as our recent TG discussions have. Thus, I think it makes sense to try to get clarity on what the WG feels is our scope, sooner than later. Based on this, we’ll know what to include in our amendment to fulfill that scope.
- So, I am thinking that it does make sense to work on a clarification of wording in the PAR, after all. We can put this to WG vote at the March plenary and have done with the discussion.
- I do not want the TG to get stuck waiting for this, however, I think we can continue our discussions in parallel.
- I do suggest we take a little time over the next couple weeks to formulate more clear words for the PAR, in particular the part: “this amendment preserves the ability to provide customer support, conduct network diagnostics and troubleshooting, and detect device arrival in a trusted environment.” I’ve proposed some text below. I do not expect this text will get unanimous support – I know that we do not have agreement on this detail of our scope. The point is get agreement (at least majority) on words that will convey a (potential) intent for the project, and then see if we have agreement at the WG level on this intent (or not).
- In parallel, to make progress on finding one or more solutions that can satisfy this intent (said solutions to be included or not, depending on the scope agreed, per above), I suggest we take Joe’s suggestion of a down-select process. One of my worries about our current status is that we have a minority of support for each of the potential solutions (with some overlap, I’m sure), each with its desire to “see our solution selected.” Thus, combined, these minorities turn into a majority that wants to see _some_ solution get included, but no individual solution has the support needed to get it included. There are two possible outcomes:
- As we down-select, the support will coalesce toward a solution that can get enough support, as a “better than doing nothing” direction, even if that solution is not currently getting enough support when in competition with other solution(s) that are “favorites.”
- OR, no solution will in fact draw enough support, which is an indication that the interest is not really in finding a solution to the problems stated, but rather the interest is split between getting different “favorite” proposals into the amendment. If this is the case, then we have no consensus that finding some/any solution is really that important, and it is the correct direction to adopt none of them.
Hence, my suggestion to the group is to run through the down-select process, more-or-less as Joe described in his email: Hold a series of Straw Polls on the solutions we have, eliminating those that get the least support each time, until we are down to one (or two, if someone wants to justify that multiple are appropriate to cover different use cases, or some such – this needs a presentation, though!): a. Yes, Straw Polls, and not motions, and hence no recording of votes. We are not voting to take an action, and a motion would be inappropriate in my opinion. b. The other aspect of Straw Polls is that not-voting members can participate. I have not seen this to be a problem on our calls – I think all the participants are voters anyway. c. If anyone has another suggestion (or disagrees with above) please respond with an alternative suggestion. For the context of both points above, I suggest that this is what we are working on (the (admittedly not agreed) scope that the possible solutions are trying to address): - One (or more) solutions that will support identification of non-AP STAs that use a randomized MAC address, but where the network and/or its users need or desire some of the following:
- Customer support – interaction with a trusted third-party who can access the network internals on behalf of a client, if that client can be identified. This includes support for issues both after association, but also prior to association including difficulties getting the device onto the network.
- Network diagnostics and troubleshooting – supporting the ability of the network to do analytics on situations that are potentially disruptive to, or could decrease, the overall performance of the network for its users. This includes recognizing interference issues including the overlap of other networks, rogue devices either actively or accidentally using network resources, and known/approved devices that either cannot connect to the network or that connect in non-ideal ways that could be mitigated by network action.
- Device arrival detection – recognizing a known device that is within range, but before or without requiring it to associate, so that the network can take actions to support the device getting services that might be otherwise unavailable, and/or to provide information about the device presence to external systems.
I’m thinking of language something like the following, as modification to the phrase in the PAR, to clarify the scenarios that we are discussing (to be clarified as either within our scope, or not within our scope): … the ability to provide customer support (including but not limited to issues connecting to the network), network diagnostics and troubleshooting (including analytics of client devices that are not associated, such as overlapping networks, rogue devices, and devices with connection issues), and, within a trusted environment, detect device arrival (including detecting known devices before they have connected to the network). As I said, please flame away.
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 |