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. 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) 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]. 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, *tT**here* 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]> 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*<https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac> > > We are soliciting comments and feedback. > > Thanks > > Regards > > Rajesh > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
