Re: [PATCH wireless-next v2 1/3] wifi: cfg80211: Add support for S1G Response Indication Configuration

[Ria Thomas <ria.thomas@morsemicro.com>]

On Tue, Jan 13, 2026 at 09:50:44AM +0100, Johannes Berg wrote:
> 
> Actually, reading the spec, are you sure it's even on an *interface*
> scope? A lot of this seems to me like it should be per intended
> receiver, and you need to know its capabilities for generating the
> intended response?
> 

After reviewing the IEEE 802.11ah specification and correlating it with
the WFA HaLow certification tests, it is clear that Response Indication
is not intended to be a per-receiver or per-peer configuration.

Per IEEE Std 802.11-2024, 10.3.2.17, Response Indication is a
TXVECTOR parameter set by the transmitting MAC entity (AP or STA)
to advertise the expected response type for a specific PPDU and to
protect the corresponding response PPDU expected SIFS later. As a
TXVECTOR parameter, Response Indication is selected for each
transmission and applies at the PPDU level; it is not defined
as persistent state associated with a specific peer STA.

The selection of a Response Indication value is governed by
the established BSS context and the protocol rules defined by
the standard for when a response is expected, rather than by
any explicit per-peer Response Indication capability negotiation.

Accordingly, the implementation treats Response Indication as a
per-interface (per MAC/VIF) transmit configuration, applied when
constructing the TXVECTOR for each PPDU. Response Indication therefore
remains a local, per-transmission decision, governed by the applicable
protocol rules and operating context, rather than by persistent per-receiver
configuration.

I hope this clarifies the rationale behind the current approach.
I am happy to discuss further if there are specific scenarios you would
like to examine.

Ria