Subject: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 8 Jul 2004 11:07:46 -0700

First, I'd like to applaud the authors on a job well done. It is clear in reading this spec that there was a significant amount of data to work with... I am very impressed with the document. 

1. Section 1.3. "Typically ," -> "Typically, "

2. This section defines the AP as terminating the 802.11 PHY, but it should be noted that this device also terminates the 
802.11 MAC mgmt layer, which is not specified.

3. The definition of Split MAC implies that all MAC mgmt is handled in the AC, but in certain implementations this is not true. The MAC mgmt packets that have very tight timing requirements can be handled in the WTP.

4. Page 14. The text reads 14 contributions, yet above 16 is mentioned.

5. Section 3.2. Another security issue is the very fact that this device is most likely not under lock and key, but does contain secret information in order to communicate with the backend systems, such as AAA, SNMP, etc. Due to the common management method used by IT personel of pushing a "template" to all similar devices, theft of such a device would compromise the wired network.

5. A Network Management Station (NMS) should not be considered as part of the Access Controller. While most controllers will provide one or more management interfaces, a system that is used to scale a global network generally resides on a separate system.

6. Page 25. The list of real-time features should probably include Power Save handling.

7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves WTP manageability"?

8. Page 30. The term "Integration Service" is used as a substitute to bringing function. However, the terminology section called this function "portal". We should stick to a single term throughout the document.

9. Page 33, second to last paragraph, there is a non traditional character in the line that starts with "every mesh node..."

10. Section 5.1. If stations (or non-trusted equipment) are allowed to become part of the mesh backbone, end to end security is required otherwise users traffic will be compromised.

11. Page 45. The URL for the LWAPP draft has changed and the one listed has expired. Does it make sense to update it?

12. General comment. I understand that there was a desire to mask the vendor in the appendices, but I wonder whether this makes sense. The primary issue moving forward is that this is (and will) be known to people on the list (or reading he archives)

13. Appendix C. We really should discourage baseless marketing claims like "secure, scalable, large scale WLAN deployments" unless one intends to back this up with facts. I'm quite certain that no submittal was intended for the home user.

14. Appendix D, Page 52. Seems like spelling rogue as "rouge" is a common mistake. May want to search/replace.

15. Appendix D, question 4. Could the submitter be a tad more specific than "IP Tunnel". For instance, is there a control protocol to setup the tunnels, etc.

16. Appendix D, question 5. Probably too late now, but I really question how these claims can be made given the rather brief data - so we just have to assume the claims are true.

17. Appendix E. Good write-up!

18. Appendix F. I have a question for the author, but this is purely asked due to curiosity. In a home environment, you seem to imply that there is a single set top box, and that you can provide dynamic power assignment, but I wonder how you can do that with a single antenna - you need a clear view of the whole space that needs to be covered.

19. Appendix F, section 9. The paragraph states that the PHY and MAC association services are handled in the STB, and other MAC services are in the controller. Is it possible to get a breakdown or at least an understanding of what the other services being provided are?

20. Appendix L. I am curious about the fact that this architecture is completely agnostic of the PHY, yet it can provide such functions as centralized RF management (which cannot be performed if one has no idea what they are dealing with).

PatC

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 13 Jul 2004 09:18:32 +0800

Dear Pat,

Some responses to your questions;

> 7. Section 4.5. Could the authors please explain how they came to the
conclusion that Remote MAC "improves 
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC improves
manageability over basic autonomous WTPs by centralizing some control
aspects; Remote MAC goes further by centralizing 'all' aspects of the
MAC. So the entire MAC processing is consolidated while the WTPs become
extremely light devices. 

> 18. Appendix F. I have a question for the author, but this is purely
asked due to curiosity. In a home 
> environment, you seem to imply that there is a single set top box, and
that you can provide dynamic power 
> assignment, but I wonder how you can do that with a single antenna -
you need a clear view of the whole space 
> that needs to be covered.
 
We see one set top box in each home and a residential community made up
of a number of boxes. Dynamic power assignment refers to managing all
the STBs - and thus all the antennas - within the community. So the
controller sees the entire wireless channel and makes appropriate
adjustments at the STBs.

> 19. Appendix F, section 9. The paragraph states that the PHY and MAC
association services are handled in the 
> STB, and other MAC services are in the controller. Is it possible to
get a breakdown or at least an 
> understanding of what the other services being provided are?
 
The controller handles services like 11i authentication and encryption. 

Cheers

Saravanan

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap