Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

Hi Jay,

 

Thanks for your reply. Please see my response below.

 

Regarding the first question, if we aim to deliver a stable draft since 11bt draft 2.0, we should maintain the draft unchanged in terms of the core algorithm and workflow, even if the PQC PAKE protocol itself undergoes frequent modifications. In this case, it does not matter whether the PQC PAKE protocol becomes an RFC before the 11bt draft is officially released.

JW: I’m not sure how I should interpret “maintain the draft unchanged in terms of the core algorithm and workflow”. If this is achieved by normatively referencing draft-vos-cfrg-pqpake, then it indeed matters whether draft-vos-cfrg-pqpake becomes an RFC. If that’s not the case, I would like to know how it can be achieved.

Conversely, if we decide to adopt the PQC PAKE protocol only after it becomes an RFC, we may miss the 2030 timeline, according to the estimated timeline you provided.

JW: I agree.

Perhaps we need a liaison to consult CFRG on which parts (the input parameters, the parameters exchanged in the air, and the workflow) are stable enough for 802.11 adoption.

JW: I do not think the consult is necessary. The question has been answered by the liaison response from CFRG. It says “until a document has been adopted and has passed RG Last Call, its content can still change, including the wire format, so we wouldn't consider it stable enough for another SDO to reference before then”. But since CFRG asked for input from our side, we can come up with a list of our requirements to reply.

The key point is that the PQC PAKE protocol is merely a tool for 802.11. Why should we duplicate the entire protocol into the 802.11 draft? In the event that a security issue arises within the Wi-Fi industry, who would be responsible for addressing it? Since the authors are part of CFRG, not 802.11, it is not a wise approach.

JW: I agree that the CPaceOQUAKE draft is a tool. I also agree that duplicating the entire protocol into the 802.11 draft is unnecessary. Regarding the responsibility, it is 802.11 that defines the specs and only 802.11 can update its own specs. IMO, regardless of whether we decide to duplicate the text, or do a mapping, 802.11 would remain responsible to address the issue.

The last point is incorrect. The registration of aPAKE is one valid method for provisioning. Please consider: which credential-based authentication does not rely on (off-channel) provisioning? None!!

JW: It is true that PAKE and aPAKE both rely on provisioning. This point is talking about the cost. Comparing with balanced PAKE, whose password can be relatively easily provisioned (e.g., human input), the provisioning of aPAKE does cost more. For example, the registration of CPaceOQUAKE+ verifiers, which contain at least a 32-bytes verifier and a KEM encapsulation key, cannot be done in the same way as a symmetric PAKE. Dan also elaborated on the memory cost of deriving the verifiers. This is the cost I’m talking about. That said, I’m not against aPAKE, I just think it is helpful to clarify the benefits and costs.

 

Best,

Jiawei

From: yang.zhijie@xxxxxxxxxx <yang.zhijie@xxxxxxxxxx>
Sent: Monday, October 26, 2026 2:01 PM
To: 000053429a76cfd4-dmarc-request@xxxxxxxxxxxxxxxxx
Cc: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

Hi Jiawei, 

 

Thank you for sharing some insights.

 

Provide responses from different perspectives.

 

Regarding the first question, if we aim to deliver a stable draft since 11bt draft 2.0, we should maintain the draft unchanged in terms of the core algorithm and workflow, even if the PQC PAKE protocol itself undergoes frequent modifications. In this case, it does not matter whether the PQC PAKE protocol becomes an RFC before the 11bt draft is officially released.

 

Conversely, if we decide to adopt the PQC PAKE protocol only after it becomes an RFC, we may miss the 2030 timeline, according to the estimated timeline you provided.

 

Perhaps we need a liaison to consult CFRG on which parts (the input parameters, the parameters exchanged in the air, and the workflow) are stable enough for 802.11 adoption.

 

The key point is that the PQC PAKE protocol is merely a tool for 802.11. Why should we duplicate the entire protocol into the 802.11 draft? In the event that a security issue arises within the Wi-Fi industry, who would be responsible for addressing it? Since the authors are part of CFRG, not 802.11, it is not a wise approach.

 

