Subject: Re: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP"

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Sun, 3 Nov 2013 21:38:39 +0000

Hello Dorothy

Thanks for the detailed review.
We accept the suggested changes and will incorporate them in the next version .

Some additional comments below.

Regards

Rajesh
From: Dorothy Stanley [mailto:[email-masked]]
Sent: Monday, October 28, 2013 10:30 AM
To: Rajesh Pazhyannur (rpazhyan)
Cc: [email-masked]
Subject: Re: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP"

Hi Rajesh,
Comments below.
Dorothy
-------------
1.       Today, Split and Local MAC are negotiated using the WTP MAC Type message element. There is no need to include Local and Split MAC in the profile element. The new mode is actually a profile of the current defined Split MAC. In section 4, delete 0 and 1, renumber "2" to "0" and change from "indentified" to "identified" in the line above.

Ø    Yes. I was somewhat ambivalent when I included Split and Local MAC profiles  but I am happy to delete it.

Ø    I am wondering whether we should create two profiles one each for the two cases: Encryption at the WTP and Encryption at the AC.

Section 3.2 can be deleted, and Sections 3.1 and 3.3 combined into a single table.
2.      Section 3.3.1: "Frames Exchange" to "Frame Exchange"
3.       Section 4, "The IEEE 802.11 WTP Profile message element allows the WTP to communicate the profile(s) it supports to the AC."
4.       4. The new MAC model is named "Hybrid MAC profile". This name is very general, and the description says that it is a specific profile of the split MAC, not a hybrid (as the current name suggests) of split and local." Suggest renaming "Hybrid MAC" to "Split MAC with WTP Encryption" (or similar)
> yes, this make sense.
5.       5. Section 5. The text is not clear: "it could directly reference". Well it could, Make it reference the section or not.
Change to "There are no additional security considerations introduced by this specification in addition to those in [RFC5416].
> Yes (this is Section 6, I believe).

6.       6. Section 4 - add a period at the end of the first sentence after "one such message element".
7.       7. Abstract. Suggested edits below:

The CAPWAP protocol defines two modes of operation for IEEE 802.11

   WTPs: Split and Local MAC (medium access control), as described in

   [RFC5415], and [RFC5416].  Specifically, [RFC5416] describes in detail the

   division of labor functionality between the WTP and AC in both the Split and Local MAC

   modes.  Unfortunately, tThere are many some functions that have not yet

   been clearly defined whether they belong can be performed in either to the WTP or the AC.  For

   example, in the Split MAC mode,  IEEE 802.11 encryption is specified as located in either in

   the AC or the WTP with no clear way to negotiate where it should be

   located.  This lack of specification leads to interoperability issues

   between an AC and WTP when the AC and WTP come from different vendors.  To

   solve this problem, this specification defines a profile of the Split MAC mode, "Split MAC with WTP Encryption" mode of operation and an the concept of IEEE

   802.11 MAC profile message element used to negotiate the profile. where each profile refers to a table containing an

   unambigous division of labor between WTP and AC.  The IEEE 802.11 MAC profile message element is used

   as follows: the WTP informs the AC of the supported profile(s) and the

   AC selects the profile when it configures to be configured on the WTP.

On Mon, Oct 14, 2013 at 7:46 AM, Rajesh Pazhyannur (rpazhyan) <[email-masked]<mailto:[email-masked]>> wrote:
Greetings...

We have submitted a new version of the draft (previously titled "Hybrid MAC-Model for CAPWAP".
While solving the same problem as in the original draft, this takes a different approach. We introduce a new element IEEE 802.11 MAC Profile. This profile defines the functional split between the MAC and AC.  The idea of using profiles was based on discussion in the last working groups meeting as well as offline meetings with other participants. While somewhat similar to mode defined in RFC 5416, this solves the problem with the ambiguity in the mode definitions in RFC 5416 as well as enables different functional splits to be defined in the future. The link to the draft is https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac

We are soliciting comments and feedback.

Thanks

Regards

Rajesh

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg