Subject: DISMAN-SCHEDULE-MIB Implementation Experiences

From: [email-masked]
Date: Wed, 2 Jun 1999 15:47:32 -0400 (EDT)

Hello,

I'm finally having a chance to share our implementation experience
with the DISMAN-SCHEDULE-MIB.  If I've overlooked specific questions
related to our implementation, please post the questions and I'll be 
glad to answer.  I will be unable to attend the DISMAN meetings in
Oslo and give a presentation, but I believe other of my colleagues 
will be at the IETF meeting, so it may be possible to arrange for
a presentation of our experiences if this is E-mail is insufficient.

We implemented <draft-ietf-disman-schedule-mib-06.txt>, and I've
just read RFC 2591 to refresh my memory and look for changes in
the document, as well as possible updates required to SNMPRI's 
implementation.

In a nutshell, the implementation went fairly well, and I cannot
recall any problems resulting from insufficient or conflicting,
or confusing statements in the specification itself.

We had implementation difficulties in two areas:

1.  For calendar-scheduled events, when sets are triggered, the
    execution time for the sequence of sets may be significant,
    and thus should be accounted for; and

2.  Properly handling the "ambiguous times"/"nonexistent times" issue.

Both of these difficulties were implementation-dependent, and do not
reflect deficiencies in the specification itself.  Fortunately for
our implementation, one of the authors (Dave Levi) helped sort these
issues out.  But future implementors may not (as I didn't) notice the 
subtleties of these issues.  These issues are hinted at in the spe-
cification, but more explanation or examples of these issues would 
help insure correct future implementations.

There are a couple of parts of the DISMAN-SCHEDULE-MIB specific-
ation that  1) make it more difficult to use that perhaps it could
be, and  2) reduce it's standalone versatility.

First, the use of SnmpAdminString row indices decreases the user-
friendliness of the DISMAN-SCHEDULE-MIB.  Requiring SnmpAdminString
row indices:

-  makes configuration of the DISMAN-SCHEDULE-MIB difficult with
   generic MIB browser/set tools;
-  mandates the use of configuration tools specialized for the 
   DISMAN-SCHEDULE-MIB; or
-  encourages DISMAN-SCHEDULE-MIB users to use very simple 
   schedOwner/schedName strings like "A" and "B".

Second, restricting the number/type of MIB objects that can be 
set at the scheduled time to a single Integer-type restricts 
the versatility of the DISMAN-SCHEDULE-MIB when used without 
the DISMAN-SCRIPT-MIB.  Removing this restriction would open
new uses for the DISMAN-SCHEDULE-MIB, especially in situations
where the DISMAN-SCRIPT-MIB is too heavyweight a solution for
simply setting, for example, an octet string or maybe creating
a row in a table and activating the row.  (It is nice that
other DISMAN MIBs under development are considering the 
possibility of time-schedulng and providing integer triggers
in these MIBs.)

We have demonstrationed our DISMAN-SCHEDULE-MIB implementation, 
including kicking off scripts in our DISMAN-SCRIPT-MIB implement-
ation.   This scenario does work.  

We have also experimented with high-frequency periodic sets.  Not
surprisingly, we re-discovered the basic queuing theory idea that
if the mean time between periodic sets is shorter than the mean 
time to service the sets, infinite queues can result.  Adding a
cautionary note to the DISMAN-SCHEDULE-MIB specification about
possible undesirable side effects of high-frequency periodic sets
may help future implementors and users avoid surprises.

We have not tested interoperability with other implementations.

All in all, RFC 2591 appears to be implementable, workable, and
have utility.  Although I believe changes to the specification
would make the DISMAN-SCHEDULE-MIB easier to use and increase
it's utility, I believe RFC 2591 can be advanced further in the
standards process.  The DISMAN-SCHEDULE-MIB is fairly simple
and has utility apart from other MIBs (e.g., the DISMAN-SCRIPT-MIB
or the event MIB), and I can see no compelling reason to ditch
RFC 2591 and merge its functionality with another MIB.

Regards,
--Alan

 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------