| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi, Graham, Thanks for the detailed thoughts. Some responses, below. Mark From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> 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. 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. 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. 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> 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> 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:
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 |