| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Jerome,
On 9/4/23, 12:38 PM, "Jerome Henry" <jhenry@xxxxxxxx> wrote:
Reading this fascinating thread (laboriously of course, as it is Labor day here), and I would like to make sure I understand these ideas of state and transactional exchange. They seem to be two different concepts, here and in 11aq 12.2.10. Separating them might help, as the former seems to taint what the latter may or may not mean.
Transactional exchange, in the thread below, is said to be an exchange that creates a state on both sides. This seems to go beyond the strict definition of a transaction (which, outside of 802.11, is merely an exchange or transfer of goods, service, or funds -> in our case this could translate as an exchange of information).
I think I was overstating the case. If you read 12.2.10 it says, "the non-AP STA shall not change its MAC address during a transactional exchange, for example, transmitting Public Action frames for preassociation discovery, or during the creation of state on an AP using preassociation capabilities…." So we're talking about 2 situations that I was conflating.
Let's just level set and say that once 802.11 authentication happens the MAC is fixed (which is also part of my presentation). Agree?
[j] yes 100%.
Assuming yes, then what 12.2.10 is talking about is when it's OK to randomly change your MAC address, and that is all pre-association (and pre-802.11 authentication). So one thing that 12.2.10 says is that a STA can change his MAC address pre-association provided it's not: 1) a transactional exchange like PAD; or 2) some state generating procedure like pre-association.
[j] makes sense, 100% agree.
In 802.11aq, an example of transactional exchange (in our dear 12.2.10) is the transmission of public action frames for pre-association discovery. If I follow Mark's reasoning, the STA needs to maintain its MAC address during that exchange (and 802.11aq confirms this need), not because a state is created, but because the STA needs to know that the AP is responding to its (the STA's) query, and if the exchange continues over a ping pong, the AP also knows that it is the same STA asking follow-up questions. Mark, Dan, Jay, do you agree so far (that a transactional exchange is an exchange if information, and that this need of a stable MAC during the exchange exists, at least for the reason stated in this paragraph)?
Yes, that would be #1 above. Some exchange in which the AP has to keep track of who sent something so a coherent response can be generated. The STA needs to retain the MAC in order to complete this transactional exchange.
Does this exchange also create a state? This is where the thread seems to time-warp. One element that is not clear to me (although Dan provides clear view) is whether the state exists on both sides or only one side. 12.2.10 does mention "during the creation of state on an AP", but also "state created with an AP". The second instance seems to allude to the idea that the state is common ('with'), but the first one allows the AP to be the only one to have a state for a STA ('on'). The natural reading Dan draws is then "If the AP creates state the STA has no idea about (or vice versa) then this has nothing to do with the subject at hand". This is the part I would like to understand better. Following the thread example, if a STA sends a (pre-association) ANQP request to an AP, the STA might know that the AP records that MAC a.b.c asks question XYZ. While the AP fetches the answer from a SIR or an advertisement server, it (the AP) keeps track of that mapping between the requesting MAC and the question.
Is this a state on the AP? My uninformed mind seems to want to answer 'yes'.
Is the STA aware of that state? Probably, as the STA wants to maintain the current MAC until it gets the answer it wants (or times out).
Again, I'm sorry for conflating these two cases. Some kind of PAD exchange is a case where a STA cannot change its MAC address. This is a transactional exchange. But there isn't really any useful state created by the AP upon conclusion of this transactional exchange. Once its over the STA is back to steady state and there's nothing it has that it would need to refer to in the future using some specific MAC address. So it is my feeling that 12.2.10 is prohibiting a MAC change while there's a transactional exchange going on but once it's concluded then the STA is back to his normal pre-association (and pre-802.11 authentication) procedures and can use any MAC he wants from the local address space.
[j] this helps a lot, reading this and 12.2.10, I have the same understanding too.
There's also the 2nd part of 12.2.10. It says that if there's some state created on the AP that the STA wants to refer to in the future, then it has to change its MAC back to what it was when the state was created. If there's no state on the AP that the STA cares about referring to in the future then 12.2.10 doesn't apply. So if I'm a STA and I probe the AP, I don't know if the AP is keeping track of who probes it or doing any sort of band steering, I just probed. There is no state on the AP that I care about and no reason to revert back to some AP I used when probing earlier. But if I do pre-auth and generate some state on an AP then when I get around to associating to it I need to revert back to the MAC I used when doing pre-auth.
[j] This is a crucial point we may want to exchange more about, as you were in 802.11aq and all I have is 12.2.10. The text seems to avoid the idea of the STA intent. It seems to say that if there is a state on the AP, and the STA decides to associate (or establish a transaction state, whatever that means), then the STA shall go back to the MAC it used when the state was established. That the state is useful for the STA alone, or only for the AP (or both) does not seem to make a difference?
So does this exchange also create a state on the STA? It seems to be the case (again, to my mind).
Is this a state we care about? This is where Dan seems to answer 'no' (please correct me if I am mistaken), unless "it is something that the STA wants to refer to later on. If the AP creates state that the STA does not care about or know about then it's not relevant. But if this state is some state that the STA knows, definitively, that the AP has created and that it is useful to the STA at a later time, well then 12.2.10 applies."
So it seems that Dan's conclusion is that, if the state is not useful to the STA beyond the transactional exchange, it may be a 'state', but not the 'state' as 12.2.10 intends it, and thus not one we care about. Do I read this idea correctly?
Yes, that is my read as well.
If the answer is 'yes', then it seems that we only consider the benefits of the STA, and not of the AP (or the infrastructure). This approach makes sense in a public venue, but just like a STA can be attacked, an infrastructure can be attacked. It seems to me that in private settings, like an enterprise network, the infrastructure has value on its own (beyond being at the service of any STA, known or unknown). For example, with a random scenario, if in the middle of the night an unknown MAC asks an AP in a small business building if there is a printer behind the AP (ipp), 'before RCM', the AP could check who is asking (e.g., if you are a known device MAC in the Insurance Company database, I answer, otherwise not). Is this a scenario we want to be able to maintain? Or do we say that PAD should be thrown away?
I'm not really sure that's in 11bh's bailiwick. It might be more 11bi. It's certainly not one of our use cases we've been working on.
[j] Not sure either where this belongs. For now, we have stopped answering and STAs don't discover services anymore if they use RCM. My concern is not so much the privacy of the network (and its assets), but that 'before RCM', there was a simple procedure, 'after RCM', this is broken. Maybe this falls into the pre-association steering and troubleshooting bucket, not sure. I am definitely moving beyond the scope of this thread here.
This idea of relevant state (for the sole benefit of the STA) also seems to have consequences for troubleshooting. 'Before RCM', a STA with a stable MAC from probe to association could be followed, along with its failures. So we could say 'we see your MAC sending ANQP request for IPv6 support, the infra responds 'no', you associate then the STA stays there with no active traffic. Looks like your client needs Ipv6 support'. 12.2.10 'seems to want to stick to this general', when it suggests that for association the STA should turn back to the MAC it used when the state was created (if it was created pre-association). But with the direction we are taking here, this logic stops. Is it the direction we want?
I'm not sure I follow you here. The STA will be reverting its MAC back only to refer to state on the AP that was created by some state-generating procedure. If the STA does not wish to refer to any state it had previously generated under a particular MAC address it is under no obligation to use that MAC address again in a subsequent connection attempt.
[j] fully agree with your reading. I am going beyond the thread context here, to also suggest that 1] there is value for a single MAC from before to post-association, because there are actions that the STA takes before association that are not merely the STA being curious about the world around itself, but the STA intending to undergo a series of actions. A STA running PAD exchanges would do so to decide which BSS to join (so the STA can used the key services it seeks). But in the reverse direction, the AP may need to keep track of this sequence, for troubleshooting purposes or simply to avoid steering the STA post association to a band where the same service is not available. But also 2] that there is value for the STA to be track-able (should the STA wish so) between associations (again, beyond this thread context).
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Jerome
---- On Mon, 04 Sep 2023 11:59:06 -0400 Harkins, Dan <daniel.harkins@xxxxxxx> wrote ---
Jay,
You said, "probe request/response between STA1/AP2 is another transactional exchange." What do you mean "transactional exchange"?
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 9/4/23, 12:08 AM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
Could you refrain from attacking me? Or Is it your hobby to attack someone if you can't convince them from technical perspective? Could we just focus on the technical debate in IEEE group, OK?
Please look at the words your made: "The only reason to bring it up would be to confuse the group. Is that what you're trying to do?","I don't think you understand how 802.11 works."
I'm hesitating whether I can have some further technical comments, and then get the further personal attack from you.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
T: +86 15021324431
Original
From: Harkins ,Dan <daniel.harkins@xxxxxxx>
Date: 2023年09月04日 14:03
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Jay,
On 9/3/23, 7:09 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
Before I answer your questions, I would like to know what's the term of "transactional exchange" . In order to get the answer, I have to go through many 11aq contributions.
Lucky, such term appreas in https://mentor.ieee.org/802.11/dcn/17/11-17-0521-03-00aq-privacy-enhancements.docx for the first time. And It's your submission 6 years ago .
In this submission, there is a standalone paragragh said "
A non-AP STA shall refrain from MAC randomization during transactional exchanges, for example transmitting public action frames for pre-association discovery.
"
It's a general description, and there is no context to say anything about state created.
Well that's what it is. A transactional exchange involves giving something and getting something—it's a transaction—and the things exchanged in this transaction result in shared state—here's the STA nonce, here's the peer's nonce, and now they both have each other's nonce. The important thing is that this state is something that the STA wants to refer to later on. If the AP creates state that the STA does not care about or know about then it's not relevant. But if this state is some state that the STA knows, definitively, that the AP has created and that it is useful to the STA at a later time, well then 12.2.10 applies.
But now, you persist to say "If there's no state created then it's not a transactional exchange" in this mail loop.
I persist? What are you talking about? I have made a statement. And is the fact that I am not renouncing it causing you some grief?
I feel some confused on the two views of the same thing from one expert.
I'm sorry that you are not able to parse words to your satisfaction. Or is it that you are hoping to parse words in the most ambiguous manner possible?
What is the confusion? You have found a single submission using this term. What are the "two views"?
It's appreciated if you can explain the term of "transactional exchange" as it's invented by you.
I've said it repeatedly. Look at 12.2.10. It talks about state being created on BOTH sides of the conversation and the STA adjusting its MAC address in order to refer to that state at a later time. Why would anything else apply? If the AP creates state the STA has no idea about (or vice versa) then this has nothing to do with the subject at hand. The only reason to bring it up would be to confuse the group. Is that what you're trying to do?
Re-read this email thread.
For the de-auth case, we share the same position. As it's a conversation, I don't add (except auth/de-auth frame ) when refer to Class 1 frame in every place, but you expected such. Applogized for making you feel confused.
"I don't add when refer to Class 1 frame in every place, but you expected such." I'm sorry, I don't understand what that is supposed to mean.
Let us all note that you still have not answered my question. So that makes three times I've asked you and you've not answered. Care to?
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
T: +86 15021324431
Original
From: Harkins ,Dan <daniel.harkins@xxxxxxx>
Date: 2023年09月03日 01:28
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Jay,
On 9/2/23, 5:45 AM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
Hope you fully undertand what I am talking before you say NO! NO! NO!
I've never said "Deauth from a random MAC address", why you assume such, and then get the conclusion "I don't think you understand how 802.11 works." My God !
You're right I don't fully understand what you're talking about.
In a previous email you said, "while probe request/response between STA1/AP2 is another transactional exchange." But down below you say, "In my mind, Class 1 frame (except auth/de-auth frame) exchange don't create new state on both side." If they don't create state then they're not transactional . So what is it?
Then you say, "But for Class 1 frame exchange, the STA can use any RMC to do frame exchange with AP, who cares.." and "the STA have to use the same MAC address when probe or send other Class 1 frame to the AP each time, which will bring a lot of privacy concern". You know what a Deauth is? It's a class 1 frame. So can the STA use any MAC address to send this class 1 frame? No, it can't, it has to use the same MAC address it used when it entered state 2. To me, the critical nature is what state the state machine is in, not what class of frame is being sent. But to you…well, I'm not sure.
So yes, I will admit I don't understand what you're talking about because you seem to say contradictory things.
If there's no state created then it's not a transactional exchange. Please explain what's the state created when the STA transmits Public Action frames for preassociation discovery.
To further add confusion to your email you seem to be quoting me without using quotes. Is "If there's no state created then it's not a transactional exchange" a statement you're making or is it a quote of mine? If the former then, again, you're contradicting yourself, if the latter then you're unnecessarily adding confusion to an email so don't get upset when people then don't understand you.
Regarding your question, I've asked you a question twice and you never answered. So maybe you answer me first, OK?
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
T: +86 15021324431
Original
From: Harkins ,Dan <daniel.harkins@xxxxxxx>
Date: 2023年09月02日 13:59
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Jay,
On 9/1/23, 5:29 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
I fail to understand what your said "The transactional exchange generates shared state" . There is nothing with the state(or new stated created).
I'm sorry but what do you think a PMKSA is?
I agree what Mark said, "transactional exchange like a set of related tasks that form a logical unit of work" . For me, it looks like a serial of frame exchanges between two sides.
That definition encompasses almost everything and is therefore useless. A transaction involves giving and getting. "a serial of frame exchanges between two sides"? What? I don't even understand what that means.
See following highlight sentence, before the STA associated/or authenticate with a BSS , both side stay in state 1.
They can do some transactional exchange, like Public action frame exchange without created a new state. But during the frame exchange period, the STA can't change it's MAC address.
What is this "public action frame exchange"? If it doesn't create state then what sort of transaction has occurred? You're making these weird statements, "frame exchange period", what is that? What does that have to do with anything?
e.g. STA sends a ANQP request frame with MAC1, STA must use MAC1 to recevie ANQP response frame, as the whole procedure belong to a "transactional exchange"
And the STA can repeat the same procedure in another transactional exchange with a new MAC address, which will be aligned with the first cited sentence.
Otherwise, there's no corelation between the following two sentences.
"The STA shall periodically change its MAC address to a random value while not associated to a BSS . The STA
shall construct the randomized MAC address from the locally administered address space as defined in
IEEE Std 802-2014 and IEEE Std 802c™-2017. However, the non-AP STA shall not change its MAC address
during a transactional exchange, for example, transmitting Public Action frames for preassociation discovery"
What is your point?
Another question, what's the state of a STA and an AP duing probing or other Class 1 frames frame exchange? In my mind, Class 1 frame (except auth/de-auth frame) exchange don't create new state on both side, the STA and AP will stay the state where it was after Class 1 frame exchange. If there is some state change on both side, the STA should use the same MAC address when the state was created. As state 1 is a default state, it should be a exception case when we talk state created.
If there's no state created then it's not a transactional exchange. I guess you will be voting "yes" on straw poll #1 from my submission.
E.g., when the AP and STA stay in state 2 (authenticated), the STA shall use the same MAC address when send a De-authention frame or association request fame, as the two frames will cause the state change.But for Class 1 frame exchange, the STA can use any RMC to do frame exchange with AP, who cares..
No! Not if it's in state 2. If it's in state 2 the frames it sends are bound to the MAC address used to enter state 2.
In the contrary, if you assume the STA must use the same MAC address when send a frame to the AP in state2. e.g. in some cases, the STA never go to state3 and state4. the STA have to use the same MAC address when probe or send other Class 1 frame to the AP each time, which will bring a lot of privacy concern.
I don't think you understand how 802.11 works.
The STA must use the MAC address it used to establish state on the AP. A Deauth frame is a class 1 frame. If it sends a Deauth frame to an AP it has to use the MAC address it used when it established the authentication state on the AP otherwise the AP has no idea what this Deauth refers to. Deauth from a random MAC address? What is the AP supposed to do with that? The requirement to use a particular MAC address is not based on the frame class, it's based on the whether there is state that the frame refers to. 802.11 authentication establishes state on the AP. If the STA wants to send a Deauth frame and destroy that state on the AP it MUST send the Deauth frame from the MAC address it used to create it. You seem to think that if it's a class 1 frame then the STA can use any random address. That's not how it works.
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
T: +86 15021324431
Original
From: Harkins ,Dan <daniel.harkins@xxxxxxx>
Date: 2023年09月02日 04:52
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Mark,
On 9/1/23, 11:20 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:
Dan, below. Mark
From: Harkins , Dan <daniel.harkins@xxxxxxx>
Sent: Friday, September 1, 2023 11:55 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Mark,
On 9/1/23, 10:25 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:
Dan/Jay/all,
I might be missing some of what Jay is trying to point out – please respond if there is more, Jay.
But, I have a couple comments, if I can jump into this thread:
1. @Harkins , Dan: Jay pointed out below what I think is just a typo: The frames are called “Beacon Request” and “Beacon Report”. There is no “Beacon Report Request” – I think you meant just “Beacon Request”.
Thank you, yes.
2. Dan asks below: >>> “When STA1 sends a probe request to AP2 what shared state is it creating?”
1. I would respond: The state is that STA1 is able to hear both AP1 and AP2, and some information about the link quality between STA1 and each of those APs . This state information can be gathered by both the AP and the STA, during a Beacon report scanning (probing). The STA will report the information in the actual Beacon Report. The APs may also create their own state information based on the reception of the Probe Requests, but that only works if the APs can identify the Probe Request(s) that are from STA1.
That's not shared state. Gathering information about RF conditions through probing or scanning or whatever may create state on the STA doing the probing and scanning but the AP doesn't create the same state and bind the STAs MAC address to it.
[[MAH ]] Dan, nothing in the 11aq text says that the state has to be “shared”. It’s just “state on an AP” and “state bound to a MAC address”, and both of those apply here.
I think you're just parsing words here. What is the point of creating state bound to a MAC address on an AP? Why would a STA "configure its MAC address according to the rules of the local address space prior to the start of the transaction" if it didn't have any knowledge of the state or share the state? How would it use that state? It doesn't even know whether it is generated or not! That can't be transactional .
There's a reason this text exists. The reason is to allow a STA to access state on an AP that it created earlier. If it doesn't know that state was created in the first place or know anything about what that state looks like then there's no point in applying this section. Is it "state on an AP"? Yea, I guess. Is it "state bound to a MAC address"? Well, that depends on what the AP is doing with that state, we don't know and neither does the STA. But is it usable by the STA at some future time such that it would want to change its MAC address back to use it? Absolutely not. It has nothing to do with 12.2.10.
When the state is shared it becomes useful for the STA. It does a transactional exchange that results in state being created on the AP. The STA knows about this state and what it can be used for. That is the sharing.
(I know that the 12.2.10 text ended up getting massaged during the RAC wars after sponsor ballot, so there are lots of fingerprints in it, but the original text was mine. The intent was to indicate to STAs that if they create state on an AP and want to use it in the future they have to return back to the MAC address they used when it was created. That's the whole point).
For the purposes of band steering an AP may create state regarding who it is that's probing the AP in an effort to not answer if the desire is to steer the STA to another band but that is not state that the STA even knows is being created nor is it state that the STA can refer to later with a particular MAC address. But in general I don't believe APs fill up memory with "I got probed by MAC-X" state because they get probed a lot.
[[MAH ]] I agree with you here, although I’ll note that some APs do keep some of this in memory (with a quick FIFO flush). However, in this case were talking about an AP that does a specific Beacon Requests, so it is likely to store the state for these responses (at least long enough to make a roaming recommendation decision), but of course only if it can correlate the Probe Requests.
AP1 did the beacon request. That is to an associated STA. The question is, when the STA goes off and probes AP2 is it accessing any state that was created with the MAC address used while associated to AP1? No. The probing is not transactional . It gathers information, sure. The STA gets some environmental information it can send back to AP1 but AP2 does not need to be aware of this and the STA does not have to use the MAC that is associated to AP1 in order to probe to AP2. The probing is not transactional . If you think it is, then what would the STA do in the future with AP2 using whatever state you think AP2 created as a result of that probe? What would compel the STA to use a particular MAC address when interacting with AP2?
When talking about these transactional exchanges, they are things that create the same stuff on both the STA and AP. Think of SAE . Or FILS . Pre-auth is another example of creating shared state between a STA and and AP that can be referred to later by using the MAC bound to that state. Just gathering some requested environmental data is not a transactional exchange because there's really no transaction made when gathering said data. Probe request, probe response. End of exchange. No transaction, no state retained. There is nothing the STA expects the AP to have that it would use on a future connection. But with SAE there is. There is an exchange of 802.11 authentication frames and the end result should be a PMKSA on both the STA and AP. When the STA wants to use that state to association it must revert back to the MAC address it used to create that PMKSA . A STA could do SAE with AP1 using MAC1, do SAE with AP2 using MAC2, and SAE with AP3 using MAC3. Now it has shared state, each bound to a unique MAC address, on 3 APs in the ESS . If it later wants to go associate with AP2 it will change its MAC address to MAC2 and associate. But a probe? No, there's no shared state bound to a MAC address that the STA will want to refer to later. It's not a transactional exchange.
[[MAH ]] SAE , FILS , pre-auth, etc. are all great examples, I agree. But, I disagree in your claim that Beacon Request is not also an example. First, “transaction” (transactional exchange) to me, is defined something like “a set of related tasks that form a logical unit of work”. In the case of a Beacon Request, all the Probe Requests and the information gleaned from them, is combined into a set of data for decision-making. To me, those all become one transaction as a result. (And, again, per above, there is nothing that says this state has to be shared, so how/whether the STA expects the AP to have this state is not relevant.)
I'm getting dizzy jumping from the minutiae of specific words to the 10000' view of what's going on…. AP1 is asking the STA to go do some work for it. Is that a "transaction"? Who cares. It's not relevant to the 12.2.10 text. It's a semantic argument which I do not wish to have. The point I'm trying to make here and in my submission is that when the STA goes off and starts to act on that request, the probes it does are not transactional per 12.2.10 and do not create state which would cause the 12.2.10 rules to apply. Yes the STA is gathering data. Yes it's going to send that data back to AP1. AP2 doesn't care. And if AP2 created any state as a result of this probing—no one knows, including the STA—then the STA will have no use of it in the future so 12.2.10 doesn't apply.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Mark
From: Harkins , Dan <daniel.harkins@xxxxxxx>
Sent: Friday, September 1, 2023 10:24 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Jay,
On 8/31/23, 11:26 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
The state created on the AP and STA is per-AP level, not per-BSS . After the STA associated with the AP(AP1),the STA can send Class1/2/3 frame to AP1. But the STA is only allowed to send Class 1 frame to the second AP(AP2). e.g. the STA can't send Class 3 frame, like Data frame, to AP2. Obviously, the STA is in the state 1 from AP2 perspective.
So? I don't understand what point you're making here. Yes, the state governs what frames can be sent. And….
When we talk "transactional exchange", i guess there is a precondition to say the transactional exchange shall be between one entity peer, like AP1 and STA1 is an entity peer, while STA1 and AP2 is the another entity peer. If so, beacon request/report between AP1/STA1 is a transactional exchange, while probe request/response between STA1/AP2 is another transactional exchange. It looks like one transactional exchange insert into the procedure of another transactional exchange. Maybe I'm totally wrong as 11aq doesn't describe this part very clear.
The transactional exchange generates shared state. If there is no shared state created then it's not a transactional exchange—"starts any transaction that establishes state bound to a MAC".
Let me ask my question below again. When STA1 sends a probe request to AP2 what shared state is it creating? Or is it using some state it created due to the fact that its associated with AP1? If so how?
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
T: +86 15021324431
Original
From: Harkins ,Dan <daniel.harkins@xxxxxxx>
To: 杨志杰10343608;STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>;
Date: 2023年09月01日 11:02
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Jay,
The question is, does the STA doing the probing require the use of any state it had created on an AP in the ESS to perform its activities? If so then what is that state?
Is this a transactional exchange or not? The fact that there might be 4 types of frame exchanges does not affect the answer. So? What's the answer? You don't need to wait until Tuesday, you can answer now.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 8/31/23, 6:28 PM, "Jay Yang" <yang.zhijie@ZTE .COM.CN> wrote:
Hi Dan,
I have a quick look at your contribution. I've some hard time to understand the question "Is a probe made in response to a Beacon Report Request a transactional exchange? ". There are 4 type of frames exchange in this procedure: Beacon request, Beacon report, probe request and probe response. Beacon report is the response to the Beacon request. So not sure what's the meaning "Beacon Report Request" here.
Anyway, I'm happy to discuss more with you next Tues.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
T: +86 15021324431
Original
From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>
Date: 2023年09月01日 03:59
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Thanks, Dan. I’ve added it.
Mark
From: Harkins , Dan <daniel.harkins@xxxxxxx>
Sent: Thursday, August 31, 2023 12:41 PM
To : Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: 11-23/1453r0
Hi Mark,
I've uploaded document 11-23/1453r0 to mentor. Can you put me on the agenda for the next teleconference on 5 September please?
thanks and regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
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
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
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
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