The last point is incorrect. The registration of aPAKE is one valid method for provisioning. Please consider: which credential-based authentication does not rely on (off-channel) provisioning? None!!

 

 

Welcome to your further insights.

 

杨志杰10343608

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

Date: 2026年10月26日 11:42  

Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake  

Hi Dan and Jay,

 

Here are my thoughts on this topic.

 

1. Regarding mapping to CPaceOQUAKE draft vs. writing our own version, there is also a timeline concern. As the CPaceOQUAKE draft has not been adopted as a Working Group draft,  an optimistic estimate on the time when it is published as RFC would be after ~3 years (according to the information provided by Mathy). Mapping to the IRTF draft means our draft relies on the IRTF draft. This raises the following questions:

·        Q1: If TGbt is to finish its work within 3 years (as the current timeline suggests), do we accept that the final TGbt  draft depends on an unpublished IRTF draft?

·        Q2: If the answer to Q1 is no, is TGbt willing to extend its timeline to wait for CPaceOQUAKE to stabilize?

 

2. Regarding the aPAKE version CPaceOQUAKE+, I agree that TLS integrating aPAKE does not necessarily mean we should do the same. I try to list the major benefits and costs  of doing CPaceOQUAKE+ in 802.11 here for discussion

 

Benefit:

·        If the AP is broken or hacked, the adversary cannot impersonate a STA using the verifiers.

Cost:

·        One extra message. The challenge message contains KEM ciphertext (for X-WING, the ciphertext size is 1120 bytes)

·        Requires a mechanism for registration (can be out of band)

 

Best,

Jiawei

 

 

From: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, October 26, 2026 1:50 AM
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

 

  Hi Jay,

 

On 10/23/26, 6:06 AM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote:

 

Hi Taochun,

 

Thanks for sharing insight. 

 

I would say the group should create a cryptography mapping subclause to show all the differences（including some enhancement）between  802.11 and IETF draft/RFC when adapting to 802.11. Rather than duplicating the whole PQC PAKE pake protocol defined by CFRG into 802.11 draft.

 

I’m not so sure about that. I think that subclause would result in more churn than if we just wrote our own version—as close as possible to the draft—of CPaceOQuake. That way the difference arise when we have a compelling need to incorporate  them and then we have draft churn. If we have a subclause of differences it will constantly change as the draft changes but we don’t need to. Every change made that really doesn’t matter to us would need to be mapped.

 

There is a good  example in TLS to show how to integrate (PQC) PAKE into TLS 1.3 PAKE protocol: (draft-ietf-tls-pake-02  - A Password Authenticated Key Exchange Extension for TLS 1.3), please have a look.

 

I don’t think that integration is helpful for us. CPaceOQuake(+) cannot be used directly in TLS 1.3 because it requires more than 2 messages to complete and it has sequential requirements on multiple protocols. That is why section 7 of  the draft exists, to support these sorts of exchanges that cannot fit directly into the TLS handshake. What the draft specifies is:

 

“External PAKEs execute their complete protocol exchange outside of TLS, then integrate with TLS through External PSK Import [RFC9258]. This approach enables  protocols that cannot be constrained to the two-message limit of Internal PAKEs.”

 

Which means you need some external out-of-band communications channel set up to run both CPace by itself, and then OQuake+ by itself. As the draft says:

 

“Both parties must support CPace and OQUAKE+ protocols for out-of-band execution. Applications configure out-of-band communication channels and TLS endpoints separately.”

 

So you need to run 2 separate protocols before you import the result (an “external PSK”) into TLS. That doesn’t sound like something we want to do. We, 802.11, are not an “application” that can assume any kind of connectivity to run protocols  out-of-band. Everything is done in 802.11 pre-association and it doesn’t seem like a good idea to attempt this kind of thing.

 

