From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2438.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2438.txt (limited to 'doc/rfc/rfc2438.txt') diff --git a/doc/rfc/rfc2438.txt b/doc/rfc/rfc2438.txt new file mode 100644 index 0000000..17cdbf6 --- /dev/null +++ b/doc/rfc/rfc2438.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group M. O'Dell +Request for Comments: 2438 UUNET Technologies +BCP: 27 H. Alvestrand +Category: Best Current Practice Maxware + B. Wijnen + IBM T. J. Watson Research + S. Bradner + Harvard University + October 1998 + + + Advancement of MIB specifications on the IETF Standards Track + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +2. Abstract + + The Internet Standards Process [1] requires that all IETF Standards + Track specifications must have "multiple, independent, and + interoperable implementations" before they can be advanced beyond + Proposed Standard status. This document specifies the process which + the IESG will use to determine if a MIB specification document meets + these requirements. It also discusses the rationale for this + process. + +3. The Nature of the Problem + + The Internet Standards Process [1] requires that for an IETF + specification to advance beyond the Proposed Standard level, at least + two genetically unrelated implementations must be shown to + interoperate correctly with all features and options. There are two + distinct reasons for this requirement. + + The first reason is to verify that the text of the specification is + adequately clear and accurate. This is demonstrated by showing that + multiple implementation efforts have used the specification to + 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 "feature + creep". This is accomplished by requiring interoperable + implementation of all features, including options. If an option is + not included in at least two different interoperable implementations, + it is safe to assume that it has not been deemed useful and must be + removed before the specification can advance. + + In the case of a protocol specification which specifies the "bits on + the wire" exchanged by executing state machines, the notion of + "interoperability" is reasonably intuitive - the implementations must + 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 less + obvious. This document specifies how the IESG has decided to judge + "MIB specification interoperability" in the context of the IETF + Standards Process. + + There are a number of plausible interpretations of MIB specification + interoperability, many of which have merit but which have very + different costs and difficulties in realization. + + The aim is to ensure that the dual goals of specification clarity and + feature evaluation have been met using an interpretation of the + concept of MIB specification interoperability that strikes a balance + between testing complexity and practicality. + +4. On The Nature of MIB specifications + + Compared to "state machine" protocols which focus on procedural + specifications, a MIB specification is much more data oriented. To + over-generalize, in a typical MIB specification the collection of + data type and instance specifications outnumbers inter-object + procedural or causal semantics by a significant amount. + + A central issue is that a MIB specification does not stand alone; it + forms the access interface to the instrumentation underneath it. + Without the instrumentation, a MIB has form but no values. Coupled + 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 API + or a dictionary than a state machine protocol. + + It is important to distinguish between assessing the interoperability + of applications which may use or interact with MIBs, and the MIBs + themselves. It is fairly obvious that "black-box testing" can be + + + + + +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 certain + maturity in the software engineering arts. A MIB specification, on + the other hand is not readily amenable to black box test plans. + +5. Discussion and Recommended Process + + In order to meet their obligations under the IETF Standards Process, + the Operations and Management Area Directors and the IESG must be + convinced that each MIB specification advanced to Draft Standard or + Internet Standard status is clearly written, that there are the + required multiple interoperable implementations, and that all options + have been implemented. There are multiple ways to achieve this goal. + Appendix A lists some testing approaches that could be used when + 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, if + applied. However, experience in real-world software engineering + makes it clear that such confidence comes at an extremely high price; + even with the most exhaustive testing, it is often not clear what + precisely has been demonstrated by such testing. We believe that + both of those standards of evidence are materially beyond what can be + reasonably accomplished in an operational sense, and achieving the + requisite semantic specifications are even more unlikely. + + Therefore, the Operations and Management Area and the IESG have + adopted a more pragmatic approach to determining the suitability of a + MIB specification for advancement on the standards track beyond + Proposed Standard status. Each MIB specification suggested for + advancement must have one or more advocates who can make a convincing + argument that the MIB specification meets the multiple implementation + and feature support requirements of the IETF Standards Process. The + specific way to make the argument is left to the advocate, but will + normally include reports that basic object comparison testing has + been done. + + Thus any recommendation for the advancement of a MIB specification + must be accompanied by an implementation report, as is the case with + all requests for the advancement of IETF specifications. The + implementation report must include the reasons why the IESG should + believe that there are multiple implementations of the MIB + specification in question and that the all of the MIB objects in the + specification to be advanced are supported in more than one + implementation. But note that the prime concern of the IESG will be + that the underlying reasons for the interoperable implementations are + met, i.e., that the text of the specification is clear and + unambiguous, and that features of the specification which have not + 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 along + with the other pre-advancement implementation reports and will be + specifically referred to in the IETF Last-Call. As with all such + implementation reports, the determination of adequacy is made by the + Area Director(s) of the relevant IETF Area. This determination of + adequacy can be challenged during the Last-Call period. + +6. Security Considerations + + Some may view this policy as possibly leading to a reduction in the + level of confidence people can have in MIB specifications but the O&M + Area Directors and the IESG feel that it will adequately ensure a + reasonable evaluation of the level of clarity of MIB specifications + and to ensure that unused options can be identified and removed + before the advancement of a specification. + + Good, clearly written MIB specifications can be of great assistance + in the management of the Internet and other networks and thus assist + in the reduction of some types of security threats. + +8. References + + [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' Addresses + + Michael D. O'Dell + UUNET Technologies, Inc. + 3060 Williams Drive + Fairfax, VA 22031 + + Phone: +1-703-206-5890 + EMail: mo@uu.net + + + Harald T. Alvestrand + Maxware + Pirsenteret + N-7005 Trondheim, Norway + + Phone: +47-73-54-57-94 + EMail: Harald.Alvestrand@maxware.no + + + Bert Wijnen + IBM T. J. Watson Research + Schagen 33 + 3461 GL Linschoten + Netherlands + + Phone: +31-348-432-794 + EMail: wijnen@vnet.ibm.com + + + Scott Bradner + Harvard University + 1350 Mass. Ave. + Cambridge MA 02138 + + Phone: +1-617-495-3864 + EMail: sob@harvard.edu + + + + + + + + + + + + + + +O'Dell, et. al. Best Current Practice [Page 5] + +RFC 2438 Advancement of MIB specifications October 1998 + + +Appendix A + +A. Some Testing Alternatives + + The IESG debated a number of interoperability and testing models in + formulating this specification. The following list is not an + exhaustive enumeration of the alternatives, but it does capture the + major plausible models which were examined in the course of the + discussion. + +A.1 Basic Object Comparison + + Assume the requisite two genetically unrelated implementations of the + MIB in an SNMP agent and an SNMP management station which can do a + "MIB Dump" (extract the complete set of MIB object types and values + from the agent implementation). Extract a MIB Dump from each + implementation and compare the two dumps to verify that both provide + the complete set of mandatory and optional objects and that the + individual objects are of the correct types. + +A.2 Stimulus/Response Testing + + Proceed as in A.1, but in addition, comprehensively exercise the two + (network) elements containing the agent implementations to verify + that all the MIB objects reflect plausible values in operational + conditions. An even stricter interpretation would require that the + MIB objects in the two network elements track identically given the + identical stimulus. While this would test "read-only" or + "monitoring" information obtained from the underlying + instrumentation, it is important to observe that such instrumentation + is actually an *application* which uses the MIB and is not part of + the MIB itself. + +A.3 Full Coverage Testing + + This model extends the notion of Stimulus/Response Testing to its + logical extreme. The MIB is viewed as an API and the software + engineering notion of full coverage testing is applied to a MIB. + This involves exercising all paths through the causal semantics and + verifying that all objects change state correctly in all cases. + Again, note that much more than the MIB definition is being exercised + and evaluated. + + + + + + + + + +O'Dell, et. al. Best Current Practice [Page 6] + +RFC 2438 Advancement of MIB specifications October 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +O'Dell, et. al. Best Current Practice [Page 7] + -- cgit v1.2.3