Two AP vendors in a merged city network each offer proprietary OKC-like fast-roam helpers that do not interoperate for mixed clients. What should the WLAN technician recommend for roaming assists?
Select an answer to reveal the explanation.
Short Explanation
Proprietary OKC cousins from Vendor A and Vendor B often refuse to shake hands. Standards-based assists are the common language in a merged city network. That’s how mixed clients actually roam together.
Full Explanation
Two AP vendors in a merged city network each offering proprietary OKC-like fast-roam helpers that do not interoperate for mixed clients should lead the WLAN technician to prefer standards-based roaming features when mixed clients and mixed vendors must interoperate. Proprietary fabrics rarely stitch cleanly across brands. Standards-based assists provide a common mobility language for the merged municipality.
Enabling both vendors’ proprietary helpers and assuming they form one seamless proprietary fabric fails when they do not interoperate. Removing all encryption so roaming never needs key hierarchy features again fails security policy and is not a roam design. Forcing every client to a single proprietary stack even when procurement bought mixed devices may be politically/technically infeasible and ignores the mixed reality.
Exam caveat: multi-vendor civic WLANs → prefer standards-based roam assists over dueling proprietary helpers.
Operational check: enable interoperable 802.11r/k/v (per design and client support); disable conflicting proprietary helpers where they break mixed roam; validate with clients from both legacy fleets; document the multi-vendor roam standard. In merger projects, write an interoperability decision record choosing standards-based roam assists and noting which proprietary helpers were disabled to protect mixed-client mobility.