[Capwap] The CAPWAP base MIB version 04 was published
Richard <rishyang@gmail.com> Sat, 28 February 2009 15:45 UTC
Return-Path: <capwap-bounces+capwap-archive=lists.ietf.org@frascone.com>
X-Original-To: ietfarch-capwap-archive@core3.amsl.com
Delivered-To: ietfarch-capwap-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F335D3A6841 for <ietfarch-capwap-archive@core3.amsl.com>; Sat, 28 Feb 2009 07:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.206
X-Spam-Level:
X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_75=0.6, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDKs-PdYhREi for <ietfarch-capwap-archive@core3.amsl.com>; Sat, 28 Feb 2009 07:45:50 -0800 (PST)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C7A743A67AD for <capwap-archive@lists.ietf.org>; Sat, 28 Feb 2009 07:45:50 -0800 (PST)
Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DECA4430355 for <capwap-archive@lists.ietf.org>; Sat, 28 Feb 2009 07:46:14 -0800 (PST)
Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id AA83944004F for <capwap@lists.tigertech.net>; Sat, 28 Feb 2009 07:46:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8A88F34AC024 for <capwap@frascone.com>; Sat, 28 Feb 2009 07:46:06 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D812E34AC01E for <capwap@frascone.com>; Sat, 28 Feb 2009 07:46:05 -0800 (PST)
X-TigerTech-Content-Filter: Clean
X-TigerTech-Spam-Status: Level 0 (High) (P0); Whitelisted TTSSA (rishyang@gmail.com whitelisted)
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.241]) by mx1.tigertech.net (Postfix) with ESMTP for <capwap@frascone.com>; Sat, 28 Feb 2009 07:46:05 -0800 (PST)
Received: by rv-out-0708.google.com with SMTP id k29so1527356rvb.50 for <capwap@frascone.com>; Sat, 28 Feb 2009 07:46:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.71.14 with SMTP id y14mr1859198rvk.23.1235835965439; Sat, 28 Feb 2009 07:46:05 -0800 (PST)
Date: Sat, 28 Feb 2009 23:46:05 +0800
Message-ID: <8556013e0902280746y23d727bev55f30ba99087e9bd@mail.gmail.com>
From: Richard <rishyang@gmail.com>
To: capwap@frascone.com
Cc: chelliot@cisco.com, Yong Zhang <yozhang@gmail.com>
Subject: [Capwap] The CAPWAP base MIB version 04 was published
X-BeenThere: capwap@frascone.com
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: A list for CAPWAP technical discussions <capwap.frascone.com>
List-Unsubscribe: <http://lists.frascone.com/mailman/listinfo/capwap>, <mailto:capwap-request@frascone.com?subject=unsubscribe>
List-Archive: <http://lists.frascone.com/pipermail/capwap>
List-Post: <mailto:capwap@frascone.com>
List-Help: <mailto:capwap-request@frascone.com?subject=help>
List-Subscribe: <http://lists.frascone.com/mailman/listinfo/capwap>, <mailto:capwap-request@frascone.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1855853961=="
Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com
Hi, The CAPWAP base MIB 04 version was published, and most changes are to close issues found by Dan. Please check it, and especially thanks Dan. The change log were added into the Appendix of draft file, while I also list them here: Appendix A. Appendix A. Changes between -04 and -03 T1. Running smilint results in the following errors: mibs/CAPWAP-BASE-MIB:480: [5] {index-exceeds-too-large} warning: index of row `capwapBaseWtpStateEntry' can exceed OID size limit by 6 subidentifier(s) mibs/CAPWAP-BASE-MIB:582: [5] {index-exceeds-too-large} warning: index of row `capwapBaseWtpEntry' can exceed OID size limit by 6 subidentifier(s) mibs/CAPWAP-BASE-MIB:1090: [5] {index-exceeds-too-large} warning: index of row `capwapBaseRadioBindEntry' can exceed OID size limit by 7 subidentifier(s) mibs/CAPWAP-BASE-MIB:1181: [5] {index-exceeds-too-large} warning: index of row `capwapBaseStationEntry' can exceed OID size limit by 13 subidentifier(s) mibs/CAPWAP-BASE-MIB:1249: [5] {index-exceeds-too-large} warning: index of row `capwapBaseWtpRebootStatsEntry' can exceed OID size limit by 6 subidentifier(s) mibs/CAPWAP-BASE-MIB:1408: [5] {index-exceeds-too-large} warning: index of row `capwapBaseRadioStatsEntry' can exceed OID size limit by 7 subidentifier(s) The reason is that these tables are indexed with objects of SYNTAX of CapwapBaseWtpIdTC which has a maximal size of 128, equal to the maximal size allowed for the whole OID. Reducing the maximal size of the TC to anything less or equal than 115 solves the problem. -------------------------------------------------------------- Refer to entPhysicalSerialNum in RFC4133 and Dan's comment, define CapwapBaseWtpIdTC with OCTET STRING (SIZE (0..32)) IF we use SnmpAdminString (SIZE (0..32)), libsmi would generate error: textual convention `CapwapBaseWtpIdTC' can not be derived from the textual convention `SnmpAdminString' T2. Section 5 - ' To reuse current MIB standards and future extensions for a wireless binding technology' - it is not clear what 'future extensions' may be and I would not commit to using them in advance, so I would suggest to drop this ------------------------------------------------------------- Change it into " To be independent of any wireless technologies and have ability to reuse wireless binding MIB modules defined by other SDOs;" T3 What are the 'MIB standards of other SDOs' that need to be reused? Shi, et al. Expires September 1, 2009 [Page 71] Internet-Draft CAPWAP Protocol Base MIB February 2009 Please refer to them specifically at least by providing one example - for instance where does Dot11OperationTable come from? -------------------------------------------------------------- It is changed into: The text give a definition of " 5.2. Wireless Binding MIB Modules" For Dot11OperationTable, the chang is: For example, the MIB tables such as Dot11OperationTable [IEEE.802- 11.2007] are able to support WTP radio configuration. T4. In order for ifIndex to be used as a common handler for the CAPWAP MIB and for the interface specific MIB modules like a dot11 MIB from IEEE one needs to ensure that the same numbering scheme and mapping is used by all MIB modules, and that it behaves identically for events like interface card swapping, reset or power loss. I do not see how this can happen, I am not sure that this is possible at all, and in any case there is no text in the CAPWAP MIB that explains this mechanism. -------------------------------------------------------------- in the Capwap Digest, Vol 39, Issue 4, we gave the text to explain a mechanism that preserves the values of ifIndex, Request mailing list to confirm it. In the section of "Relationship to the IF-MIB", add text "Also, as ifIndex[RFC2863] will be used as common handler for corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless technologies MIB modules, the system (AC) MUST have a mechanisms that preserves the values of ifIndex in the ifTable at AC reboot." T5. Section 7.2 - 'The interface SHOULD be modeled as an ifEntry' - Is a SHOULD enough or rather a MUST is required here taking into account the requirements in Section 5. ----------------------------------------------------------------- It is changed into:MUST be T6. The documents that define the MIB modules required for IMPORTs must be listed in the Normative References section. ----------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 72] Internet-Draft CAPWAP Protocol Base MIB February 2009 add reference to RFC3411 in the section of "MIB modules required for IMPORTS", add "SNMP-FRAMEWORK-MIB [RFC3411]," T7. In the example in Section 8 capwapBaseWtpId equals the representation of the OCTET STRING '12345678' and not the number 12345678 ---------------------------------------------------------------- Yes, it is change into '12345678' T8. In the example in Section 8 ifPhysicalAddress should have six zeros. ----------------------------------------------------------------- Yes, it is change into '000000' T9. What is the Vendor Identifier mentioned in Section 9 as being assigned by IANA? Is this something specific for this MIB document - in this case it needs to be mentioned in the IANA considerations section? ----------------------------------------------------------------- The description of Vendor Identifie is changed into: Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes" T10. Why does one need a special TC for CapwapBaseWtpIdTC? If this is typically a serial number, then SnmpAdminString SIZE (1..128) should do. ----------------------------------------------------------------- Station, radio, WTP are main objects to management by MIB drafts. They would appear in the serval table and notification. Suggest to have a TC for them. T11. In any case why is the SIZE in this TC fixed at 128? ----------------------------------------------------------------- Refer to entPhysicalSerialNum in RFC4133 and Dan's comment, define CapwapBaseWtpIdTC with OCTET STRING (SIZE (0..32)) T12. A number of read-write objects do not have the persistency behavior defined in case of agent reboot - capwapBaseStationSessionsLimit, capwapBaseDataChannelSecConfig, Shi, et al. Expires September 1, 2009 [Page 73] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseControlChannelAuthenConfig ----------------------------------------------------------------- Add the "The value of the object is persistent at restart/reboot." in the description of capwapBaseAcMaxRetransmit,capwapBaseAcChangeStatePendingTimer, capwap BaseAcDataCheckTimer,capwapBaseAcDTLSSessionDeleteTimer,capwapBaseAcE choInterval, capwapBaseAcWaitJoinTimer, capwapBaseAcWaitDTLSTimer,capwapBaseAcSilentInterval, capwapBaseAcRetransmitInterval T13 - Is more than one security policy possible to be configured on a given AC? If not, then why is capwapBaseDataChannelSecConfig a BIT? ----------------------------------------------------------------- Yes, the data type of capwapBaseDataChannelSecConfig should be INTEGER T14 - the name of capwapBaseDataChannelSecOptions should better be something that includes DTLSPolicy to make clear to what fields in the AC Descriptor it corresponds. The DESCRIPTION should also be consistent with the text in the protocol document ----------------------------------------------------------------- To make it consistent with protocol, change capwapBaseDataChannelSecOptions with capwapBaseDataChannelDTLSPolicyOptions. Change capwapBaseDataChannelSecConfig with capwapBaseDataChannelDTLSPolicyConfig Also, the DESCRIPTION should also be consistent with the text in the protocol document T15 - is more than one credential type possible to be configured on a given AC? If not then why is capwapBaseControlChannelAuthenConfig a BIT? ----------------------------------------------------------------- Yes, the data type of capwapBaseControlChannelSecConfig should be INTEGER T16 - it would be good for management applications writers to mention in the DESCRIPTION clause thatcapwapBaseAcnameListName is expected to be a UTF-8 encoded string ----------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 74] Internet-Draft CAPWAP Protocol Base MIB February 2009 Yes, it is added T17 - Object names in capwapBaseWtpStateTable do not respect the naming conditions relative to capwapBaseWtpStateEntry --------------------------------------------------------------- Add one more WtpState in the object name. For example, capwapBaseWtpId is to changed into capwapBaseWtpStateWtpId, other objects are similiar. all objects with new name: CapwapBaseWtpStateEntry ::= SEQUENCE { capwapBaseWtpStateWtpId CapwapBaseWtpIdTC, capwapBaseWtpStateWtpIpAddressType InetAddressType, capwapBaseWtpStateWtpIpAddress InetAddress, capwapBaseWtpStateWtpPhyAddress PhysAddress, capwapBaseWtpState INTEGER } T18 - same for capwapBaseWtpStateTable ----------------------------------------------------------------- Same as above T19 - capwapBaseWtpName is of SYNTAX AsnmpAdminString which is limited to SIZE 255, while the WTP name can be up to 512 characters -------------------------------------------------------------- change with OCTET STRING(SIZE(512)) T20 - same about capwapbaseWtpLocation which can be up to 1024 characters in length ----------------------------------------------------------------- change with OCTET STRING(SIZE(1024)) T21 - Section 4.8 defines default value for a number of variables. However, these are not reflected in the MIB - for example why is there not a DEFAULT clause that will set capwapBaseWtpFallbackEnable to enabled(1) as per 4.8.9? Or capwapBaseWtpMaxDiscoveries which has a default of 10 defined in 4.8.5 ------------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 75] Internet-Draft CAPWAP Protocol Base MIB February 2009 Added DEFVAL { enabled } for capwapBaseWtpFallbackEnable. capwapBaseWtpMaxDiscoveries already has DEFVAL { 10 }. T22 - why does the MIB support reserved(0) for capwapBaseWtpFallbackEnable. Does setting to reserved(0) by the management application have any significance? ----------------------------------------------------------------- The reserved(0) is removed for capwapBaseWtpFallbackEnable T23 - According to 4.8.8 capwapBaseWtpRetransmitCount is a monotonous increasing counter. The appropriate SYNTAX for such an object is Counter32 and not Unsigned32 ----------------------------------------------------------------- Yes, capwapBaseWtpRetransmitCount should use Counter32 T24 - it would be useful to define UNITS clauses for objects like capwapBaseWtpRetransmitCount ----------------------------------------------------------------- It seemed capwapBaseWtpRetransmitCount does not require a UNIT. T25 - define a range (2..180) for capwapBaseWtpMaxDiscoveryInterval ---------------------------------------------------------------- add value scope of (0..24) to capwapBaseWtpDataChannelDeadInterval add value scope of (2..180) to capwapBaseWtpMaxDiscoveryInterval add value scope of (30..4294967295) to capwapBaseWtpWaitDTLSTimer add value scope of (30..4294967295) to capwapBaseAcWaitDTLSTimer add value scope of (20..4294967295) to capwapBaseAcWaitJoinTimer T27 - Object names in capwapBaseRadioBindTable do not respect the naming conditions relative to capwapBaseRadioBindEntry -------------------------------------------------------------------- Change all objects (entry, table)'s prefix from capwapBaseRadioBind to capwapBaseWirelessBinding. change CapwapBaseRadioBindTable to CapwapBaseWirelessBindingTable The Objects with new name: Shi, et al. Expires September 1, 2009 [Page 76] Internet-Draft CAPWAP Protocol Base MIB February 2009 CapwapBaseWirelessBindingEntry ::= SEQUENCE { capwapBaseWirelessBindingRadioId CapwapBaseRadioIdTC, capwapBaseWirelessBindingVirtualRadioIfIndex InterfaceIndex, capwapBaseWirelessBindingType INTEGER } T28 - What do the values reserved(0) and reserved(2) in capwapBaseRadioWirelessBinding mean? Are they ever returned by an agent? ----------------------------------------------------------------- removed the reserved(0) and reserved(2) from the object definition. T29 - in other IETF documents (like RFC 4363) VLAN names are defined as SnmpAdminString (SIZE (0..32)). I suggest the same for capwapBaseStationVlanName. I am aware that section 4.6.8 allows for names up to 512, but I do not find this justified. In any case, if the full size defined in 4.6.8 is to be accommodated, then SnmpAdminString would not be sufficient as its size is limited to 256. ----------------------------------------------------------------- capwapBaseStationVlanName use SnmpAdminString (SIZE (0..32)) T30 - Object names in capwapBaseWtpRebootStatsTable do not respect the naming conditions relative to capwapBaseWtpRebootStatsEntry ------------------------------------------------------------------ Change table name from capwapBaseWtpRebootStatTable to capwapBaseWtpEventsStatsTable. The objects also do similar changes, for example, change capwapBaseWtpRebootCount to capwapBaseWtpEventsStatsRebootCount The objects with new name: CapwapBaseWtpEventsStatsEntry ::= SEQUENCE { capwapBaseWtpEventsStatsRebootCount Counter32, capwapBaseWtpEventsStatsInitCount Counter32, capwapBaseWtpEventsStatsLinkFailureCount Counter32, capwapBaseWtpEventsStatsSwFailureCount Counter32, capwapBaseWtpEventsStatsHwFailureCount Counter32, capwapBaseWtpEventsStatsOtherFailureCount Counter32, capwapBaseWtpEventsStatsUnknownFailureCount Counter32, capwapBaseWtpEventsStatsLastFailureType INTEGER Shi, et al. Expires September 1, 2009 [Page 77] Internet-Draft CAPWAP Protocol Base MIB February 2009 } T31 - Object names in capwapBaseWtpRadioStatsTable do not respect the naming conditions relative to capwapBaseWtpRadioStatsEntry ---------------------------------------------------------------- Change table name from capwapBaseWtpRadioStatsTable to capwapBaseRadioEventsStatsTable. The objects also do similar changes, for example, change capwapBaseRadioSwFailCount to capwapBaseRadioEventsStatsSwFailCount. The objects with new name: CapwapBaseRadioEventsStatsEntry ::= SEQUENCE { capwapBaseRadioEventsStatsResetCount Counter32, capwapBaseRadioEventsStatsSwFailCount Counter32, capwapBaseRadioEventsStatsHwFailCount Counter32, capwapBaseRadioEventsStatsOtherFailCount Counter32, capwapBaseRadioEventsStatsUnknownFailCount Counter32, capwapBaseRadioEventsStatsConfigUpdateCount Counter32, capwapBaseRadioEventsStatsChannelChangeCount Counter32, capwapBaseRadioEventsStatsBandChangeCount Counter32, capwapBaseRadioEventsStatsCurrentNoiseFloor Integer32, capwapBaseRadioEventsStatsDecryptErrorCount Counter32, capwapBaseRadioEventsStatsLastFailType INTEGER } E1. Even if this document uses terminology borrowed from other CAPWAP documents, acronyms like WTP, AC, etc. should be expanded at the first occurrence. ----------------------------------------------------------------- The Terminology section is updated with more Terminology such as Autonomous WLAN Architecture, Centralized WLAN Architecture, Wireless Binding,Split and Local MAC and so on. E2. It would be good for the document to be grammar and spelling checked by a native English speaker. E3. No need for sections 6.1, 6.2, 6.3 - these are standard in any MIB module and their content is well known ----------------------------------------------------------------- Ok, there are removed Shi, et al. Expires September 1, 2009 [Page 78] Internet-Draft CAPWAP Protocol Base MIB February 2009 E4. In Section 7.2 there is no need to mention information that is not specific to the CAPWAP MIB -------------------------------------------------------------------- Removed the "Some specific interpretations of ifTable for CAPWAP- BASE-MIB are as follow." and the interpretations followed it. E5. In the example in Section 8 ifType should be equal with the value assigned by IANA for the ifType - you may mark it xxx and enter an editor note saying 'RFC Editor - please replace xxx with the value allocated by IANA for IANAifType of 'WTP Virtual Radio Interface') ----------------------------------------------------------------- It is done according to the comment E6. Please indicate specifically for each field for the protocols timers message the exact reference in than CAPWAP protocol document. ----------------------------------------------------------------- The section was updated according to protocol E7. The numbering of referred paragraphs in the REFERENCE clauses are not synchronized with the latest version of the CAPWAP protocol document as per http://www.rfc-editor.org/rfc/rfc3411.txt ------------------------------------------------------------------- The REFERENCE clauses for the following TCs or objects are changed with new id: CapwapBaseTunnelModeTC Section 4.6.42 to Section 4.6.43 CapwapBaseMacTypeTC Section 4.6.43 to Section 4.6.44 capwapBaseWtpName Section 4.6.44 to Section 4.6.45 capwapBaseWtpLocation Section 4.6.29 to Section 4.6.30 capwapBaseWtpBaseMacAddress Section 4.6.39 to Section 4.6.40 Shi, et al. Expires September 1, 2009 [Page 79] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseTunnelModeOptions Section 4.6.42 to Section 4.6.43 capwapBaseMacTypeOptions Section 4.6.43 to Section 4.6.44 capwapBaseWtpRadiosInUseNum and capwapBaseWtpRadioNumLimit Section 4.6.40 to Section 4.6.41 capwapBaseWtpStaticIpEnable, capwapBaseWtpStaticIp, capwapBaseWtpNetmask,capwapBaseWtpGateway Section 4.6.47 to Section 4.6.48 capwapBaseWtpFallbackEnable Section 4.6.41 to Section 4.6.42 all the objects in the capwapBaseWtpRebootStatsTable Section 4.6.46 to Section 4.6.47 all the objects in the capwapBaseRadioStatsTable Section 4.6.45 to Section 4.6.46 capwapBaseJoinFailure,capwapBaseImageUpgradeFailure, capwapBaseConfigMsgError Section 4.6.34 to Section 4.6.35 capwapBaseRadioOperableStatus,capwapBaseNtfRadioOperStatusFlag, capwapBaseNtfRadioStatusCause Section 4.6.33 to Section 4.6.34 capwapBaseNtfJoinFailureReason,capwapBaseNtfImageFailureReason Section 4.6.34 to Section 4.6.35 capwapBaseNtfConfigMsgErrorType,capwapBaseNtfMsgErrorElements Section 4.6.35 to Section 4.6.36 E8. No need to repeat the text in the DESCRIPTION clause if a TC is used (e.g. capwapBaseTunnelModeOption, capwapBaseMacTypeOptions) ---------------------------------------------------------------- Change the description of them, and only talk about the function of objects. E9 - capwapBaseWtpMaxRetransmitCnt is not a counter so the suffix Cnt should be dropped from the name. ------------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 80] Internet-Draft CAPWAP Protocol Base MIB February 2009 Change capwapBaseWtpMaxRetransmitCnt into capwapBaseWtpMaxRetransmit E10 - capwapBaseAcMaxRetransmitCnt is not a counter so the suffix Cnt should be dropped from the name. ------------------------------------------------------------------- Change capwapBaseAcMaxRetransmitCnt into capwapBaseAcMaxRetransmit Other changes made by authors: 1) To keep Terminology consistent change "MIBs" with "MIB modules", change "MIB standards" with "MIB modules". 2) Replace "As a generic mechanism, it is independent of any wireless technologies and defined by an independent MIB file" with "It is designed to accommodate the specific needs of each wireless technology in a standard way. It is independent of any wireless technologies;" 3) add reference to [IEEE.802-11.2007],[I-D.ietf-capwap-protocol-binding -ieee80211] and [I-D.ietf-capwap-802dot11-mib] 4) Respect the naming conditions to capwapBaseWtpTable, change capwapBaseMacTypeOptions to capwapBaseWtpMacTypeOptions change capwapBaseTunnelModeOptions to capwapBaseWtpTunnelModeOptions 5) Change IPV6 to IPv6, IPV4 to IPv4 6) remove redundant "the" in the R"Represents the the next" 7) reorganized the section of overview, and divided it into the following sub sections: 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Requirements and Constraints . . . . . . . . . . . . . . . 5 5.2. Wireless Binding MIB Modules . . . . . . . . . . . . . . . 5 5.3. Design Objectives . . . . . . . . . . . . . . . . . . . . 5 5.4. Design Idea . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Mechanism of Reusing Wireless Binding MIB Modules . . . . 6 5.6. CAPWAP Protocol Wireless Binding MIB Module . . . . . . . 7 Especially, add the Terminology of "CAPWAP Protocol Wireless Binding MIB Module" and "Wireless Binding MIB Module". 8) Remove unused(0) from CapwapBaseTunnelModeTC, capwapBaseControlChannelAuthenOptions and capwapBaseControlChannelAuthenConfig 9) Update some words in the section of" Example of CAPWAP-BASE-MIB Module Usage" 10) Added capwapBaseAcEcnSupport, capwapBaseWtpEcnSupport <yzhang@fortinet.com>
_________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap