All,
Some of my thoughts – flame away in response!
1. 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.
a. 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.
b. I do not want the TG to get stuck waiting for this, however, I think we can continue our discussions in parallel.
c. 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).
2. 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:
a. 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.”
b. 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:
o 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.
o 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.
o 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