Subject: Re: [MIB-DOCTORS] The changes according to Bert's comments

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 20 Dec 2009 12:56:33 +0100

Looks good. If you send me a (pre-release) c opy of the new MIB module, I can run it through
SMICng to check it beofre you commit it to a new rev of the draft.

Bert
  ----- Original Message ----- 
  From: shiyang 00338 
  To: [email-masked] ; [email-masked] 
  Sent: Sunday, December 20, 2009 9:38 AM
  Subject: The changes according to Bert's comments

  Hi, Bert:

  The following are changes should be done according to your comments.
  Thanks for your guidance.

  W:
  SMICng (strict checking) tells me:
   f(capwap-base.mi2), (851,17) Item "capwapBaseWtpStateWtpBaseMacAddress"
  should have SIZE specified
  [Editors]
  According to the following text in the RFC5415，The MAC Address is EUI-48
  [EUI-48] or EUI-64.
  So the change would follow the Bert’s guidance:
      capwapBaseWtpStateWtpBaseMacAddress  PhysAddress  (SIZE (6|8))
  Also,
  For the TC CapwapBaseStationIdTC and CapwapBaseWtpIdTC, the size should be:
  OCTET STRING (SIZE (6|8))

   [new issue]
  1) Also Bert raised another issue: Although the Reference of the
  capwapBaseWtpStateWtpBaseMacAddress tells the Section 4.6.40 in the RFC5415,
  it does not clearly tell that the MIB object corresponding to the sub
  element Base MAC Address in the RFC5415.
  [Editors]
  The description would be updated according to the Bert’s suggestion.

  capwapBaseWtpStateWtpBaseMacAddress  OBJECT-TYPE
     SYNTAX      PhysAddress (SIZE(6|8))
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Represents the WTP's Base MAC Address, which MAY be
          assigned to the primary Ethernet interface.
          The instance of the object corresponds to the Base MAC Address 
          sub-element in the CAPWAP protocol [RFC 5415]."
     REFERENCE
         "Section 4.6.40. of CAPWAP Protocol Specification, RFC 5415."

  The description of capwapBaseWtpBaseMacAddress would do a similar change.

  W:
  SMICng (strict checking) tells me:
  f(capwap-base.mi2), (974,17) Item "capwapBaseWtpBaseMacAddress" should have
  SIZE specified
  [Editors]
  According to the following text in the RFC5415，The MAC Address is EUI-48
  [EUI-48] or EUI-64.
  The change would follow the Bert’s guidance:
      capwapBaseWtpBaseMacAddress PhysAddress  (SIZE (6|8))

  W:
  SMICng (strict checking) tells me:
  f(capwap-base.mi2), (2038,17) Item "capwapBaseNtfStationIdList" should have
  SIZE specified
  [Editors]
  Suggest capwapBaseNtfStationIdList  OCTET STRING (SIZE (6..1024))
  Should the size give a minimal value 6? Thus, at least, it should contain
  one item of Station Id (EUI-48).
  [Bert]
  If an empty list is not allowed/wanted, then yep, do use a min size that can
  contain one element. But this is up to the WG to decide.
  [Status]
  Need WG confirm it.

  W:
  SMICng (strict checking) tells me:
  f(capwap-base.mi2), (1293,7) Row "capwapBaseStationEntry" does not have a
  consistent indexing sche
  me - cannot specify an index item from additional "base row"
  capwapBaseWtpEntry, since can have only
  one "base row" which is capwapBaseWirelessBindingEntry
  The INDEX is as follows:

     INDEX {
       capwapBaseWtpCurrId,
       capwapBaseWirelessBindingRadioId,
       capwapBaseStationId
     }

  The first one is the first index in another table
  The second one is the 2nd index in yet another table
  The 3rd one is an index (the 3rd one) in this table capwapBaseStaionTable.

  That is indeed some sort of weird indexing. So that is why SMICng gives a
  warning.
  It does not mean it is absolutely a fatal error. But it would be good that
  the CAPWAP
  WG checks if this is indeed the indexing they intended and wanted
  [Editors]
  To bert: I updated it here.
  I think the index is correct. 
  capwapBaseWtpCurrId is to indicate the Id of WTPs which are connecting to
  the AC.
  Another index capwapBaseWtpProfileId is together with
  capwapBaseWirelessBindingRadioId.
  capwapBaseWtpProfileId is to identify a WTP profile which would be used by a
  specific WTP (capwapBaseWtpCurrId). Since the relationship between
  capwapBaseWtpCurrId and capwapBaseWtpProfileId is 1:1,
  the index capwapBaseWtpProfileId + capwapBaseWirelessBindingRadioId could work together.

  So the index in such way should be ok.
  Yes, It would be better if the description could give some explain to the
  reason.
  Could you suggest the text for it? Thanks.

  W:
  SMICng (strict checking) tells me:
  f(capwap-base.mi2), (1509,13) Row "capwapBaseRadioEventsStatsEntry" does not
  have a consistent ind
  exing scheme - cannot specify an index item from additional "base row"
  capwapBaseWtpEntry, since can
  have only one "base row" which is capwapBaseWirelessBindingEntry

  Here the index objects are:

     INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId }

  That looks better, but again the the 2nd index is a 2nd index object in
  another
  table that gets added as the 2nd index here. Pls make sure this is what the
  WG intends and wants and that the indexing makes sense.

  For these "does not have a consistent indexing scheme" warnings, it would be
  good to add
  some comment lines to the MIB module that explain why this indexing is
  OK/INTENDED.
  Something like:

     -- The following indexing is intended because we want to show a table
  that
     -- ... here you text ...
     INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId }

  That way, when the SYNTAX check is done, and the MIB doctor checks the MIB
  module,
  then he can see the explanation and see that the indexing is indeed intended
  and nit
  inconsistent by accident.
   [Editors] same as above one.

  W:
  capwapBaseAcNameListRowStatus OBJECT-TYPE
     SYNTAX      RowStatus
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "This variable is used to create, modify, and/or delete a row
          in this table."
     ::= { capwapBaseAcNameListEntry 4 }

  I thought that a RowStatus object MUST describe if and under which
  conditions
  any writable (including read-create) objects can be modified if the row is
  Active?

  The same holds true for some (all?) other RowStatus objects
  [Editors]
  Yes,the description of RowStatus objects should be updated.       
         
  capwapBaseAcNameListRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object is used to create, modify, and/or delete a row 
           in this table.
           All the objects in a row can be modified only when the value
           of this object in the corresponding conceptual row is not
           ''active''. Thus to modify one or more of the objects in 
           this conceptual row,
                a. change the row status to ''notInService'',
                b. change the values of the row
                c. change the row status to ''active''
           The capwapBaseAcNameListRowStatus may be changed to ''active'' 
           if all the managed objects in the conceptual row with 
           MAX-ACCESS read-create have been assigned valid values."         
      ::= { capwapBaseAcNameListEntry 4 }
      
  capwapBaseMacAclRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object is used to create, modify, and/or delete a row 
           in this table.
           All the objects in a row can be modified only when the value
           of this object in the corresponding conceptual row is not
           ''active''. Thus to modify one or more of the objects in 
           this conceptual row,
                a. change the row status to ''notInService'',
                b. change the values of the row
                c. change the row status to ''active''
           The capwapBaseMacAclRowStatus may be changed to ''active'' 
           if all the managed objects in the conceptual row with 
           MAX-ACCESS read-create have been assigned valid values."               
      ::= { capwapBaseMacAclEntry 3 }
      
  capwapBaseWtpProfileRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object is used to create, modify, and/or delete a row
           in this table.
           The value of capwapBaseWtpProfileName can be changed when this 
           object is in state ''active'' or in ''notInService''
           The other objects in a row can be modified only when the value
           of this object in the corresponding conceptual row is not
           ''active''. Thus to modify one or more of the objects in 
           this conceptual row,
                a. change the row status to ''notInService'',
                b. change the values of the row
                c. change the row status to ''active''
           The capwapBaseWtpProfileRowStatus may be changed to ''active'' 
           if the managed objects capwapBaseWtpProfileName, 
           capwapBaseWtpProfileWtpMacAddr, 
           capwapBaseWtpProfileWtpModelNumber, capwapBaseWtpProfileWtpName 
           and capwapBaseWtpProfileWtpLocation in the conceptual row 
           have been assigned valid values. 
                   
           Deleting a WTP profile in use will disconnect the WTP to 
           the AC. So the network management system SHOULD
           ask the operator to confirm such an operation.
           When a WTP profile entry is removed from the table, 
           the corresponding WTP Virtual Radio Interfaces are also 
           removed from the CapwapBaseWirelessBindingTable and 
           ifTable [RFC2863].
           Also, the related object instances SHOULD be removed from
           the wireless binding MIB modules such as IEEE 802.11 
           MIB module [IEEE.802-11.2007]."
      ::= { capwapBaseWtpProfileEntry 21 }      

      Dot11 MIB:
      
  capwapDot11WlanRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This variable is used to create, modify, and/or delete a row
           in this table.
           All the objects in a row can be modified only when the value
           of this object in the corresponding conceptual row is not
           ''active''. Thus to modify one or more of the objects in 
           this conceptual row,
                a. change the row status to ''notInService'',
                b. change the values of the row
                c. change the row status to ''active''
           The capwapDot11WlanRowStatus may be changed to ''active'' 
           if all the managed objects in the conceptual row with 
           MAX-ACCESS read-create have been assigned valid values.         
           
           When the operator deletes a WLAN profile, the AC SHOULD 
           check whether the WLAN profile is bound with a radio. 
           If yes, the value of the Response-PDU's error-status field 
           is set to `inconsistentValue', and the value of its 
           error-index field is set to the index of the failed variable
           binding. If not, the row object could be deleted."
      ::= { capwapDot11WlanEntry 5 }   
          
  capwapDot11WlanBindRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This variable is used to create, modify, and/or delete a row
           in this table.
           All the objects in a row can be modified only when the value
           of this object in the corresponding conceptual row is not
           ''active''. Thus to modify one or more of the objects in 
           this conceptual row,
                a. change the row status to ''notInService'',
                b. change the values of the row
                c. change the row status to ''active''"      
      ::= { capwapDot11WlanBindEntry 3 }        
      
  w:
  capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
     SYNTAX      InetAddress
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "When capwapBaseWtpProfileWtpStaticIpEnable is true,
          it represents the static IP address to be assigned to the WTP."
     REFERENCE
         "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
  I thought that nay object of SYNTAX InetAddress MUST state in its
  DESCRIPTION
  clause which object of SYNTAX InetAddressType specifies the format?
  Further, it seems that "dns" is a valid InetAddressType. So in that case,
  the
  DESCRIPTION clauses MUST explain when the dns name is resolved.
  See RFC4001 for details.
  Same question for various other objects of SYNATX InetAddress.

  [Bert new comment]
  Also, Bert wonder why there are no IPv6 support on the
  capwapBaseWtpProfileWtpStaticIpType.
  I added a NOTEs in the description.

  [Editors]

  1) For capwapBaseWtpProfileWtpStaticIp

  The change would be:

  capwapBaseWtpProfileWtpStaticIpType OBJECT-TYPE
      SYNTAX      InetAddressType
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "Represents the static IP address type used by the WTP.
           Only ipv4(1) and ipv4z(3) are supported by the object.
           Although the CAPWAP protocol (RFC5415) supports both IPv4
           and IPv6, note that the CAPWAP field modelled by this 
           object does not support IPv6, so the object does not 
           support ipv6(2) and ipv6z(4)."
      REFERENCE
          "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."        
      ::= { capwapBaseWtpProfileEntry 8 }  
      
  capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
      SYNTAX      InetAddress
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "When capwapBaseWtpProfileWtpStaticIpEnable is true, 
           it represents the static IP address to be assigned to the WTP.
           The format of this IP address is determined by the 
           corresponding instance of object 
           capwapBaseWtpProfileWtpStaticIpType."
      REFERENCE
          "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
      ::= { capwapBaseWtpProfileEntry 9 }

  capwapBaseWtpProfileWtpNetmask OBJECT-TYPE
      SYNTAX      InetAddress
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "When capwapBaseWtpProfileWtpStaticIpEnable is true, 
           it represents the netmask to be assigned to the WTP.
           The format of this netmask is determined by the 
           corresponding instance of object 
           capwapBaseWtpProfileWtpStaticIpType."         
      REFERENCE
          "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
      ::= { capwapBaseWtpProfileEntry 10 }

  capwapBaseWtpProfileWtpGateway OBJECT-TYPE
      SYNTAX      InetAddress
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "When capwapBaseWtpProfileWtpStaticIpEnable is true, 
           it represents the gateway to be assigned to the WTP.
           The format of this IP address is determined by the 
           corresponding instance of object 
           capwapBaseWtpProfileWtpStaticIpType."        
      REFERENCE
          "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
      ::= { capwapBaseWtpProfileEntry 11 }

  2) For capwapBaseWtpStateWtpIpAddress
  The change would be:

  capwapBaseWtpStateWtpIpAddressType OBJECT-TYPE
      SYNTAX      InetAddressType
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "Represents the IP address type of a WTP.
           Only ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) and dns(16)
           are supported by the object."        
      ::= { capwapBaseWtpStateEntry 2 }    

  capwapBaseWtpStateWtpIpAddress OBJECT-TYPE
      SYNTAX      InetAddress
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "Represents the IP address of a WTP.
           The format of this IP address is determined by
           the corresponding instance of object 
           capwapBaseWtpStateWtpIpAddressType."
      ::= { capwapBaseWtpStateEntry 3 }

  W:
  capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
     SYNTAX      INTEGER {
                   limited(0),
                   fullAndLimited(1)
                 }
     MAX-ACCESS  read-create
     STATUS      current

  Normally we recommend that ENUMERATIONS do NOT start with zero, unless
  there is a good reason (which we then like to see in the DESCRIPTION
  clause).
  So... what is the reason?
  Same question for: capwapBaseWtpDiscoveryType
  And for: capwapBaseWtpEventsStatsLastFailureType
  And possibly others!! pls check.
  [Editors]
  There is a lot of capwap variables are defined using enumerated value
  start from 0, such as 4.6.21.  Discovery Type,  4.6.34.  Radio
  Operational State, 4.6.44.  WTP MAC Type...
  Just think using the same values as what defined in the capwap
  protocol will make the MIB easier to use.

  Would add a note in the description of the 
  capwapBaseWtpProfileWtpEcnSupport:

  capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
     SYNTAX      INTEGER {
                   limited(0),
                   fullAndLimited(1)
                 }
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "Represents the support for the Explicit Congestion Notification
          (ECN) bits, as defined in [RFC3168].
          The following enumerated values are supported:
            limited(0)        - Limited ECN support
            fullAndLimited(1) - Full and limited ECN support
          Note that the CAPWAP field [RFC 5415] modelled by this object
  takes zero as Starting value, this MIB object follows this rule."
     REFERENCE
         "Section 4.6.25. of CAPWAP Protocol Specification, RFC 5415."
     ::= { capwapBaseWtpProfileEntry 20 }

  A same chane change would be added to the following MIB objects:
  > CapwapBaseMacTypeTC
  > capwapBaseDataChannelDTLSPolicyConfig
  > capwapBaseWtpProfileWtpEcnSupport
  > capwapBaseWtpDiscoveryType
  > capwapBaseWtpEventsStatsLastFailureType
  > capwapBaseRadioEventsStatsLastFailType
  > capwapBaseNtfRadioOperStatusFlag
  > capwapBaseNtfRadioStatusCause

  [Bert new comments]
  Bert could live with starting at zero.I would still think it 
  be better to start at 1.
  But I leave it now up to Dan to decide.

  W:
  capwapBaseWtpEventsStatsInitCount OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Represents the number of reboots that have occurred at the
          request of a CAPWAP protocol message, such as a change in
          configuration that requires a reboot or an explicit CAPWAP
          protocol reset request.  A value of 65535 implies that this
          information is not available on the WTP."
     REFERENCE
         "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415."
     ::= { capwapBaseWtpEventsStatsEntry 2 }

  I do not believe that a SYNTAX of Counter32 allows any value (like the
  65535)to have a specific meaning !!!!! 
  This is impossible given the semantics for the Counter32 SYNTAX.

  Same for: capwapBaseWtpEventsStatsRebootCount
  and possibly others, pls check and make sure.

  [Editors]
  According to the suggestion in the CAPWAP mailing list, the change would be:
  capwapBaseWtpEventsStatsRebootCount OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "Represents the number of reboots that have occurred due to a
           WTP crash.
           Note that the CAPWAP field [RFC 5415] modelled by this counter
           takes the value 65535 to indicate that the information is not
  available
           on the WTP. This MIB object does not follow this behaviour which
           would not be standard in SMIv2. If the WTP does not have the
  information,
           the agent will not instantiate the object."
      REFERENCE
          "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415."
      ::= { capwapBaseWtpEventsStatsEntry 1 }

   A same change would be done to the capwapBaseWtpEventsStatsInitCount.

  W:
  I wonder if there is a risk of sending too many notifications in a very
  short time?
  IS there a way to control the rate of notifications?
  If the risk does not exist, then maybe some words about that would be good.
  [Editors]
  Yes, controls flags for the notification are necessary.
  Also, using "TruthValue" likes simple.

  The changes would be:

  -- Notification Control
  capwapBaseNotifyControlObjects OBJECT IDENTIFIER
      ::= { capwapBaseObjects 6 }

  capwapBaseChannelUpDownNotifyEnable  OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "Represents whether the Channel Up/Channel Down notification
           should be generated.
           A value of true(1) means that the notification is enabled
           A value of false(2) means that the notification is disabled"
      DEFVAL { false }
      ::= { capwapBaseNotifyControlObjects 1 }

  capwapBaseDecryptErrorNotifyEnable OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "Represents whether the decryption error notification should
           be generated.
           A value of true(1) means that the notification is enabled
           A value of false(2) means that the notification is disabled"
      DEFVAL { true }
      ::= { capwapBaseNotifyControlObjects 2 }

  capwapBaseJoinFailureNotifyEnable OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "Represents whether the notification of WTP join failure should
           be generated.
           A value of true(1) means that the notification is enabled
           A value of false(2) means that the notification is disabled"
      DEFVAL { true }
      ::= { capwapBaseNotifyControlObjects 3 }

  capwapBaseImageUpgradeFailureNotifyEnable OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "Represents whether the notification of WTP image upgrade 
           failure should be generated.
           A value of true(1) means that the notification is enabled
           A value of false(2) means that the notification is disabled"
      DEFVAL { true }
      ::= { capwapBaseNotifyControlObjects 4 }

  capwapBaseConfigMsgErrorNotifyEnable OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "Represents whether the notification of configuration message 
           error should be generated.
           A value of true(1) means that the notification is enabled
           A value of false(2) means that the notification is disabled"
      DEFVAL { false }
      ::= { capwapBaseNotifyControlObjects 5 }

  capwapBaseRadioOperableStatusNotifyEnable OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "Represents whether the notification of a radio's operational
           state change should be generated.
           A value of true(1) means that the notification is enabled
           A value of false(2) means that the notification is disabled"
      DEFVAL { false }
      ::= { capwapBaseNotifyControlObjects 6 }

  capwapBaseAuthenticationFailureNotifyEnable OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
         "Represents whether the notification of authentication failure
          should be generated.
          A value of true(1) means that the notification is enabled
          A value of false(2) means that the notification is disabled"
      DEFVAL { true }
      ::= { capwapBaseNotifyControlObjects 7 }
      
  In the Module compliance, the following changes are required.

   GROUP capwapBaseNotifyControlGroup
      DESCRIPTION
          "The capwapBaseNotifyControlGroup group is optional.
           If capwapBaseNotificationsGroup is supported,
           this group must be implemented."

  capwapBaseNotifyControlGroup OBJECT-GROUP
      OBJECTS {
        capwapBaseChannelUpDownNotifyEnable,
        capwapBaseDecryptErrorNotifyEnable,
        capwapBaseJoinFailureNotifyEnable,
        capwapBaseImageUpgradeFailureNotifyEnable,
        capwapBaseConfigMsgErrorNotifyEnable,
        capwapBaseRadioOperableStatusNotifyEnable,
        capwapBaseAuthenticationFailureNotifyEnable
     }
     STATUS  current
     DESCRIPTION
          "Objects used to enable or disable notifications."
     ::= { capwapBaseGroups 18 }

  W:
  In the MODULE-COMPLIANCE, I would have expected at least that some (or all)
  of
  the IF-MIB module would also be mandatory???!!!

  Section 7.2 of draft-ietf-capwap-base-mib-06.txt states that
        The IF-MIB module is required to be supported on the AC.

  So when I see a MODULE-COMPLIANCE, I would have expected something like:

  capwapBaseCompliance MODULE-COMPLIANCE
    STATUS current
    DESCRIPTION
        "Describes the requirements for conformance to the
         CAPWAP-BASE-MIB module."

    MODULE  IF-MIB
        MANDATORY-GROUPS {
             some mandatory groups from the IF-MIB, possibly all?
        }
    ... potentially some optional groups from IF-MIB as well?

    ... and then follow the MANDATORY GROUPS of THIS MODULE (the
  CAPWAP-BASE-MIB module)

    MODULE -- this module
      MANDATORY-GROUPS {
        capwapBaseAcNodeGroup,
        capwapBaseWtpProfileGroup,
        capwapBaseWtpStateGroup,
        capwapBaseWtpGroup,
        capwapBaseRadioGroup,
        capwapBaseStationGroup
      }

  For an example, see RFC3811, but also RFC3289

  But then, maybe if indeed the WHOLE IF-MIB MUST be supported, then just
  stating that
  may be OK.

   [Editors]
  The following change would be added:

      MODULE IF-MIB -- The interfaces MIB, RFC2863
      MANDATORY-GROUPS {
         ifGeneralInformationGroup
      }

  Regards
  Richard

------------------------------------------------------------------------------

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.716 / Virusdatabase: 270.14.113/2573 - datum van uitgifte: 12/18/09 08:35:00