| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Jouni, Thank you very much for taking valuable time and insightful feedback! Please find my response as below. What value should a prover use in the PoW Lifetime field it sends? Should that be marked to be reserved, i.e., that field would be applicable only in frames sent by the verifier? --I agree with you. I have revised the text to indicate the field would be only present in frames sent by the verifier. What is the frame in which a verifier would set the PoW Difficulty field to 0 (capability indication)? The PoW element is not include in Beacon or Probe Response frames in the current draft and this contribution does not change that. (And if the plan is to add this to every Beacon frame, I would object that part.) --I understand your concern. I have removed this change from this document. Clause 9 should not describe behavior and shall not include normative verbs like "shall" and "may", i.e., the text describing behavior in 9.4.2.aa1 needs to moved to another clause. --Agree, I have moved it to 12.17.2. The use and contents of the new PoW Flags field is described only for the verifier (AP). This element is also sent by the prover (non-AP STA). How is a prover supposed to use this new field? --I have emailed Anuj and will try to work with him to complete descriptions related with PoW Flags field, as this field is proposed originally by his CR document. Why do we have a PoW Challenge Length field if we hardcode a fixed length value for the PoW Challenge field? Please don't use "of this amendment" in the text.. I'm assuming the pöan is to describe 40 octets as the only defined length for P802.11bt, but it should not be done in this manner. It is also unclear why any value longer than that is acceptable when construction of such a value is not defined. If we do end up having a fixed length contents for this PoW Challenge field, it would be nice to have a figure showing that fields used in that construction instead of just the text description of those fields. --I agree on your concern about the fixed length. I have removed "of this amendment" in 12.17.2. I also removed the related text changes from this CR. I have attached the revised CR in this email, and also uploaded it to the mentor page. Thank you very much! Hi TGbt team, I have revised the CR document as attached. Please let me know if you have any comments. Your input is highly appreciated! Thank you. Best Regards, Ming -----Original Message----- From: Jouni Malinen <jkmalinen@xxxxxxxxx> Sent: Wednesday, July 15, 2026 8:20 AM To: Zhao Ming <zhao.ming1@xxxxxxxxxx> Cc: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx Subject: Re: [STDS-802-11-TGBT] Requesting Feedback on PoW: 11-26-1402-01-00bt Clause 9 should not describe behavior and shall not include normative verbs like "shall" and "may", i.e., the text describing behavior in 9.4.2.aa1 needs to moved to another clause. The use and contents of the new PoW Flags field is described only for the verifier (AP). This element is also sent by the prover (non-AP STA). How is a prover supposed to use this new field? What value should a prover use in the PoW Lifetime field it sends? Should that be marked to be reserved, i.e., that field would be applicable only in frames sent by the verifier? What is the frame in which a verifier would set the PoW Difficulty field to 0 (capability indication)? The PoW element is not include in Beacon or Probe Response frames in the current draft and this contribution does not change that. (And if the plan is to add this to every Beacon frame, I would object that part.) Why do we have a PoW Challenge Length field if we hardcode a fixed length value for the PoW Challenge field? Please don't use "of this amendment" in the text.. I'm assuming the pöan is to describe 40 octets as the only defined length for P802.11bt, but it should not be done in this manner. It is also unclear why any value longer than that is acceptable when construction of such a value is not defined. If we do end up having a fixed length contents for this PoW Challenge field, it would be nice to have a figure showing that fields used in that construction instead of just the text description of those fields. - Jouni On Tue, Jul 14, 2026 at 7:08 PM Zhao Ming <00005f3ede0a8578-dmarc-request@xxxxxxxxxxxxxxxxx> wrote: > > Hi TGbt team, > > > > We have updated the documents on PoW enhancement (26/1360r1 and 26/1402r2), based on the feedback received so far. > > > Our proposal complements the existing design and CRs being discussed, by addressing important gaps, to achieve a more complete solution. > > > I have summarized the three changes in our proposed CR as follows. > > 1. Use 1 bit in RSNXE to indicate PoW support STA (This enables backward-compatible operation). > 2. Add a lifetime field in the PoW element (So that a STA can stop computing the solution if the PoW challenge has expired. It helps STA to save energy, without spending unnecessary computation). > 3. Advertisement of Hashing Algorithms supported (by reusing PoW element). > > > Please let me know if you have any comments. Appreciate your valuable feedback. > > > Thank you. > > > Best Regards, > > Ming > > ________________________________ > > 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
Attachment:
11-26-1402-01-00bt-cr-for-pow-enhancement.docx
Description: 11-26-1402-01-00bt-cr-for-pow-enhancement.docx