Subject: Re: [MIB-DOCTORS] The reply to Bert's comment

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 16 Dec 2009 11:15:13 +0100

My comments/reactions/answers inline

young wrote:
> Hi, Bert:
>
> Thanks. Here I give a list of changes should be made.
> Since I have to take a business trip, I have to keep 
> two issues open.
>
> 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 be: 
> capwapBaseWtpStateWtpBaseMacAddress  PhysAddress  (SIZE (8))
>   

If it can be EITHER EUO48 or EUI64, then it sounds to me that the size
must be either
6 or 8. Any other size seems then invalid, right?

So the way to specify that would be:

     capwapBaseWtpStateWtpBaseMacAddress  PhysAddress  (SIZE (6|8))

> Also, I think size of CapwapBaseStationIdTC, CapwapBaseWtpIdTC should be 8.
> My doubt:
> Whether is it required to add a new MIB object to specify the MAC address
> type? EUI-48 or EUI-64. I am not sure.
>
>   
It seems that if the above PhysAddress is used, that one can determine
from the
actual size of the instance of an object if it is EUI48 or EUI 64, no?

> [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. 
> For the reference part, is there any common rule in the IETF? 
> Do we need to update the Reference like:
>     REFERENCE
>         " The sub-element Base MAC Address in the Section 4.6.40. of CAPWAP
> Protocol Specification, RFC 5415."
> If we follow this change (or similar), lots of changes for other references
> are required.
>
>   

I think the reference should just be to the section 4.6.0.
In the DESCRIPTION clause of the MIB object, you can describe what piece of
the spec, namely the sub-element, is to be represented in the object.

> 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.
> So the change would be: capwapBaseWtpBaseMacAddress PhysAddress  (SIZE (8))
>
>   
see above
> 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).
>
>   

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.
> 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] 
> 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. 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.
>
>   
Not sure it is clear to me yet.
Is it clear to other CAPWAP WG participants?

> 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. It should be modified. Since I would take business trip, I have to give
> the text after I got back.  We keep it open.
>
>   

ok, will wait for the results to come in later
> 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."
>     ::= { capwapBaseWtpProfileEntry 9 }
>
>
> 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.
> [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.
> The object supports the value of ipv4(1) and ipv4z(3), and does not
> support the value of unknown(0) , ipv6(2) , ipv6z(4) and dns(16) ."
>     ::= { capwapBaseWtpProfileEntry 8 }
>
>   
If that is what you want, then you would do something like

capwapBaseWtpProfileWtpStaticIpType OBJECT-TYPE
    SYNTAX      InetAddressType {ipv4(1), ipv4z(3)}
    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 CAPWAP."
     ::= { capwapBaseWtpProfileEntry 8 }

You may get in trouble now... because WHY would you not support IPv6 ???
Does CAPWAP not support IPv6? If not, then I suggest you add an explanation
that states so. That explains it, and so if the base CAPWAP protocol has
been
approved without IPv6 support, then not supporting it in the MIB module is
fine too I think.

Another way to do this, is to just keep

    SYNTAX      InetAddressType

And then in the MODULE compliance specify that only ipv4 needs to be supported.
That way, the MIB module itself is prepared for IPv6, and if such ipv6 support is
ever needed in the future, then it is just a matter of adding/defining a new 
MODULE-COMPLIANCE without any changes to teh MIB module itself.

> * Please refer to the Section 4.6.48 in the RFC5415.
>
> Add “The IP address type supported is specified by the
> capwapBaseWtpProfileWtpStaticIpType”.
>
> 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 IP address type supported is specified by the
> 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 IP address type supported is specified by the
> 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 IP address type supported is specified by the 
> capwapBaseWtpProfileWtpStaticIpType."
>     REFERENCE
>         "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseWtpProfileEntry 11 }
>
>   
the above is good, although I think I would state it different
instead of

     The IP address type supported is specified by the 
     capwapBaseWtpProfileWtpStaticIpType."

I think I would write

     The format of this IP address is determined by the corresponding
     instance of object  capwapBaseWtpProfileWtpStaticIpType."

So... it is not about "what is supported", it is how one can determine
what the
format of an instance of the InetAddress object is.
> 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.
> The object supports the value of ipv4(1) , ipv6(2) , ipv4z(3), ipv6z(4) and
> dns(16), and does not support the value of unknown(0) ."
>     ::= { capwapBaseWtpStateEntry 2 }
>
>   

see above
> capwapBaseWtpStateWtpIpAddress OBJECT-TYPE
>     SYNTAX      InetAddress
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>         "Represents the IP address of a WTP. The IP address type is 
> specified by the capwapBaseWtpStateWtpIpAddressType. "
>     ::= { capwapBaseWtpStateEntry 3 }
>
>   

see above
> 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 }
>
>   
Dan Romascanu can tell you if this is acceptable.
Given the addition of the xaplantion, I can live with it.

