Re: DISMAN MIB implementation summaries

Hi -

Thanks!  I especially appreciate the detailed comments
provided, and would like to initiate some (separate) follow-up
threads on them.  This is the kind of useful feedback we need.

Randy

> From: "Steve Moulton" <[email protected]>
> To: <[email protected]>
> Sent: Thursday, June 17, 2004 12:40 PM
> Subject: [Disman] DISMAN MIB implementation summaries
>
> The following are implementation summaries for the DISMAN MIBs
> implemented in SNMP Research products.  We do not implement the
> Notification Log or Expression MIBs.  See the end of this message for
> more deployment information.
>
> The summaries were prepared by Alan Luchuk and Brian Beach of the
> SNMP Research Staff.
>
> ----------------------------------------------------------------------
>
> Implementation Survey for RFC 3165
> Definition of Managed Objects for the Delegation of Management Scripts
> Module:  DISMAN-SCRIPT-MIB
>
>
> GROUPS:
> smLanguageGroup:        Implemented
> smScriptGroup2:         Implemented
> smLaunchGroup2:         Implemented
> smRunGroup2:            Implemented
> smNotificationsGroup2:  smScriptAbort      implemented
>                         smScriptResult     implemented
>                         smScriptException  not implemented
> smCodeGroup:            Implemented
>
>
> OBJECTS:
> smScriptSource:     read-only
> smCodeText:         read-write
> smLaunchArgument:   maximum size 2048
> smRunArgument:      maximum size 2048
> smRunResult:        maximum size 2048
> smRunState suspension permitted:   yes
>
>
> Deployment/Operational experience:
>
> The DISMAN-SCRIPT-MIB is implementable, does work, and can be used
> for network management, although it is, shall we say, "MIB Object rich".
>
> The lengthy description clauses that describe the interlocking states bet-
> ween tables makes it difficult to insure the implementation conforms to the
> specification.
>
> In some cases, the documented behavior is counter-intuitive.  For example,
> an intuitive behavior for 'destroying' a row in the smScriptTable would be
> to delete the row and all subordinate references to it (from the smCodeTable,
> the smLaunchTable, and smRunTable).  But the MIB appears to not allow this.
> To 'destroy' a row in the smScriptTable, the following procedure must be
> followed:
>
> -  terminate all subordinate running instances from the smRunTable;
> -  disable (or expire) all subordinate smLaunchEntries;
> -  'destroy' all subordinate smLaunchEntries;
> -  disable the 'smScriptAdminStatus';
> -  'destroy' the smScriptEntry;
>
> The MIB allows instrumenting, launching, suspending, and restarting programs
> in a multi-process operating system.  This capability adds much more complex-
> ity and agent code size than is necessary to support distributed network
> management, which seems more  likely to need to run fairly modest scripts
> that start and run perpetually.  The added complexity and code size is likely
> to reduce the the number of implementations and actual field deployment.
>
> ----------------------------------------------------------------------
>
> Implementation Survey for RFC 3231
> Definition of Managed Objects for Scheduling Management Operations
> Module:  DISMAN-SCHED-MIB
>
> GROUPS:
> schedGroup2:               implemented
> schedNotificationsGroup:   implemented
> schedCalendarGroup:        implemented, on systems that support time of day
>
>
> Deployment/Operational experience:
>
> The DISMAN-SCHED-MIB is implementable, does work, and can be used
> for network management.
>
> ----------------------------------------------------------------------
>
> Implementation Survey for RFC 2981
> Event MIB
> Module:  DISMAN-EVENT-MIB
>
>
> Implementation Survey for RFC 2981, Event MIB
>
> Module: DISMAN-EVENT-MIB
> Implementation Source: SNMP Research
> Management Application / Agent: CIAgent
>
> GROUPs:
> dismanEventResourceGroup (y/n): y
> dismanEventTriggerGroup (y/n): y
> dismanEventObjectsGroup (y/n): y
> dismanEventEventGroup (y/n): y
> dismanEventNotificationObjectGroup (y/n): y
> dismanEventNotificationGroup (y/n): y
>
> OBJECTs:
> mteTriggerTargetTag (ro/rw): ro
> mteEventSetTargetTag (ro/rw): ro
> mteTriggerValueIDWildcard (ro/rw): rw
> mteTriggerContextNameWildcard (ro/rw): ro
> mteObjectsIDWildcard (ro/rw): ro
> mteEventSetContextNameWildcard (ro/rw): ro
>
>
> Deployment / Operational Experience:
>
>
> Comments:
>
>
> ----------------------------------------------------------------------
>
>
> Implementation Survey for RFC 2925
> DISMAN Remote Operation MIBs
> Module:  DISMAN-NSLOOKUP-MIB, DISMAN-PING-MIB, and DISMAN-TRACEROUTE-MIB
>
>
> Implemented DISMAN-NSLOOKUP-MIB, DISMAN-PING-MIB,
> DISMAN-TRACEROUTE-MIB as part of SNMP Research's
> Service Monitor product to provide remote management of nslookup, ping,
> and traceroute services.
>
> Capabilities - We support all objects of these three MIB Modules with
> the following exceptions:
>
> DISMAN-PING-MIB:
>
>       pingCtlTargetAddressType - Does not support IPv6
>       pingCtlDataFill - Not implemented
>       pingCtlType - Only value allowed is pingIcmpEcho
>       pingCtlSourceAddress - Not implemented
>       pingCtlIfIndex - Not implemented
>       pingCtlByPassRouteTable - Not implemented
>       pingCtlDSField - Not implemented
>
> DISMAN-TRACEROUTE-MIB
>
>       traceRouteCtlTargetAddressType - Does not support IPv6
>       traceRouteCtlByPassRouteTable - Not implemented
>       traceRouteCtlDSField - Not implemented
>       traceRouteCtlSourceAddress - Not implemented
>       traceRouteCtlIfIndex - Not implemented
>       traceRouteCtlDontFragment - Not implemented
>       traceRouteCtlTrapGeneration - pathChange not implemented
>       traceRouteCtlType - Default is using UDP Probes. Only implemented
>               to use ICMP ECHO
>
> DISMAN-NSLOOKUP-MIB
>
>       lookupCtlTargetAddressType - Does not support IPv6
>
>
> SNMP Research has no immediate plans to add support to the above MIB
> objects on our roadmap.
>
> We support the Service Monitor product including the REMOPS MIBs on
> Windows (NT, XP, 2000),  Solaris 2.x (32, 64-bit), and Red Hat Linux.
>
> ----------------------------------------------------------------------
>
> General Summary
> ---------------
>
> The DISMAN-SCHEDULE-MIB, DISMAN-SCRIPT-MIB, and DISMAN-EVENT-MIB have
> been implemented by SNMP Research, Inc. and included as parts of the
> CIAgent product.  CIAgent may be freely downloaded from the SNMP Research
> web site for evaluation and interoperability test.  The remops-related
> MIBs are an optional, extra-cost feature of CIAgent, and are not available
> for download.
>
> Since the CIAgent product was first introduced several years ago, SNMP
> Research, International, Inc., sales reports hundreds of customers have
> licensed and deployed thousands of copies of CIAgent.  Because the remops-
> related MIBs are an extra-cost feature of CIAgent, their actual licensing
> and deployment are lower than that of the standard CIAgent components.
>
> SNMP Research has internal deployment experience typical for a software
> development company, that is deployment for internal testing, trade show
> demos, etc.  However, the SNMP Research, Inc., Technical Support group
> does provide support to customers about the DISMAN MIBs implemented in
> CIAgent, and does receive feedback from customer deployments.
>
> SNMP Research, Inc., Technical Support has received no questions about the
> DISMAN-SCHEDULE-MIB.  SNMP Research, Inc., Technical Support has received
> questions about the DISMAN-EVENT-MIB from a few customers.  SNMP Research,
> Inc., Technical Support has received questions about the DISMAN-SCRIPT-MIB
> from a few customers.  Many of these questions concern the SNMP Research
> proprietary SNMP scripting language.  SNMP Research, Inc., Technical Support
> has received no questions about the remops-related MIBs, but again, their
> deployment numbers are much lower because it is a extra-cost feature.
>
> Feedback from our customers is that they typically find the DISMAN MIBs too
> complex and difficult-to-understand because of the multiple tables and
> relationships defined between the tables.  Maintaining the configurations
> proves difficult because of the complexity of the configurations and the
> learning curve required to understand these MIBs.
>
>
> ---
> SNMP Research, Inc            voice: +1 865 573 1434
> 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
> Knoxville, TN 37920-9716 USA  http://www.snmp.com
>
>
>
>
>
>