Subject: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 23 Jul 2004 07:07:35 -0700

I applaud the authors on taking the time to write up this draft, while I do believe
that such a document is useful, I do have some issues with the actual specification.

1. Section 2.1: I have an issue with this proposal. The basic premise is that we cannot
agree on a single model, so every vendor implements all possible combinations.
First, I believe that the engineering resources required to design such a box
would be cost prohibitive. Second, the number of possible combination 
significantly increases the test conditions that must be performed by the
vendor. Third, it increases the code count on all devices - and the more code
you have, the higher the potential for errors.

I would like to understand the motivation behind this proposal.

2. Section 3.1: The statement that consumers and enterprises need the combined
benefit of all architectures does not seem correct. Customers will purchase
a product that delivers the features and performance they require. It is 
not clear to me that this can only be met by supporting all possible 
architectures.

3. Section 3.4: So my view is slightly different. Some customers want the plug and play
convenience of a layer 2 approach. Furthermore, the fact that the AP is not
IP addresseable significantly reduces the risk of attack. Meanwhile, some
customers prefer the flexibility of a layer 3 approach, since it provides them
with the ability to deploy their access points on various subnets, eliminating
the network architectural restrictions associated with the layer 2 approach.

The security issue that is introduced with layer 3 can be overcome with
a carefully designed implementation that is tested against a variety of network
attacks. However, I believe that you will find customers in both camps. Does
this mean that the IETF has to care about what customers will want? I guess it
is up to us to decide.

4. Section 4.1: I disagree for the reasons listed above.

5. Section 4.2: But there are some additional deployment issues here that we are 
ignoring, such as how to protect the data on the backhaul. Perhaps it is fine
to state that this is out of scope for the WG.

6. Section 4.4: QoS can be achieved via other means, such as DS or 802.1P, and therefore
there is not necessarily a need for sub-data channels.

PatC

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 23 Jul 2004 10:58:44 -0600

All,

This is to note that this ID is an individual submission - not a WG
draft item;

nor appears within the scope and timeframe of this charter.

However, In principle, the subject of draft is closely relevant to the
taxonomy work.

Therefore, we would allow the discussion in this WG list for now.

-mani

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat R. Calhoun
Sent: Friday, July 23, 2004 7:08 AM
To: Cheng Hong; [email-masked]
Cc: Saravanan Govindan; Satoshi IINO; TAN, Pek-Yew
Subject: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt

I applaud the authors on taking the time to write up this draft, while I
do believe
that such a document is useful, I do have some issues with the actual
specification.

[...]
5. Section 4.2: But there are some additional deployment issues here
that we are
ignoring, such as how to protect the data on the backhaul. Perhaps it is
fine
to state that this is out of scope for the WG.

[Mani, Mahalingam (Mahalingam)] see above.

6. Section 4.4: QoS can be achieved via other means, such as DS or
802.1P, and therefore
there is not necessarily a need for sub-data channels.

PatC