Hi Mark, Stephen,
I have been thinking hard about your points and I admit I am torn. My immediate reaction is “do we really need to explain the PAR, as is, or are we trying to change it?”. Do we really disagree over what it says? Mark’s proposal clarifies
points that I would have hoped we did not really disagree on.
My point has been, that for me, the PAR is not met if we only have the Device ID scheme in our Draft. Now if some wanted to change the PAR such that no other scheme in addition to Device ID is needed, then fair enough, but if so they need
to produce a presentation that formally lays out the arguments and justifications to do so, in the light of the TIG and SG work. I have not seen anything along these lines.
In addition to the PAR topic, we have heard comments that TGbh should not introduce something that would require TGbi to later ‘repair’. Again, no specifics and no presentation that looks at proposed TGbh solutions and how they create
a ‘problem’ for TGbi.
One thing I can say is that I have made presentations that have looked at all the possible ‘problems’ and provided details as to how proposed schemes work and why they satisfy TGbh PAR. Again, I have not seen a presentation that explains
why these solutions will be a problem for TGbi, or, indeed, why the PAR needs to be changed and how the PAR writers “got it wrong”. I’m all for reasoned arguments, so let’s see them.
OK, having said that, how do we go ahead? A majority of the TG does wants to see solution(s) that meet the PAR, but it is not clear if the majority is 75%. Several straw polls on “pre-schemes” have not met the 75%. Hence, I wanted a
Motion on this. Then if it passes, the TG is sort of beholden to accept one or more of the proposed schemes. If it failed, then the PAR problem has to be faced.
Mark and others are correct that one problem is that we have 8 or so proposals – some, however, are similar except that the STA or the AP allocates. Yes, of course this dilutes the votes. We then have the “simple/computation” split.
One thought is that I see nothing wrong in having three solutions, Device ID/simple pre/computational pre.
Anyhow, I suppose what I am saying is it will not be easy, but I do feel that before we rush into changing the PAR we need to ask the basic question as to whether the TG wants to meet the PAR.
Thanks
Graham
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, February 9, 2023 2:12 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh motions, PAR, and way forward
Maybe “restore” would have been a better word. The challenge with this group is that we are not trying to add anything _new_, just _restore_ (
😊) what got broken. It doesn’t fit the mold for the PAR as nicely.
All that said, how far do we want to go with revisiting the PAR, at this point? I was just trying to clarify whether we intended “pre-association” features/activities to be part of the list of what we “restored” or not – on the assumption
that we were all in agreement and understanding that our goal was to restore broken features/activities and the disagreement/disconnect was just about the breadth of those items.
Mark
I can see your point of view, although my interpretation of the word "preserved" means maintain, as opposed to correct. Moving forward, I think the PAR should explicitly list the items that are considered broken and that the amendment will
fix, although items such as customer support are out of scope of 802.11.
Hi, Stephen,
Hmm. Maybe there is a deeper difference of opinion…? I read that sentence as saying, “Now that STAs are using RCMs, these things that have become broken are going to be preserved
(restored back to working) by this amendment…” Thus, this list is explicitly some of the items that the amendment is meant to address.
Mark
thanks for the detailed and honest email. I think the process you outline is reasonable and I agree with it.
However, regarding the phrase in the PAR, I disagree. The start of the sentence you have quoted is "For STAs in an ESS that use randomized
or changing MAC addresses, this amendment preserves....", in other words, these are the items that the amendment is not going to change. Therefore I think an extended detailed list as you have suggested is simply not necessary. It also appears to me that the
items quoted in this sentence deal with "the network" and are therefore out of scope of 802.11.
My conclusion is to delete this entire 2nd sentence of this paragraph, as it does not provide any additional detail about what the amendment
is trying to do (as opposed to what the amendment is not trying to do).
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
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
|