BTW, the hybrid PQC PAKE adapted by TLS 1.3 PAKE is CpaceOQUAKE+, it's natural for 802.11 to adopt the same protocol in the infrastructure  BSS senario.

 

  Is it really? I don’t think so. It says, in 7.3.3, that the parties exchange OQuake+.Init and OQuake+.Respond and then derive the hybrid_secret. How does it do the asymmetric PAKE in 2 messages without OQuake+.Finish? The client needs  to confirm possession of the password via successful decapsulation of the ciphertext sent by the server. But without that message I don’t think it’s really doing  the + version of the protocol.

 

  Why do you think it is “natural to adopt the same protocol in the infrastructure BSS scenario”? I mean, there may be benefits to doing the + version but there are also costs. Are those benefits something we cannot live without? Do those  benefits for us outweigh the costs to us? What TLS does is up to TLS. But they have different requirements and different constraints. The decision making process of TLS is not ours and what they end up deciding really has no bearing on what we  do. We need to come to an agreement on what to do based on our requirement and our constraints.

 

  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

 

杨志杰10343608

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

From: TaoChunLee(李道軍)  <000062f6c3142c4b-dmarc-request@xxxxxxxxxxxxxxxxx>

To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx  <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>;

Date: 2026年10月23日 16:50  

Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake   

 

Hi Dan,

 

Concur with the idea to shape the 802.11 version of CPaceOQuake, what else do you see are redundant besides lv_cat()? The group needs  to converge on a list of  CPaceOQuake redundancy when adapting to 802.11.

 

--

Tao Chun Lee | Tech Manager, Standards  | Communication System  Design, MediaTek Inc.

Email: TaoChun.Lee@xxxxxxxxxxxx  | Phone:  +886 3 560 0868 | Website: www.mediatek.com

 

From: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, October 20, 2026 4:54 AM
To:STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

External email : Please do not click links or open attachments until you have verified the sender or the content.

 

  Hi Mathy,

 

  Good collection of documents. There’s also draft-irtf-cfrg-dnhpke which is not an RFC but has been in working group last call (next stop before RGLC and then publication as RFC) for several years. CFRG is active  for some stuff and a graveyard  for others. My draft is in the graveyard.

 

  But I think the issue is not so much when it was published as an RFC after it was adopted as a RG item. I think it’s better to look at when the draft became *stable* which is when other documents can start  considering referencing  it. And given the fact that CPaceOQuake is based on other cryptographic work that has good providence—CPace, hash-to-curve, NoIC—I think the time to acceptable stability is not that long.

 

  That said, one of my gripes about CFRG is that its documents are doing more E than R, that is its more IETF than IRTF. IRTF is supposed to make tools, IETF uses the tools in a protocol. It used to be that IRTF  documents didn’t need IANA  registries because they’re not proposing a protocol. Now we have all sorts of IRTF documents with IANA considerations. And they are proposing on-the-wire formats which not everyone needs. For instance, lv_cat(). 802.11 has elements.  Our data already have length  indicators. We don’t need to lv_cat() an Information Element. That’s redundant, it’s overkill. But CPaceOQuake is specifying the use of lv_cat() when constructing the messages it sends.

 

  Given the fact that the TG has already told 2 external organizations that we’re working on a PQ PAKE I don’t think we can punt this effort to “whenever the CFRG comes up with an RFC or a draft of considerable  stability.” We need something  that is as faithful to CPaceOQuake as possible (given the requirements of 802.11) and then we need to closely monitor the draft to see if there are any substantial changes that we need to incorporate. This will be an ongoing  concern as the TGbt draft matures.  The composition of these two PAKEs is discussed quite extensively and I think we can follow that text to define an 802.11 version of CPaceOQuake that addresses the needs of 802.11 but is not so rigid that it cannot change  if considerable changes are made to  the CFRG draft. But I don’t think we necessarily need to be 100% aligned with the draft. This is not going to be showing up as an API to call in OpenSSL—e.g. “pmk = cpaceoquake(password, sta-mac, ap-mac, profile)—so we  don’t need to treat it as a black box.  That doesn’t mean we should just roll-our-own though. The draft has some very specific, cryptographically justified, and well defined, key derivation and it would behoove us to not deviate from that. But if other aspects  of the draft are not really compelled  by a use case, then just saying “well the draft says to do this so we’re doing it” is not right.

 

  Interested in other opinions.

 

  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 10/18/26, 1:48 AM, "Mathy Vanhoef" <00006588701cd687-dmarc-request@xxxxxxxxxxxxxxxxx>   wrote:

 

