1. CAPWAP Arch-Draft Issues IETF 59, Seoul 4 March 2004

2. #1: Data-forwarding Datapath should not be required to traverse AC. This draft (on architectural taxonomy) does not require data forwarding through AC. But it does intend to include description of architectural variant(s) which do(es)

3. #2: CAPWAP focus CAPWAP is too narrowly focused on IEEE 802.11 The WG has gone through enough analysis to justify the identified need in WLAN space. –This alone calls for enough interface clarity in architecture. Need to minimize scope to limit complexity and reach consensus across SDOs and vendors any shortcomings to the approach may be argued through drafts articulated well enough to justify it.

4. 3#: CAPWAP & Routing CAPWAP is about distributed routing. CAPWAP is intended to describe ability to monitor, control and provision AP elements across a RF/wireless domain. Routing between APs & Network Infrastructure is an optional consequence.

5. #4: Capabilities negotiation Capabilities negotiation described in architecture draft – how does it help interoperability? The intent is to deduce functional capabilities APs (and AC combine to) provide. No clear answers yet. While outside scope of the charter now – this is the basis of exercise to agree on a AP & AC interworking.

6. #5: Capabilities Will this lead to implementing all variants in APs and ACs? Capabilities are intended to identify the scope of AP functions. Taken together with IEEE work on AP functions should lead to a well defined functional balance

7. #6: Terminology – AC, AR, AB The usage of AB, AR and AC are inconsistent with the definition of terms Fix definition & usage. –Access Controller (AC) - can be an AB or an AR. Signifies the control plane rather than datapath –AB - Access Bridge only applies to controllers that are capable of direct-connect or L2 connected. –AR - Access Router applies to controllers that are capable of L3/IP connect.

8. #7: AP & AR name How do APs and ACs know each other’s names in CAPWAP? For an entity to be managed it needs to have an identity Current CAPWAP draft does not discuss namespace Identity must be authenticated (such as a subjectname in a cert.) and reliably securely provisioned. The taxonomy will try to describe current schemes.

9. #8: Interoperability How do we get to an interoperable WLAN backend? –Is it by defining one reference WLAN model? –Is there only one possible model that’s right? –What is the route to CAPWAP? all-embracing – all APs to all ACs? Identify one functional distribution approach that’s scalable? By defining functions that CAPWAP wants to decentralize and arriving at the right distribution of functions preserving IEEE 802.11 WLAN semantics More?

10. #9: RRM Distribution Where should RRM (Radio Resource Management) reside? AP provides measurements, AC manages The draft to expand on RRM approaches and their Pros & Cons

11. #10: AC registration AP should be authenticating to only one AC. the Discovery section describes it being authenticated to more than one available AC The AP will actively be associated to only one AC at a time – managed by one instance of AC. It may be capable of registering with another upon an AC failure.

12. #11: Distribution & Integration “every AP is its own, isolated ESS and no APs actually implement the architecture described in the standard” How should distribution and integration be ‘distributed’ to scale?

13. #12: TSN, TKIP, RSN 3.3.5.1.2 confuses TSN & TKIP PSK can be used in TSN, RSN RSN is based on RSNA-only BSS; TSN can be a mix of WEP, TKIP, RSNA capable devices.

14. #13: Motivation section seems to prefer one type of data-forwarding. appears to imply other wireless technologies MAC are splittable. Neither are implied. Data forwarding requirement through AC is not mandated. The mention of split does not make any assumptions about MAC- split vs. AP split: it means functional split. The section will be restructured to reflect taxonomy goals.

15. #14: ForCES, DIRAC etc. Comparison of ForCES, DIRAC to LWAPP is premature. This section of document, while less significant to the current charter, is discussing prior art. The intent is to reference possible relevant work already done. Comparisons to LWAPP currently may be removed. –However, LWAPP as now adopted by some vendors may be another prior art (not draft submitted to IETF) to discuss, besides other open protocols/architectures.

16. #1: PS draft Issue Incompatibilities arising due to different types of functional splits is an issue to be addressed