Subject: e: RFC 2591 (schedule MIB) implementations

From: Alan Luchuk <[email-masked]>
Date: Wed, 5 Apr 2000 13:17:17 -0400 (EDT)

Hello all,

>Hi -
>
>It's time to consider whether we'll be ready to request that
>the RFC 2591 Schedule MIB be advanced from "Proposed Standard"
>to "Draft Standard."  As a memory refresher, here are the
>requirements from RFC 2026:
>
>|4.1.2  Draft Standard
>|
>|   A specification from which at least two independent and interoperable
>|   implementations from different code bases have been developed, and
>|   for which sufficient successful operational experience has been
>|   obtained, may be elevated to the "Draft Standard" level.  For the
>|   purposes of this section, "interoperable" means to be functionally
>|   equivalent or interchangeable components of the system or process in
>|   which they are used.  If patented or otherwise controlled technology
>|   is required for implementation, the separate implementations must
>|   also have resulted from separate exercise of the licensing process.
>|   Elevation to Draft Standard is a major advance in status, indicating
>|   a strong belief that the specification is mature and will be useful.
>|
>|   The requirement for at least two independent and interoperable
>|   implementations applies to all of the options and features of the
>|   specification.  In cases in which one or more options or features
>|   have not been demonstrated in at least two interoperable
>|   implementations, the specification may advance to the Draft Standard
>|   level only if those options or features are removed.
>|
>|   The Working Group chair is responsible for documenting the specific
>|   implementations which qualify the specification for Draft or Internet
>|   Standard status along with documentation about testing of the
>|   interoperation of these implementations.  The documentation must
>|   include information about the support of each of the individual
>|   options and features.  This documentation should be submitted to the
>|   Area Director with the protocol action request. (see Section 6)
>|
>|   A Draft Standard must be well-understood and known to be quite
>|   stable, both in its semantics and as a basis for developing an
>|   implementation.  A Draft Standard may still require additional or
>|   more widespread field experience, since it is possible for
>|   implementations based on Draft Standard specifications to demonstrate
>|   unforeseen behavior when subjected to large-scale use in production
>|   environments.
>|
>|   A Draft Standard is normally considered to be a final specification,
>|   and changes are likely to be made only to solve specific problems
>|   encountered.  In most circumstances, it is reasonable for vendors to
>|   deploy implementations of Draft Standards into a disruption sensitive
>|   environment.
>
>I think we will be able to meet these requirements.
>
>I know of two Schedule MIB implementations.  I would like the
>implementors to fill me in on the details of their implementations
>with respect to the requirements above, e.g., whether any objects
>not implemented.

I believe SNMP Research's DISMAN-SCHEDULE-MIB implementation implements 
all of the MIB objects in RFC 2591.

I believe the DISMAN-SCHEDULE-MIB is stable and useful.  SNMP Research
has tested/demonstrated an implementation.   I do not know if there has 
been enough actual field experience to identify "unforseen behavior".
Although it would be my personal desire to advance the standard, I am
uncomfortable doing so based upon the text in the next-to-last paragraph.

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

   Note:  Our area code changed to 865 from 423 in November.  If you have
   trouble reaching us via area code 865, please try the old area code (423) 
   and let us know.  Both area codes should work until April.