Dan Thanks for the comments. Appreciate the review. Some follow up comments and questions.
Regards Rajesh -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, October 21, 2013 6:48 AM To: [email protected] Subject: [OPSAWG] my comments on draft-ietf-opsawg-capwap-hybridmac-01 Hi, I have read draft-ietf-opsawg-capwap-hybridmac-01.txt. I believe that the document is on the right track, the solution is clear and makes sense. There are however a number of functional and editorial improvements that should improve the clarity of the document. 1. The interaction between the AC and WTP which is introduced for the Hybrid-MAC model Frames Exchange needs to be better clarified. If I understand well the WTP communicates to the AC the list of profile it supports, and the AC selects one to configure the WTP. This exchange of information takes place in the Discovery Request message, Primary Discovery Request message, and Join Request message as per section 4, but it is not clear what is the order. It is also not clear whether an AC can support more than one profile. > Yes. Agree. We will incorporate a sequence diagram that indicates the order. > The intent is that the WTP capability is indicated in one of the following: > Discovery/Primary Discovery/Join. > The AC and WTPs may support multiple profiles (and the AC may select a > profile while configuring the WLAN) 2. The IANA policy of Expert Review suggested to manage the profile space seems too 'liberal'. Adding a new profile actually defines a new class of device, possibly with new functionality, or with functionality distributed differently between the WTPs and ACs. As with this document, I believe that new profiles should be defined in Standards Track documents. 'Standards Action' or at least 'IETF Review' (as per RFC 5226) seem to be the appropriate policies. > I am not completely sure what you are recommending. This may be mainly > because of lack of experience with this matter but am seeking further > guidance on this matter. 3. (editorial) This document uses -- a lot -- of terms from RFC 5415 and RFC 5416. I suggest to have a short section of Terminology and Abbreviations that reminds the principal terms and acronyms re-used. This section can be shared with draft-ietf-opsawg-capwap-extension > Yes, noted. Will incorporate in the next version. 4. (editorial) Acronyms should be avoided in the Abstract. In general I think that a shortest and more 'high level' abstract is needed. > Yes, noted. Will incorporate in the next version. Regards, Dan _______________________________________________ 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
