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 protected]]
Sent: Monday, October 28, 2013 10:30 AM
To: Rajesh Pazhyannur (rpazhyan)
Cc: [email protected]
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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to