As per Relevance of the word implementation, we have this rfc below:
Network Working Group M. O'
Request for Comments: 2438 UUNET
BCP: 27 H.
Category: Best Current Practice
B.
IBM T. J. Watson
S.
Harvard
October 1998
Advancement of MIB specifications on the IETF Standards
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
2.
The Internet Standards Process [1] requires that all IETF
Track specifications must have "multiple, independent,
interoperable implementations" before they can be advanced
Proposed Standard status. This document specifies the process
the IESG will use to determine if a MIB specification document
these requirements. It also discusses the rationale for
process
3. The Nature of the
The Internet Standards Process [1] requires that for an
specification to advance beyond the Proposed Standard level, at
two genetically unrelated implementations must be shown
interoperate correctly with all features and options. There are
distinct reasons for this requirement
The first reason is to verify that the text of the specification
adequately clear and accurate. This is demonstrated by showing
multiple implementation efforts have used the specification
achieved interoperable implementations
O'Dell, et. al. Best Current Practice [Page 1]
RFC 2438 Advancement of MIB specifications October 1998
The second reason is to discourage excessive options and "
creep". This is accomplished by requiring
implementation of all features, including options. If an option
not included in at least two different interoperable implementations
it is safe to assume that it has not been deemed useful and must
removed before the specification can advance
In the case of a protocol specification which specifies the "bits
the wire" exchanged by executing state machines, the notion
"interoperability" is reasonably intuitive - the implementations
successfully "talk to each other", exchanging "bits on the wire",
while exercising all features and options
In the case of an SNMP Management Information Base (MIB
specification, exactly what constitutes "interoperation" is
obvious. This document specifies how the IESG has decided to
"MIB specification interoperability" in the context of the
Standards Process
There are a number of plausible interpretations of MIB
interoperability, many of which have merit but which have
different costs and difficulties in realization
The aim is to ensure that the dual goals of specification clarity
feature evaluation have been met using an interpretation of
concept of MIB specification interoperability that strikes a
between testing complexity and practicality
4. On The Nature of MIB
Compared to "state machine" protocols which focus on
specifications, a MIB specification is much more data oriented.
over-generalize, in a typical MIB specification the collection
data type and instance specifications outnumbers inter-
procedural or causal semantics by a significant amount
A central issue is that a MIB specification does not stand alone;
forms the access interface to the instrumentation underneath it
Without the instrumentation, a MIB has form but no values.
with the large number of objects even in a simple MIB specification
a MIB specification tends to have more of the look and feel of an
or a dictionary than a state machine protocol
It is important to distinguish between assessing the
of applications which may use or interact with MIBs, and the
themselves. It is fairly obvious that "black-box testing" can
O'Dell, et. al. Best Current Practice [Page 2]
RFC 2438 Advancement of MIB specifications October 1998
applied to such applications and that the approach enjoys a
maturity in the software engineering arts. A MIB specification,
the other hand is not readily amenable to black box test plans
5. Discussion and Recommended
In order to meet their obligations under the IETF Standards Process
the Operations and Management Area Directors and the IESG must
convinced that each MIB specification advanced to Draft Standard
Internet Standard status is clearly written, that there are
required multiple interoperable implementations, and that all
have been implemented. There are multiple ways to achieve this goal
Appendix A lists some testing approaches that could be used
attempting to document multiple implementations
The Full Coverage or Stimulus-Response approaches are very through
and would increase confidence that the requirement has been met,
applied. However, experience in real-world software
makes it clear that such confidence comes at an extremely high price
even with the most exhaustive testing, it is often not clear
precisely has been demonstrated by such testing. We believe
both of those standards of evidence are materially beyond what can
reasonably accomplished in an operational sense, and achieving
requisite semantic specifications are even more unlikely
Therefore, the Operations and Management Area and the IESG
adopted a more pragmatic approach to determining the suitability of
MIB specification for advancement on the standards track
Proposed Standard status. Each MIB specification suggested
advancement must have one or more advocates who can make a
argument that the MIB specification meets the multiple
and feature support requirements of the IETF Standards Process.
specific way to make the argument is left to the advocate, but
normally include reports that basic object comparison testing
been done
Thus any recommendation for the advancement of a MIB
must be accompanied by an implementation report, as is the case
all requests for the advancement of IETF specifications.
implementation report must include the reasons why the IESG
believe that there are multiple implementations of the
specification in question and that the all of the MIB objects in
specification to be advanced are supported in more than
implementation. But note that the prime concern of the IESG will
that the underlying reasons for the interoperable implementations
met, i.e., that the text of the specification is clear
unambiguous, and that features of the specification which have
garnered support have been removed
O'Dell, et. al. Best Current Practice [Page 3]
RFC 2438 Advancement of MIB specifications October 1998
The implementation report will be placed on the IETF web page
with the other pre-advancement implementation reports and will
specifically referred to in the IETF Last-Call. As with all
implementation reports, the determination of adequacy is made by
Area Director(s) of the relevant IETF Area. This determination
adequacy can be challenged during the Last-Call period
6. Security
Some may view this policy as possibly leading to a reduction in
level of confidence people can have in MIB specifications but the O&
Area Directors and the IESG feel that it will adequately ensure
reasonable evaluation of the level of clarity of MIB
and to ensure that unused options can be identified and
before the advancement of a specification
Good, clearly written MIB specifications can be of great
in the management of the Internet and other networks and thus
in the reduction of some types of security threats
8.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
O'Dell, et. al. Best Current Practice [Page 4]
RFC 2438 Advancement of MIB specifications October 1998
9. Authors'
Michael D. O'
UUNET Technologies, Inc
3060 Williams
Fairfax, VA 22031
Phone: +1-703-206-5890
EMail: mo@uu.
Harald T.
N-7005 Trondheim,
Phone: +47-73-54-57-94
EMail: Harald.Alvestrand@maxware.
Bert
IBM T. J. Watson
Schagen 33
3461 GL
Phone: +31-348-432-794
EMail: wijnen@vnet.ibm.
Scott
Harvard
1350 Mass. Ave
Cambridge MA 02138
Phone: +1-617-495-3864
EMail: sob@harvard.
O'Dell, et. al. Best Current Practice [Page 5]
RFC 2438 Advancement of MIB specifications October 1998
Appendix
A. Some Testing
The IESG debated a number of interoperability and testing models
formulating this specification. The following list is not
exhaustive enumeration of the alternatives, but it does capture
major plausible models which were examined in the course of
discussion
A.1 Basic Object
Assume the requisite two genetically unrelated implementations of
MIB in an SNMP agent and an SNMP management station which can do
"MIB Dump" (extract the complete set of MIB object types and
from the agent implementation). Extract a MIB Dump from
implementation and compare the two dumps to verify that both
the complete set of mandatory and optional objects and that
individual objects are of the correct types
A.2 Stimulus/Response
Proceed as in A.1, but in addition, comprehensively exercise the
(network) elements containing the agent implementations to
that all the MIB objects reflect plausible values in
conditions. An even stricter interpretation would require that
MIB objects in the two network elements track identically given
identical stimulus. While this would test "read-only"
"monitoring" information obtained from the
instrumentation, it is important to observe that such
is actually an *application* which uses the MIB and is not part
the MIB itself
A.3 Full Coverage
This model extends the notion of Stimulus/Response Testing to
logical extreme. The MIB is viewed as an API and the
engineering notion of full coverage testing is applied to a MIB
This involves exercising all paths through the causal semantics
verifying that all objects change state correctly in all cases
Again, note that much more than the MIB definition is being
and evaluated
O'Dell, et. al. Best Current Practice [Page 6]
RFC 2438 Advancement of MIB specifications October 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
O'Dell, et. al. Best Current Practice [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
