Subject: [Capwap] The changes according to Bert's comments

From: shiyang 00338 <[email-masked]>
Date: Sun, 20 Dec 2009 16:38:13 +0800

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

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

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

---

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:

  W:

   [new issue]

  W:

  W:

  W:

     INDEX {
       capwapBaseWtpCurrId,

  W:

  W:

         

                   

      Dot11 MIB:

          
      
  w:

  [Bert new comment]

  [Editors]

  The change would be:

  W:

  [Bert new comments]

  W:

  [Editors]

  W:

  The changes would be:

  -- Notification Control

      

  W:

    MODULE  IF-MIB
        MANDATORY-GROUPS {

    MODULE -- this module
      MANDATORY-GROUPS {
        capwapBaseAcNodeGroup,

   [Editors]

  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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap