Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)

On Thu, 2026-01-22 at 00:42 -0800, Abhishek Rajkapur Suryawanshi wrote:
> > Taking this specific example, it basically says "FW sends a request to
> > hostapd, hostapd does the handshake and installs the MAPC station. This
> > is how we think we should handle the MAPC stations."
>=20
> hostapd controls and manages all MAPC related discovery and MAPC peer=20
> creation part. No trigger from firmware for MAPC Discovery Phase.

Seems to me you're splitting hairs. Clearly you have the *negotiation*
trigger (NL80211_CMD_MAPC_NEGOTIATION_TRIGGER) prominently featured in
the diagrams etc. Sure, it maybe that doesn't explicitly trigger
*discovery*, but if hostapd doesn't already know about the station that
the FW/driver is requesting a negotiation with, it probably also has to
do discovery...

Anyway. I went to write a long email replying to some of your individual
points but deleted it again, I feel it's not worth your and my time.


Clearly, you have already decided on the architecture, and aren't
sharing all of it, based on reasons you aren't really sharing either.
Which is fine, I can't claim that we always share the full reasoning
behind architecture decisions.

We should all still make it transparent _how_ it's intended to work, but
that could also be just part of the documentation added to the kernel
when adding the necessary APIs.


Which then means that really in all the hundreds of lines of text you
just wanted to ask whether or not "Option-A" or "Option-B" for handling
the MAPC peers should be used, and I'd agree that duplicating APIs isn't
good, i.e. taking "Option-A". Note we did something similar for NAN
stations, even if they have different sets of attributes than regular AP
client stations or mesh peers etc.

johannes