> 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.
>
>   
sounds OK to me.

> 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.
> The changes would be:
>
> -- for notifications
>
> capwapBaseNotifyControlObjects OBJECT IDENTIFIER
>     ::= { capwapBaseObjects 6 }
>
>
> capwapBaseChannelUpDownNotifyEnable  OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   enabled(1),
>                   disabled(2)
>                 }
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             " Represents whether the Channel Up/Channel Down notification
> should be generated.
>            The following enumerated values are supported:
>              enabled(1)  - The notification is enabled
>              disabled(2) - The notification is disabled
>     DEFVAL { disabled }
>     ::= { capwapBaseNotifyControlObjects 1 }
>
> capwapBaseDecryptErrorNotifyEnable OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   enabled(1),
>                   disabled(2)
>                 }
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             " Represents whether the decryption error notification should be
> generated.
>              The following enumerated values are supported:
>              enabled(1)  - The notification is enabled
>              disabled(2) - The notification is disabled
>     DEFVAL { enabled }
>     ::= { capwapBaseNotifyControlObjects 2 }
>
> capwapBaseJoinFailureNotifyEnable OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   enabled(1),
>                   disabled(2)
>                 }
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             " Represents whether the notification of WTP join failure should
>
> be generated.
>            The following enumerated values are supported:
>              enabled(1)  - The notification is enabled
>              disabled(2) - The notification is disabled
>     DEFVAL { enabled }
>     ::= { capwapBaseNotifyControlObjects 3 }
>
> capwapBaseImageUpgradeFailureNotifyEnable OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   enabled(1),
>                   disabled(2)
>                 }
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             " Represents whether the notification of WTP image upgrade
> failure 
> should be generated.
>             The following enumerated values are supported:
>              enabled(1)  - The notification is enabled
>              disabled(2) - The notification is disabled
>     DEFVAL { enabled }
>     ::= { capwapBaseNotifyControlObjects 4 }
>
> capwapBaseConfigMsgErrorNotifyEnable OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   enabled(1),
>                   disabled(2)
>                 }
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             " Represents whether the notification of configuration message
> error 
> should be generated.
>              The following enumerated values are supported:
>              enabled(1)  - The notification is enabled
>              disabled(2) - The notification is disabled
>     DEFVAL { disable }
>     ::= { capwapBaseNotifyControlObjects 5 }
>
> capwapBaseRadioOperableStatusNotifyEnable OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   enabled(1),
>                   disabled(2)
>                 }
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             " Represents whether the notification of a radio's operational
> state 
> change should be generated.
>              The following enumerated values are supported:
>              enabled(1)  - The notification is enabled
>              disabled(2) - The notification is disabled
>     DEFVAL { disable }
>     ::= { capwapBaseNotifyControlObjects 6 }
>
> capwapBaseAuthenticationFailure NOTIFICATION-TYPE
>     SYNTAX      INTEGER {
>                   enabled(1),
>                   disabled(2)
>                 }
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             " Represents whether the notification of authentication failure 
> should be generated.
>              The following enumerated values are supported:
>              enabled(1)  - The notification is enabled
>              disabled(2) - The notification is disabled
>     DEFVAL { disable }
>     ::= { capwapBaseNotifyControlObjects 7 }
>
>   

Wow, that are a lot of toggles. I can live with it.
I could live with fewer toggles that enable/disable (a) set(s) of
notifications.
Up to the the editors and the WG.

Once comment on the above toggles. Might it be better to re-use the TC
TruthValue
from RFC2579? So instead of

(missing "Enable" from the next one??)

     capwapBaseAuthenticationFailure NOTIFICATION-TYPE
         SYNTAX      INTEGER {
                     enabled(1),
                     disabled(2)
                     }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "Represents whether the notification of authentication failure 
             should be generated.
             The following enumerated values are supported:
             enabled(1)  - The notification is enabled
             disabled(2) - The notification is disabled
        DEFVAL { disable }
        ::= { capwapBaseNotifyControlObjects 7 }

you could do:

     capwapBaseAuthenticationFailureEnabled NOTIFICATION-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 { false }
         ::= { capwapBaseNotifyControlObjects 7 }

I happen to like re-use of SYNTAX/TC if possible.
But defining your own enumeration does work too.,

Some of the ...Enable objects do not have a DEFVAL ??
Is that intentional?

>   
> 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,
> capwapBaseAuthenticationFailure
>     }
>     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] 
> Yes. Since I would take business trip, I have to give the text after I got
> back. We keep it open.
>
>   

OK

Bert
> Regards
> Richard