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