Subject: [Capwap] Comments on draft-ietf-capwap-base-mib-00

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Jul 2008 13:39:32 +0200

This is only a partial reviews and not yet a full MIB Doctor review. I
am seeing a lot of problems in modeling and lack of synchronization
between the MIB and the CAPWAP protocol document, so I would recommend
that the authors of the protocol document and other WG members do a
detailed check and comparison between the two documents. 

1. smilint complains about: 

mibs/CAPWAP-MIB:314: [5] {identifier-case-match} warning: identifier
`capwapWTPId' differs from `CapwapWTPId' only in case
mibs/CAPWAP-MIB:632: [5] {identifier-case-match} warning: identifier
`capwapRadioId' differs from `CapwapRadioId' only in case
mibs/CAPWAP-MIB:712: [5] {identifier-case-match} warning: identifier
`capwapStationId' differs from `CapwapStationId' only in case
mibs/CAPWAP-MIB:1334: [5] {identifier-case-match} warning: identifier
`capwapChannelType' differs from `CapwapChannelType' only in case
mibs/CAPWAP-MIB:1342: [5] {identifier-case-match} warning: identifier
`capwapWTPAuthenMethod' differs from `CapwapWTPAuthenMethod' only in
case

The problem is that object names are similar to TC names, excepting
capitalization

2. smilint complains about: 

mibs/CAPWAP-MIB:294: [5] {index-element-accessible} warning: index
element `capwapWTPId' of row `capwapWTPStateEntry' should be
not-accessible in SMIv2 MIB
mibs/CAPWAP-MIB:613: [5] {index-element-accessible} warning: index
element `capwapRadioId' of row `capwapRadioBindEntry' should be
not-accessible in SMIv2 MIB

Objects that are indices in tables should be not-accessible, and if
there is a need to use the objects for notifications they should be
duplicated in the table. 

3. smilint complains about:

mibs/CAPWAP-MIB:1672: [5] {group-unref} warning: current group
`capwapStationsGroup' is not referenced in this module

4. It would be better that all objects in the MIB module have a common
naming prefix beyond capwap which is common to all capwap MIB modules.
Maybe capwapBase or capwapProto. 

5. The Introduction should refer to the CAPWAP work as to stable work
not 'under way'

6. Overview - it looks to me that the first objective ('To work well
under centralized architectures') and the fifth one ('to meet operator
requirements for centralized architectures') are redundant

7. 'The SNMP agent run on the AC side, and it MAY not be required on the
WTP side' - it is not clear what is meant here, and the usage of the
RFC2119 language is not appropriate. Does it mean to say 'The CAPWAP-MIB
MUST be run on the AC devices and is NOT REQUIRED on the WTP devices'?  

8. Instead of 'ifIndex [RFC2863] will play a role in bridging between
MIB standards defined by different SDOs' better say 'ifIndex [RFC2863]
will be used as common handler for corresponding interfaces in the
CAPWAP-MIB and specific wireless technologies MIB modules'. 

9. 'To reuse MIB objects (defined by SDOs such as IEEE) for radio is
very import' - s/import/important/

10. There is no need for section 6.1 to duplicate the textual
conventions defined in the MIB module itself

11. Section 7.2 - does not ifName map into WTP name? same ifDescr into
WTP descriptor? 

12. Section 7.3 - what is the entPhysicalClass that is recommended for
the usage of RFC4133? 

13. Naming consistency - it would be good to keep object names under a
node with the same prefix as the node name - e.g. capwapAC ->
capwapACWTPSessions or better capwapBaseAC -> capwapBaseACWTPSessions,
etc.

14. CapWapWTPAuthenMethod - it would be better to put other(1) as the
first enumerated value. 

15. Objects like capwapWTPSessionsLimit have a limited range in the
CAPWAP protocol dictated by the numbers of bits used for their
representation (16 for example) - it would be appropriate to limit the
range of the Unsigned32 accordingly

16. capwapDataChannelSecOptions, capwapWTPAuthenOptions - the BIT
construct should be used as SYNTAX

17. capwapWTPACNameList is SIZE(256) in the MIB and 512 in section 4.6.5
of the protocol document. 

18. capwapWTPState has one state dtls(1) while the state diagram in
section 2.3.1 of the protocol document mentions three different states
'DTLS Setup', DTLS Connect', 'DTLS TD' - is dtls(1) supposed to cover
all three? If so please be explicit in the DESCRIPTION clause

19. capwapWTPMACTypeOptions has a SYNTAX of CapwapWTPMACType which is an
enumerated, but the DESCRIPTION clause indicates that BITS SYNTAX should
be used here. 

20. The SYNTAX of capwapStationVlanName should be SnmpAdminString

21. It would be good to find a more adequate name for the
capwapVariables group

22. why is there a need to define a special group for objects for
notifications, instead of defining these objects in the other
configuration tables in the MIB module

23. What is the functionality of the capwapIdEntryNum? The reference to
section 4.6.15 in the protocol document seems to be wrong, this is the
CAPWAP transport protocol

Regards,

Dan

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap