Thanks, Javier.
My thoughts/comments, below.
Mark
From: Javier Contreras (jacontre) <0000271029dd1f91-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 13, 2023 3:58 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Duplicate IRM
Hi
>“If the new IRM is already in use within the network, or identical to a most recently received IRM for another non-AP STA”
From troubleshooting scenarios, it is interesting to be able to correlate a STA changing between SSIDs belonging to the same network as administrative entity. This “wlan change” can cause problems and it is common source of client deletion problems (triggers can be AP or STA, not going into details there)
That said, that is a stretch goal, and I think this correlation is outside the scope, as it may need upper layer authentication links to the STA attributes
This opens couple of problems:
- Client should not use device ID across different ESS. As network, I would not expect client to leak information between different SSID names, and it should not be a burden put into clients to decide if they keep device ID or not, even if network “owns” two ESS, and present the same device ID for both of them
Client should not reject getting same device ID from two ESS (which should not be a problem as per what I recall in the draft), it falls into network side to decide how to arrive to that correlation
[[MAH]] Since device ID is chosen by the network, and given to the non-AP STA, and the non-AP STA is responsible for maintaining a mapping/list of its assigned device ID per network, I’m not seeing that there is anything actionable here (within our scope). I think I agree that the scenario described is a possible usage scenario, that can be arranged if the network administrator wants to do so (for troubleshooting reasons, or whatever). Javier, if you think there is any action/change to be made, please clarify.
- I would need to check, on the IRM usage points, but there could be several scenarios where IRM is presented before auth of the STA has been fully completed (even if it is possible)
as such, the infrastructure does not have possibility of validating the IRM properly, or confirm If it is a duplicate, or the same STA roaming across ESS
[[MAH]] To clarify, there are many scenarios where an IRM is put into use before authentication. However, the IRM “handshake” is that a “next IRM I will use” is provided during a given association (and therefore post authentication), which will be used at some point in the future (likely/possibly pre-authentication). So, the validation, duplicate detection, etc. is done while the non-AP STA is authenticated (and associated). As for anything to do with identification across multiple ESSs (note, similar/in parallel to the above) is beyond our scope, and is entirely a usage question. In the case of IRM (as opposed to the above), this is a non-AP STA decision, and it/its implementation can decide when it is or is not appropriate to share its IRM identification across ESSs.
Beyond just our discussion here, to help with clarification (and confirm our thinking is aligned), again I don’t see that there is a problem identified here.
On this scenario, I would put the requirement that a given STA, must not use the same IRM across different ESS (using lay terms, SSIDs names, or WLANs, etc), leaving open the possibility that if the network infra sees the same IRM tried to be used across two ESS, that should be handled as collision, and the last one rejected (although this probably falls outside the scope of this discussion, just mentioning as possible implementation detail)
[[MAH]] Similar to just above (and agreeing with the last parenthetical comment here), any behavior across ESSs is outside our scope. We have no requirement authority to impose such a restriction.
regards
Hi Graham,
Thanks for set-up the mail thread.
There is no clear definition about the term of "network" in 802.11 draft, but it's also widely used in many place. If we read the following citied paragraph, it indicates a network may contain multiple ESSs , while our original agreement is that the 11bh identifier can be recognized by any AP in the same ESS . And thus I think we can't use "network" if we don't plan to use the 11bh identifier across different ESSs .
4.5.3.2 Mobility types
The three transition types of significance to this standard that describe the mobility of (M12)non-GLK STAs within a network are as follows:
a) No-transition: In this type, two subclasses that are usually indistinguishable are identified:
1) Static—no motion.
2) Local movement—movement within the PHY range of the communicating STAs , i.e.,
movement within a basic service area (BSA).
b) BSS -transition: This type is defined as a STA movement from one BSS in one ESS to another BSS
within the same ESS . A fast BSS transition is a BSS transition that establishes the state necessary for
data connectivity before the reassociation rather than after the reassociation .
c) ESS -transition: This type is defined as STA movement from a BSS in one ESS to a BSS in a
different ESS . This case is supported only in the sense that the STA might move. Maintenance of
Original
Subject: [STDS-802-11-TGBH] Duplicate IRM
Following today’s meeting I have amended and uploaded 23/1392r4 with the changes discussed, adding robust action frames and PASN Class 1a.
Please see the updated version here:
https://mentor.ieee.org/802.11/dcn/23/11-23-1392-04-00bh-cid-7-21-114-resolutions-for-duplicate-irm.docx
Hopefully the remaining work is only to decide on an alternative term for “network” in the sentence.
“If the new IRM is already in use within the network, or identical to a most recently received IRM for another non-AP STA, then, after association or authentication using PASN , the AP may send an IRM Duplicate Action frame (see 9.6.aa.2) to the non-AP STA indicating to the STA that the provided IRM is a duplicate.”
Comments and suggestions please.
To kick it off, how about “WLAN ”? (term defined in clause 4.2?)
Graham
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