| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Yanjun,
I don't think threats are needed.
Your point about ACKs is not really relevant. The retransmission is taking place at a much higher layer. ACKs are basically PHY-level. The protocol we're discussing is upper MAC. Think of it as kernel space versus user space. The user space app does not really have access to the bowels of the kernel. So the app implementing the PQC protocol is not going to know whether a particular frame was ACK'd or not. So I maintain that your concern about initiated retransmissions is misplaced.
Your other point about the Key Query is moot because that was removed.
So I believe all of your concerns have been addressed without need to change the document. If you think the document needs changing I would appreciate some change text to implement what you think needs changing.
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 11/12/25, 6:04 PM, "Yanjun Sun" <yanjunsunstd@xxxxxxxxx> wrote:
Hi Dan, Mike,
Please see our past email exchange below. I also mentioned this verbally to you multiple times.
Btw, if someone else were to say the dirty words like what I got during the meeting today, he would get a punch in his face immediately. I tolerate the first one for business conduct, but not the second one.
Best,
Yanjun
On Fri, Sep 19, 2025 at 5:36 AM Yanjun Sun <yanjunsunstd@xxxxxxxxx> wrote:
Hi Dan,
Thank you for the prompt response. Please see follow-up comments inline.
On Sep 18, 2025, at 11:15 AM, Harkins, Dan <daniel.harkins@xxxxxxx> wrote:
Hi Yanjun,
On 9/18/25, 2:03 PM, "Yanjun Sun" <yanjunsunstd@xxxxxxxxx> wrote:
Hi Dan,
Thank you for r2. I’ve reviewed it and please see some early feedbacks inline.
1. The following format will create two ways of retransmitting a lost fragment: either a retransmission initiated by the transmitter itself or a retransmission solicited by the receiver. I raised this question on Monday and had offline discussions with a few folks to hear the rationale. However, I still don’t think that I’ve got a compelling reason for such redundancy. So my suggestion to to defer this aspect for now so that I can check with my colleagues.
· “The Requested MMPDU Fragment field indicates a request for an MMPDU fragment carried in an Authentication frame to be retransmitted.”
I do not believe that the transmitter initiates a retransmission. The receiver will realize that a fragment is missing—e.g. receives 0, 1, 3, notices 2 is missing—and ask for it to be retransmitted. The transmitter will then do the retransmission. But the transmitter will not gratuitously initiate retransmissions.
[YS]: as every authentication frame is either ACKed or receives an Ack timeout, a transmitter is in a good position to handle retransmissions and can simplify implementation. If we allow retransmission to be solicited also by the receiver, we’re creating two possible ways handle retransmissions and it can make the spec more complex and introduce more corner cases in actual implementations.
2. For Key Query, can you explicitly call it out why it’s needed and which AKM depends on this? You had a high-level answer on Monday is that it’s needed for all the schemes, but my understanding is that it’s not needed at least for 1X or 11bi based approach. Some clarification on the scope would help a reader like me.
It's only for the PAKE. And it will go away if the group wants to do identifier privacy in the manner that 11bi does.
[YS]: thank you for the clarification. To clarify, are you suggesting that “this Key Query procedure is not needed if the group wants to do identifier privacy in the manner that 11bi does”? If so, I would prefer to bring back this part afterl the group is clearer about the direction/scope.
3. The followings are some next level questions I got after going through r2:
· “All fragments except the last shall be the same size”: why do we need such shall rule? Is the intention to say that for all the Authentication frames in a transaction, only the last Authentication frame can have a different size? I chat with Mike and Jouni and they sounded open to give us more time to digest this part.
To compel efficiency. There is really no reason to send less than the max in a fragment, otherwise we will have more fragments than necessary. So each fragment is the max except the last one which contains all the cleanup octets.
[YS]: If link condition is good, I totally agree with you. If link condition is unstable (e.g., edge STA), I’m not sure at the moment, which is why I need more time to check with my colleagues.
· Does the PQC Key element contains one or more keys? The current text below can be interpreted in both ways. Please help clarify.
o “This element contains public keys for key establishment… ...The Length of Public Key indicates the length in octets of the public key that follows. Some KEM public keys can be too large to fit in a single element and in many cases too large to fit in a single frame. Therefore, these elements will necessarily require fragmentation and reassembly. “
It just contains one key. The sentence can be rewritten as "This element contains a public key used for key establishment….”
[YS]: Thanks. This is clear for me 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 Sep 18, 2025, at 8:11 AM, Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Yan,
I'm surprised you say you "have not received enough feedback from [me]." You have not received *any* feedback from me. And that is because I have not received any technical issues from you. I don't know what your "concern" is and I don't have any way to divine what is said in any "offline discussion with other members".
The only thing I have heard is that it would be a disaster if you were forced to read every submission in every TG. But that is not being requested of you.
Unless you can articulate your concern or put the discussions you have been having in writing there is no way to provide you with the feedback you seem to expect.
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/18/25, 10:56 AM, "li.yan16@xxxxxxxxxx" <li.yan16@xxxxxxxxxx> wrote:
Hi Dan,
I'm really happy that you becomes gentle to discuss more instead of kind of mean or aggressive.
Basically my colleagues have pointed out some technical issue and we also receive some concern during offline discussion with other members. But unfortunately, we have not received enough feedback from you.
I'd like to participate in our meeting and share my opinion with other members.
See you later!
Best Regards！
Yan Li
Original
From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2025年09月19日 00:54
Subject: Re: [STDS-802-11-TGBT] 1592r1
Yan,
You say you have "concern" over my document. Well, what is it? You're just complaining that you don't have time to read every submission from every TG (which is not what I'm asking of you). If you have some issue with my document I'd like you to tell me what it is. Then we can address your concern. Telling me it will be a disaster if you have to read all submissions is not a "concern" of my document.
I'm not trying to close anyone's mouth. I'm trying to get this group going. We're on a very tight timeline due to external pressures and requirements.
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/18/25, 6:06 AM, "Yan Li" <li.yan16@xxxxxxxxxx> wrote:
Hi Dan,
Please take it easy that every member could provide individual opinion on this topic. No one could instruct other members to do anything. IEEE is open for members to shared their idea. If you do not like it, please do what you like instead of closing other's mouth
See my response inline
Best Regards！
Yan Li
Original
From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2025年09月18日 17:03
Subject: Re: [STDS-802-11-TGBT] 1592r1
Hi Yang,
On 9/17/25, 11:52 PM, "li.yan16@xxxxxxxxxx" <li.yan16@xxxxxxxxxx> wrote:
Hi Alex, Dan and other members,
Firstly, i really appreciate your efforts in TGbt group.
Well gee, thank you.
Basically i have same concern as Alex '
I find one note quite unexpected in the second paragraph of your e-mail: “the technical content has not changed in 9 months or so”. In line with this note, there is a follow-up in the third paragraph “We've had 9 months to look at this stuff, that's plenty.”.
If that is the case I must have missed the initial submission. I thought this submission was first uploaded to mentor in the PQC SG area with DCN 1108 on the 7th of July and, as SG meeting minutes show, presented as 1108r2 on the 30th of July during the Madrid Plenary. Just for my reference, so I don’t miss things in the future, can you please point me to the document which had this technical content ~9 months ago?
I would also note that my first feedback, albeit not broadcast on the reflector, was sent to you on the 23rd of July. I then followed up on the important points during the SG meeting at the end of July, again as shown by the meeting minutes.'
I would like to share my understanding on this part:
Your technical content is provided as a proposal long long ago, during that phase, what we could do is just to check your opinion and direction in your proposal. No one would like to check all details in every proposal;otherwise, it will become a disaster.
Yes, my technical contribution was provided a long time ago. What should you be doing except "check your opinion and direction on your proposal"? I really don't know what your issue is. You're saying that if I expect you to check the details in my proposals that it will be a disaster? Well, I'm very sorry then. But I think a disaster is in your future.
What is It that you'd like to avert this "disaster" of having to check details in proposals?
Yan: there're a lot of proposals generated everyday in the whole 802.11WG. We can not check all details among all of them. I do not think your prosposal should have more priority than others. About 'I think a disaster is in your future' ,I respect your thinking just becasue IEEE is open. If you are happy with it ,go ahead
But now you would like to request it as Draft, which is quite different thing. We should be very careful and check every paragraph even every word in the Draft. I think you should also agree on this point.
Yea, I'm asking you to check paragraphs and words. Is this too much to ask of you? Really? I don't know what to say if you think it's too much for you to actually read every word and paragraph in order to vote on it then I question why you're even voting. I kind of thought that was how this organization operated.
Yan： Sorry, i think every individual person could share thought and vote on this. I'm interested in this topic and have the right to vote on this, this is what IEEE tells us. BTW, i have explained in the discussion： we do not have sufficient discussion on your proposal and still have concern on it.
Response to your question: yes, personally i indeed need more time. However, this is your proposal and you can do anything other than closing my mouth🙂
Therefore, the time you give us is too short to complete every thing we should do for a standard draft. Please understand us and give more time
Who said there was a "standard draft"? I don't know what you're talking about. But what you're saying is that you are incapable of making a decision and require other people to instruct you on how to vote. Which is kind of sad and in opposition to how this organization works. You're supposed to be an individual who is capable of reading things and voting on them based on the technical content and who makes decisions based on what's true.
If you're incapable of participating in IEEE 802l.11 in the manner expected then don't obstruct our work.
Yan： Maybe i have some misunderstanding on definition. But bascially i think IEEE and officers would like the participation of new members and to teach them how to develop our standard. I believe in that our group is welcome to instruct new members except you, but who care, right🙂?
I have to correct you again that in IEEE every individual person is capable to make a decision and vote individually. If you do not like, you can ignore it.
You initiate the email discussion, and i share my thought. That's it.
Please keep it in mind that this is IEEE instead of your house. However, thanks again for your hark work on security. You are a special expert rather than a good teacher
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！
Yan Li
Original
From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2025年09月18日 09:12
Subject: Re: [STDS-802-11-TGBT] 1592r1
Hi Alex,
All of this "I sent you an email" and "I then followed up on the important points during the SG meeting at the end of July" is why we need to get some formal process going here. I don't dispute you sent me an email and I have received comments in person from you and others but the document you're talking about is not a formal draft.
If we were to adopt this submission as a baseline 0.1 then we could address modifications to it in November (you can write some submissions, present them, try and get consensus for their adoption) and we could probably go to internal comment collection which is a more formal process at draft improvement and consensus building, do comment resolution in January and we could then have a good chance of hitting our draft 1.0 target in the timeline we discussed. If we don't adopt this submission then I fear that everything will slip.
Sorry you don't like how much attention is being paid to the detail you are providing and feel it is unreasonable but that is due to the nature of where we are today. If you'd like that to change and have it become more formal I hope to see you speaking in favor of adopting this document as a baseline 0.1 tomorrow. It is not perfect, but it is a start and has a framework to build on. Let's start building.
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 9/17/25, 5:48 PM, "Alex Lungu" <alex.daniel.lungu@xxxxxxxxx> wrote:
Hi Dan,
Congratulations for all the awards!
Thank you for addressing some of my comments, and for the hints on how you would prefer to receive feedback. I, for one, find it trivial to search in Word documents but I understand your preference for a section/ page number and will do my best to adjust.
I find one note quite unexpected in the second paragraph of your e-mail: “the technical content has not changed in 9 months or so”. In line with this note, there is a follow-up in the third paragraph “We've had 9 months to look at this stuff, that's plenty.”.
If that is the case I must have missed the initial submission. I thought this submission was first uploaded to mentor in the PQC SG area with DCN 1108 on the 7th of July and, as SG meeting minutes show, presented as 1108r2 on the 30th of July during the Madrid Plenary. Just for my reference, so I don’t miss things in the future, can you please point me to the document which had this technical content ~9 months ago?
I would also note that my first feedback, albeit not broadcast on the reflector, was sent to you on the 23rd of July. I then followed up on the important points during the SG meeting at the end of July, again as shown by the meeting minutes.
>>> This can be cleaned up with a submission against base draft 0.1.
>>> That's a good comment and let me suggest that you vote to adopt this text as 0.1 and then make a submission to improve it!
I’m not sure I find that approach reasonable, especially as we agree that the text should be changed. I believe the effort required to address this issue today is trivial, while I find the submission/ motion process to be quite laborious.
>>> "attack surface"? If you have an attack against either I'd be interested in seeing them.
As per https://csrc.nist.gov/glossary/term/attack_surface I don’t believe there is a need to identify a successful attack to recognize that a new exchange brings with it at least 1 new entry point.
>>> There is a usage of “ephemeral private key” and the variable is called “esk”. I believe the “esk” is coming from a paper using ephemeral secret key terminology, but we should be consistent.
>>> OK.
I thought the “OK” implied that the comment was accepted, but I note r2 has the same finding.
As I had to find the feedback I sent in July, there are a couple of points which I identified then but missed this morning. Thought I’ll use the opportunity to re-raise them:
1. In the changes brought to Table 9-190 at page 9 in r2 there are 2 AKMs with cipher suite selector restriction “Used only with 00-0F-AC:9 (GCMP-256)”. I was expecting to allow CCMP as well, and restrict integrity ciphers to use a similar key space e.g. “Used only with cipher suite selector values 00-0F-AC:9 (GCMP-256), 00-0F-AC:10 (CCMP-256), 00-0F-AC:13 (BIP-CMAC-256), and 00-0F-AC:12 (BIP-GMAC-256)”. I was also expecting to see the same limitation for all AKMs. Why does the document not include BIP limitations, and why are the restrictions not applied for all AKMs?
2. There is an “OPAQUE” hit in section 12.X.4.2 Privacy Exchange and PQPAKE, at page 21 in r2. Is this an OQUAKE typo?
Regards,
Alex
On Wed, 17 Sept 2025, 09:41 Harkins, Dan, <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
OK, I have updated the document and generated 11-25/1592r2. The changes are editorial and address the editorial comments Alex provided below. There are no substantive, technical changes, the exchanges remain the same as they've been since around January of this year.
I intend on making a motion to adopt this and I really hope no one says, "well the document was just changed yesterday and I didn't have a chance to read it" because, again, the changes are entirely editorial and the technical content has not changed in 9 months or so. But now's your chance to read it if you have not done so yet.
Let me point out, again, that Alex has identified several other issues that will require a submission to describe and gather consensus to change. This is the way forward. But we need a draft 0.1 to do that. We have an aggressive timeline and we cannot afford to waste time because people feel they cannot act quickly to adopt the draft or need more time to consider it. We've had 9 months to look at this stuff, that's plenty. Let's GO!
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/17/25, 12:12 PM, "Harkins, Dan" <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Alex,
On 9/17/25, 9:30 AM, "Alex Lungu" <alex.daniel.lungu@xxxxxxxxx> wrote:
Hi Dan,
Please find below a few thoughts on 1592r1:
1. A non-AP STA that supports a higher KEM parameter set than the AP will not be able to authenticate, at least not using the opportunistic AKM. There is no provision made for the AP to advertise its supported KEM parameter set – and thus allow the non-AP STA to find the greatest common parameter set (+ MitM defence required). There is also no provision made for the AP to inform the STA it doesn’t support its requested parameter set – thus allowing the STA to decide if it is willing to try again using a lower parameter set (again + MitM defence). Now TBH I am not too worried about this issue, as I believe this is a reasonably big hole so it has to be fixed before D1.0.
I note the following quote from section 12.X.5.1: “Upon receipt of an Authentication frame with transaction sequence 1, the AP inspects the PQC Key Element. If the PQC Parameter Set is not acceptable the exchange fails”. However, I believe this issue to be common issue for most AKMs proposed, not for PMKID caching of course. Also probably not for CNSA 2.0 compliant EAP method – but I don’t see any text for that AKM?
Yes, this is an issue that needs attention. I would be happy to work with you to come up with some negotiation capability to address this.
2. FIPS 203, which is not listed as a normative reference (neither is FIPS 204), states in section 7.2 ML-KEM Encapsulation: “ML-KEM.Encaps shall not be run with an encapsulation key that has not been checked as above.”
I note that “shall not” is printed in bolded letters in NIST’s document. Amongst the checks referenced is the modulus check. Similarly, section 7.3 ML-KEM Decapsulation requires performing, amongst others, a hash check on the ciphertext. I acknowledge I only copied a subset of the section for brevity, please refer to the document for full context.
Disregarding these requirements is probably not a good idea, especially for section 12.X.5 Opportunistic KEM where the encapsulation key/ ciphertext can be easily manipulated. I suggest adding these checks to the specification as there are clear references to running these KEM algorithms in section 12.X.5.1:
"Upon receipt of an Authentication frame with transaction sequence 1, the AP inspects the PQC Key Element. If the PQC Parameter Set is not acceptable the exchange fails. Otherwise, the AP extracts the encapsulation key from the PQC Key field and generates a key and a ciphertext:
(K, c) = Kem.Encaps(pk)"
I will add FIPS 203 and FIPS 204 to the normative portion of the standard, thanks.
I agree that the checks in FIPS 203 need to be done but I was thinking that it was something for the ML-KEM implementation to handle—check before use—and not something for the higher-layer. But explicit checks can be added just to be safe. Keep in mind that the descriptions of these exchanges are not expected to be SA Ballot ready at this point. The question is, are they draft 0.1 ready? I maintain they are.
3. I am concerned GAS frames will be used for authentication exchanges, I believe Authentication frames should be used for authentication. While the text has a couple of references of exchanging encapsulation keys in a “manner outside the scope of this” specification (needed?), the description of the GAS exchange may, and probably will, lead implementations to use that GAS exchange. I fail to see why that exception has to exist: “These exchanges use Authentication frames (9.3.3.11 Authentication frame format)) to perform the key exchange, except the PQC Key Query exchange which uses GAS frames” .
Well we use data frames for authentication today so there's really nothing wrong with using GAS frames for an exchange that does not actually perform authentication, it provides a tool that can be used for authentication. We've discussed this before and I'm sorry but I disagree. But, if we were to have a base draft 0.1 then you could come up with a submission to change this and see if there is consensus to do it. That is really the way to address this disagreement. But first we need 0.1.
4. “(DNH: should c be added to the prk_pmk calculations with K?)” -> is this a question to yourself? Probably should not be included in the submission when we run the motion?
Good eye.
5. PQC Parameter Set – this sometimes refers to KEMs and sometimes to DSAs. I believe this is confusing and error prone, hence I recommend using “KEM Parameter Set” / “DSA Parameter Set” terminology.
I note the following quote from section 9.4.2.W:
PQC Parameter Set = 1: ML-KEM-512
And section 9.4.2.Z:
PQC Parameter Set = 1: ML-DSA-44
That's what they are being called in FIPS 203 (section 8) and FIPS 204 (section 4). But that change is helpful.
6. There are still references to the PQC Key Selector being present in beacons: “The AP includes a SHA256 hash of its KEM encapsulation key in the Key Selector field of a PQC Key Selector element in all beacons”. I believe there are 3 hits, but not using the same exact quote.
I will look for them. Wish you identified all of them for me but I will try and find them.
7. I find the notation in section 12.X.2.1 Signatureless Request confusing. The non-AP STA sends c1, the AP receives c1’ (unclear to me why). K1 and K1’ make sense to me, but there is no mention why the two may be different, or the chances of that ever happening. Afterwards, through HKDF, the shared secret is the same even though c1 may not be c1’(?) and K1 may not be K1’? I was expecting to see ss’, if the inputs differ?
This can be cleaned up with a submission against base draft 0.1.
8. I think the number of frames required for the PAKE exchange keeps fluctuating. I believe we started the week at “most likely” 4, we are at 6 now, I still think the ideal number would be 2 as described by section 5 of https://eprint.iacr.org/2025/231.pdf. I am confident there are solutions to establish the sid.
Solutions to establish the sid can be presented in a submission against base draft 0.1. This is a perfect example of why we need to adopt draft 0.1 this week so we can start converging. Coments like "I am confident there are solutions…." are not really helpful at this stage. But if we had a draft then the solution you are confident exists can be put into a submission for all to see.
I maintain that if we do the identity privacy solution the way it is done in 11bi that the 11bt PAKE could be 4 messages.
9. I still fail to see a need for the “no signature” and “digital signature” exchanges. My concern is that we are opening a fair amount of attack surface, and adding more may not help. These additions can also dilute the group’s ability to focus, so I would be keen to understand what is their use case.
"attack surface"? If you have an attack against either I'd be interested in seeing them.
The digital signature mode is for CNSA 2.0. The no signature mode is because the CNSA 2.0 exchange will likely be close to 2 dozen frames (or more!) being sent back and forth. There are similar "no sig" exchanges being proposed for TLS and IPsec/IKE so there is industry acknowledgment of this issue and the approach of using a trusted KEM solution to address it.
10. “for legacy, not PQC, protocol” -> I think “classical cryptography” is the accepted term in this context. 802.11 already has quite a few “legacy” hits.
I'll try and find this sentence but a section or page # would've helped.
11. Are the draft entries necessary in 9.4.2.179 Public Key element? Or should we wait until these proposals reach RFC status?
They're placeholders for now. Again, we are so far from being finished to worry about stuff like this.
12. The PQC Key element always contains a public key. Then why not call it PQC Public Key element? I find the specificity welcomed, as it reduces confusion with the PQC Commit element.
That's a good comment and let me suggest that you vote to adopt this text as 0.1 and then make a submission to improve it!
13. PQC Key element – the length of PQC Key is confusing. The update(s) to the submission brought since the Madrid plenary have added the following text: “The PQC field is a public key from the indicated PQC Parameter Set whose length depends on the PQC Parameter set.”. Does the length depend on the PQC Parameter Set, or on the “Length of PQC Key” field? Similar for PQC Ciphertext element.
14. “No Sig” should probably be “No Signature”, as there are hits for both. All “Auth” hits should probably be “Authentication”.
Again, it would be nice to have sections to these comments. Grepping through a document and saying "fix all of 'foo'" is not really a good practice for making comments. I know that happens in 11m but let's not bring that practice to 11bt.
15. There is a usage of “ephemeral private key” and the variable is called “esk”. I believe the “esk” is coming from a paper using ephemeral secret key terminology, but we should be consistent.
OK.
16. Typos: “Authenticaiton” x 2.
Again, section? Page number?
17. Quite a few terms are not defined and do not have their acronym expanded e.g. PQPAKE, KEM.
A useful addition to a submission to modify draft 0.1.
Note: I made no comments on wording, as this could also be improved later.
I have no idea what you're getting at but you can suggest improvements in a concrete manner by making a submission to change the base text. But we need 0.1 to do that.
As I rushed this review to allow time for updates before the meeting scheduled for Thursday PM1, please feel free to point out any inaccuracies. To streamline discussions during the TG meeting, I should be available for a joint review or to discuss any specific points further. Several of the points above were previously raised during the Madrid plenary SG sessions, and also before the Madrid meeting.
I'll update the draft, put it on the document server, and send a note to the mailing list.
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
Regards,
Alex
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1