Hello all,

 

Making predictions is hard, especially about the future. Nevertheless, at least for me it was useful to look up the timelines of a few other recent cryptographic RFCs to have a comparison:

 

- OPAQUE (RFC 9807): adopted in September 2020, published in July 2025.

 

- SPAKE2 (RFC 9382): adopted in January 2015, published in September 2023.

 

- OPRF/VOPRF (RFC 9497): adopted in July 2019, published in December 2023.

 

- Hashing to Elliptic Curves (RFC 9380): first CFRG group draft in March 2018, published in August 2023.

 

- HPKE (RFC 9180): adopted in June 2019, published in February 2022.

 

Here, 'adopted' means adopted by the CFRG as a research-group document. The CPaceOQUAKE draft has not yet been 'adopted' (but may soon be?). All of the above are Informational RFCs. Of   course the timeline of CPaceOQUAKE may be substantially faster (or slower), but this at least gives something to compare to.

 

> This IETF message seems to generate more doubts on basing PAKE on draft-vos-cfrg-pqpake: only an individual draft, not IETF standards, security analysis inconclusive, etc.

 

Note that the authors already provide a formal security analysis of CPaceOQUAKE [1]. Further work analyses the security of the underlying PAKE construction and hardens against timing  attacks  [2], and the hybrid PAKE combiner is analysed in [3]. The CFRG process provides an additional security review. Arguably one downside is that CPaceOQUAKE is still a fairly new security protocol, but at the same time, I am not aware of a better alternative.

 

Best regards,

Mathy

 

[1] https://eprint.iacr.org/2025/1343

[2] https://eprint.iacr.org/2025/1399

[3] https://eprint.iacr.org/2024/1621

 

From: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 15 October 2026 17:38
To:STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

 

  Hi Tao Chun,

 

 

On 10/15/26, 1:36 AM, "TaoChun Lee (李道軍)" <000062f6c3142c4b-dmarc-request@xxxxxxxxxxxxxxxxx>   wrote:

 

Hi all,

 

This IETF message seems to generate more doubts on basing PAKE on draft-vos-cfrg-pqpake: only an individual draft, not IETF standards, security analysis inconclusive, etc.

 

It is an individual draft right now. It will not stay that way. Yes, it will be an informational RFC not a standard. Know what other things we use that are informational RFCs and not standards? HKDF (RFC 5869),   HMAC (RFC 2104), CCMP (RFC 3610), SIV (RFC 5297), AES Key Wrap (RFC 3394), ECDSA (RFC 6979). SAE wasn’t even based on an RFC. We have normative requirements in IEEE Std 802.11 that are based on informational RFCs all over the place. That should not be a determining   factor in whether we adopt CPaceOQuake or not.

 

If the group still wants to leave option open for draft-vos-cfrg-pqpake, on security framework side, suggest to be agile or hybrid with other (native) options.

 

What do you mean leaving it open “on security framework side”? As opposed to what other side? What other option do you see on the security framework side? Also what do you mean “agile”? It’s already hybrid. Please   explain what properties you’re looking for in a PAKE.

 

  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

 

--

Tao Chun Lee | Tech Manager,  Standards  | Communication System Design, MediaTek Inc.

Email: TaoChun.Lee@xxxxxxxxxxxx  | Phone:  +886 3 560 0868 | Website: www.mediatek.com

 

From: Stacey, Robert <robert.stacey@xxxxxxxxx>
Sent: Thursday, October 15, 2026 12:55 AM
To:STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

Dear TGbt participants,

 

See below for a response to our liaison. Note in particular the last paragraph on providing more input to the CFRG.

 

Regards,

-Robert

Hi Robert, Peter,

Thanks for the liaison, and sorry for the slow reply. Here's where things stand on your three questions.

On adoption: draft-vos-cfrg-pqpake is still an individual draft. CFRG takes on work through a call for adoption on its mailing list, and we haven't run one for this draft, so we can't say yet whether it will be adopted. It was presented at IETF 126 in July,   and discussion has continued on the list since then.

