| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi All, I saw a lot of things discussion in this mail loop, I would like to share some personal opinion.
I agree what Mike M said during the call, the task group has the duty to interpretate the PAR, as Mark did in this mail loop, I’m in flavor of this. I don’t see any value to do any change in current PAR. For what? What’s the compelling story to change the PAR, just because we can’t finish the job in time, so we have to change to the PAR?
It reminds me to think about the Link recommendation feature defined by 11be draft. Actually, Link recommendation inherits the spirit of band steering feature, which the AP MLD recommends the buffered frame received link to the non-AP
MLD, and the non-AP MLD will receive the buffered data frame from that link. While the purpose of band steering is that the multi band AP recommends the STA to get the service from other band. Therefore, the story is almost the same. If we can’t support band
steering use case in 11bh group, can we encourage 11be group remove Link recommendation feature as well?
Generally, I don’t believe Wi-Fi industry will accept a dirty solution, 11bi group must repair that solution if we want Wi-Fi industry adopt it indeed. On the other hand, 11bi Chair also suggest 11bh group complete their feature
design independently. And thus I call for group member drop such thought, and encourage this group have a completed solution, as least provide the same security level as Device ID has.
I guess we have to run a motion like “Do you think 11bh group can go the letter bullet based on 11bh draft0.2” sooner or later. If it can get the majority support, everything is over. For the proposal to run other motion, I see the benefit is only to identify some group members who vote N. If we can add a note to say the members who vote N should provide some direction so that this group can jump from cycle, it’s
worth to have a try. As you know, 11bh group is quite small group, if some group member are always voting N without any reason, there is no way to get 75% support. From this perspective, just waste a motion, IMHO. Anyway, hope we can have a clear target on
this proposal first. Thanks Best Regards Jay Yang From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> 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>
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. [[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>
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 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 |