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

Re: [STDS-802-11-TGBH] TGbh motions, PAR, and way forward



Thanks Mark,

I think I am better understanding your thoughts, and I am not opposed.

Few responses in line

 

Graham

 

 

From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, February 9, 2023 5:44 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] TGbh motions, PAR, and way forward

 

Hi, Graham,

 

Thanks for the detailed thoughts.  Some responses, below.

 

Mark

 

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Thursday, February 9, 2023 2:40 PM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] TGbh motions, PAR, and way forward

 

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.

[[MAH]] I put those in my proposal, because on at least the last call (and I believe some prior calls) there have been comments that I would disagree with about what the PAR says.  So, it seems that I and the person commenting disagree about the PAR’s defined scope.  I’m assuming/guessing that if we two disagree, then others probably do as well.  Hence, my suggestion that we should explain (I would say clarify) the PAR.  Personally, it is not my intent to change it, but of course if there is disagreement about what it says (or was meant to say) and we clarify it, then someone will lost their point of view and will consider this a change.  I am hopefully that we can figure out how to make a change that the majority considers to be a clarification and not a change.

[[Graham]] OK I now understand that you are looking at ‘clarification’ and not ‘changing’.  I’m OK with that.

 

My point has been, that for me, the PAR is not met if we only have the Device ID scheme in our Draft. 

[[MAH]] To your points below, perhaps it also then comes to you to “lay out the arguments and justification” that the PAR is not met with the current draft.  I don’t mean that to be snarky – it might truly help us with our discussion about what is our scope, to have that discussion.

[[Graham]] Presentation 22/1230 did exactly that  

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.

[[MAH]] I would agree with that, as Chair.  We have been round-and-round on these arguments too many times.  It is time for presentations that lay out the details of individuals’ logic, when such claims are made (either way).

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.

[[MAH]] To unpack this: I hope that we can all agree that while it is not explicitly stated anywhere (that I am aware) that TGbh should not introduce anything that TGbi will need to ‘repair’, it is clearly not productive for 802.11 to work in such a fashion.  That said, there may be a balance in TGbh trying to do something “quickly” (he said, tongue-in-cheek at this point) where TGbi may head in a different direction that makes the TGbh solution moot or not used, for example.  But, to be completely contrary to TGbi goals with a TGbh solution seems like it would violate the PAR’s requirement that we not reduce the existing privacy of 802.11. 

 

To your second point, assuming we do agree to my statement just above, then I agree with you that we need to see specifics and/or presentation for any claim that a proposed TGbh solution is causing such a situation 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.

[[MAH]] My challenge here is that motions must be about something actionable.  I’m not sure what you would motion…  That we must meet the PAR?  (Surely, that’s a wasted motion.)  Whether a given scheme or set of schemes will satisfy the PAR?  That is effectively the motion to approve the draft.  I am inclined to run such a motion (to approve the D0.2 scope – with cleanup of the CC raised concerns specifically on that text).  I hesitated, when I detected that we have disagreement about the scope/meaning of the words in the PAR, as the motion to ask if we are done (by approving D0.2) is effectively a question asking if we have met the PAR scope, so we end up back in that debate.  Hence, my suggestion to clarify (with motions, as appropriate) the PAR, to remove this ambiguity/disagreement, as a first step.  I’m open to other suggestions, though, of course…

 

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.

[[MAH]] I have to jump in here, as Chair.  The TG really doesn’t have a choice but to meet the PAR.  That was our mandate from the WG.  We either accomplish that mandate, or go back to the WG saying we give up and the program should be abandoned. 

[[Graham]] Good point, no choice but to meet the PAR. 

 

BUT…  if we don’t agree on what the PAR says, then that is a different problem than asking if we must meet it.  It becomes a problem of clarifying what is required in order to meet it.  So, we’re back to my suggestion that we need to get that disagreement settled, as a first step.

 

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

 

From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Thursday, February 9, 2023 10:15 AM
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh motions, PAR, and way forward

 

Mark,

         Ah, interesting :-)

 

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.

 

Kind regards

 

Stephen

 

 

On Thu, 9 Feb 2023 at 16:49, <mark.hamilton2152@xxxxxxxxx> wrote:

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

 

From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Thursday, February 9, 2023 6:45 AM
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh motions, PAR, and way forward

 

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).

 

Kind regards

 

Stephen

 

On Wed, 8 Feb 2023 at 20:12, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:

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.
    1. 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.
    2. I do not want the TG to get stuck waiting for this, however, I think we can continue our discussions in parallel. 
    3. 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).
  1. 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:
    1. 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.”
    2. 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!):

  1. 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.
  2. 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.
  3. 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