Subject: [Capwap] AD review of draft-ietf-capwap-base-mib-03.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Jan 2009 16:21:00 +0100

Please find below the AD review of draft-ietf-capwap-base-mib-03.txt. I
have divided my comments into Technical and Editorial comments. 

This document is not ready to be submitted to the IESG. It needs one
more iteration at least, but I suggest to do it after a serious scrutiny
from the WG members who know well the protocol.  

Regards,

Dan

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. 

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

T3 What are the 'MIB standards of other SDOs' that need to be reused?
Please refer to them specifically at least by providing one example -
for instance where does Dot11OperationTable come from? 

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. 

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. 

T6. The documents that define the MIB modules required for IMPORTs must
be listed in the Normative References section. 

T7. In the example in Section 8 capwapBaseWtpId equals the
representation of the OCTET STRING '12345678' and not the number
12345678

T8. In the example in Section 8 ifPhysicalAddress should have six zeros.

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? 

T10. Why does one need a special TC for CapwapBaseWtpIdTC? If this is
typically a serial number, then SnmpAdminString SIZE (1..128) should do.

T11. In any case why is the SIZE in this TC fixed at 128? 

T12. A number of read-write objects do not have the persistency behavior
defined in case of agent reboot - capwapBaseStationSessionsLimit,
capwapBaseDataChannelSecConfig, capwapBaseControlChannelAuthenConfig

T13 - Is more than one security policy possible to be configured on a
given AC? If not, then why is capwapBaseDataChannelSecConfig a BIT? 

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 

T15 - is more than one credential type possible to be configured on a
given AC? If not then why is capwapBaseControlChannelAuthenConfig a BIT?

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 

T17 - Object names in capwapBaseWtpStateTable do not respect the naming
conditions relative to capwapBaseWtpStateEntry

T18 - same for capwapBaseWtpStateTable

T19 - capwapBaseWtpName is of SYNTAX AsnmpAdminString which is limited
to SIZE 255, while the WTP name can be up to 512 characters

T20 - same about capwapbaseWtpLocation which can be up to 1024
characters in length

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

T22 - why does the MIB support reserved(0) for
capwapBaseWtpFallbackEnable. Does setting to reserved(0) by the
management application have any significance? 

T23 - According to 4.8.8 capwapBaseWtpRetransmitCount is a monotonous
increasing counter. The appropriate SYNTAX for such an object is
Counter32 and not Unsigned32

T24 - it would be useful to define UNITS clauses for objects like
capwapBaseWtpRetransmitCount

T25 - define a range (2..180) for capwapBaseWtpMaxDiscoveryInterval

T27 - Object names in capwapBaseRadioBindTable do not respect the naming
conditions relative to capwapBaseRadioBindEntry

T28 - What do the values reserved(0) and reserved(2) in
capwapBaseRadioWirelessBinding mean? Are they ever returned by an agent?

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. 

T30 - Object names in capwapBaseWtpRebootStatsTable do not respect the
naming conditions relative to capwapBaseWtpRebootStatsEntry

T31 - Object names in capwapBaseWtpRadioStatsTable do not respect the
naming conditions relative to capwapBaseWtpRadioStatsEntry

E1. Even if this document uses terminology borrowed from other CAPWAP
documents, acronyms like WTP, AC, etc. should be expanded at the first
occurrence. 

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

E4. In Section 7.2 there is no need to mention information that is not
specific to the CAPWAP MIB

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')

E6. Please indicate specifically for each field for the protocols timers
message the exact reference in than CAPWAP protocol document. 

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

E8. No need to repeat the text in the DESCRIPTION clause if a TC is used
(e.g. capwapBaseTunnelModeOption, capwapBaseMacTypeOptions)

E9 - capwapBaseWtpMaxRetransmitCnt is not a counter so the suffix Cnt
should be dropped from the name. 

E10 - capwapBaseAcMaxRetransmitCnt is not a counter so the suffix Cnt
should be dropped from the name. 

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

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