Hi Mark,
I understand the proposals in the list as this group talk too much on them, except the last one (ID Query in PASN ).
May I request anyone can make a brief contribution on the proposal of “ ID Query in PASN ” before vote the list? If the contribution is already in the mentor, I can check it.
Thanks
Best Regards
Jay Yang
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: 2023年2月11日 5:20
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] TGbh - Chair's plan/proposal
All,
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?
Thanks. Mark
All,
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!):
- 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.
- 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.
- 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.
Mark
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
|