On timeline: we don't have dates, and CFRG doesn't work to fixed deadlines. If the draft is adopted, how long it takes to reach RG Last Call depends on how quickly the security analysis and reviews settle. After RG Last Call, the remaining steps (shepherd write-up,   IRTF chair review, IRSG poll, IESG conflict review and RFC editing) typically take two months or more.

On stability: until a document has been adopted and has passed RG Last Call, its content can still change, including the wire format, so we wouldn't consider it stable enough for another SDO to reference before then. The draft lists some open research questions   itself, and its security analysis is still being discussed on the list. Also note that CFRG documents aren't IETF standards. This one is intended as an Informational RFC.

The authors will present an update at the CFRG session at IETF 127 in San Francisco in November, and we'll discuss the draft there. 802.11 participants are welcome to join, in person or remotely.

It would help us to hear from 802.11, ideally on the CFRG list, about what P802.11bt needs: a balanced PAKE, where both sides hold the password as with SAE today, or an augmented one, where the access point or server stores only a verifier; whether it has to   be hybrid; any limits on round trips or message sizes; and when TGbt needs a stable reference. That input will shape whether and how CFRG takes this on.

Best,
Nick, for the CFRG chairs

 

On Mon, Sep 28, 2026 03:05 PM, Russ Housley <housley@xxxxxxxxxxxx> wrote:

 

 

From: "Stacey, Robert" <robert.stacey@xxxxxxxxx>

Subject: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

Date: September 28, 2026 at 2:22:27 PM EDT

To: "alexey.melnikov@xxxxxxxxx" <alexey.melnikov@xxxxxxxxx>,  Nick Sullivan  <nicholas.sullivan+ietf@xxxxxxxxx>, "Stanislav V. Smyshlyaev" <smyshsv@xxxxxxxxx>,  Russ Housley <housley@xxxxxxxxxxxx>

Cc: Alpesh Shah <sasecretary@xxxxxxxx>, "James  P. K. Gilb" <gilb_ieee@xxxxxxxx>, Alfred  Asterjadhi <asterjadhi@xxxxxxxxx>,  "Stephen McCann" <mccann.stephen@xxxxxxxxx>, Stephen Orr <sorr@xxxxxxxxx>,   Peter Yee <peter@xxxxxxxxxx>

 

Dear Alexey Melnikov, Nick Sullivan, and Stanislav V. Smyshlyaev:

 

The IEEE 802.11 working group is working on a project, P802.11bt, with the scope to “extend IEEE 802.11 security to support algorithms for post-quantum cryptography (PQC)”.  Part   of this extension specifies “a password authenticated key exchange that uses PQC”. Some participants in IEEE 802.11 have taken particular interest in the work described in the individual draft draft-vos-cfrg-pqpake.

IEEE 802.11 would like to understand the status and expected direction of this work, and would be grateful if the CFRG could provide their opinion on:

1.      whether the CFRG anticipates adopting draft-vos-cfrg-pqpake as a research group document;

2.      the expected timeline toward RG Last Call and publication; and

3.      the point at which the CFRG would consider the specification sufficiently stable to be referenced by another standards development organisation.

This liaison conveys interest in the status of ongoing CFRG work. It does not constitute a decision by IEEE 802.11 to specify any particular mechanism, nor support of any individual   Internet-Draft.

 

 

Sincerely,

Robert Stacey

Chair, IEEE 802.11 WLAN Working Group

 

Peter Yee

IETF Liaison, IEEE 802.11 WLAN Working Group

+1 415 215 7733

 

 

_______________________________________________
CFRG mailing list -- cfrg@xxxxxxxx
To unsubscribe send an email to cfrg-leave@xxxxxxxx

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

************* MEDIATEK Confidentiality Notice ********************
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful. If you are not an intended recipient of this e-mail, or believe
that you have received this e-mail in error, please notify the sender
immediately (by replying to this e-mail), delete any and all copies of
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

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

************* MEDIATEK Confidentiality Notice
 ********************
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful. If you are not an intended recipient of this e-mail, or believe
 
that you have received this e-mail in error, please notify the sender
immediately (by replying to this e-mail), delete any and all copies of
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

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