RFC 2438

RFC 2438: Advancement of MIB specifications on the IETF Standards Track 🎀

Okay bestie, let's get into it 💅 RFC 2438 came out of the Network Working Group in October 1998. It's a Best Current Practice (the header says BCP: 27), which means it's guidance on how to do things rather than a protocol spec. The authors are M. O'Dell (UUNET Technologies), H. Alvestrand (Maxware), B. Wijnen (IBM T. J. Watson Research), and S. Bradner (Harvard University). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

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] says that all IETF Standards Track specifications have to have "multiple, independent, and interoperable implementations" before they can move beyond Proposed Standard status. This document explains the process the IESG will use to decide whether a MIB specification meets that bar. It also explains the reasoning behind the 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 separate reasons for this, and they're both important 🫶

The first reason is to check that the specification text is clear and accurate. You prove that by showing several implementation teams used the spec to build interoperable implementations.

The second reason is to stop options from piling up and "feature creep" from happening 🙈 That's done by requiring interoperable implementation of every feature, options included. If an option isn't in at least two different interoperable implementations, it's safe to assume nobody found it useful, and it must be removed before the specification can advance.

For a protocol specification that defines the "bits on the wire" that state machines swap, "interoperability" is pretty intuitive. The implementations have to successfully "talk to each other", exchanging "bits on the wire", while exercising all features and options 📡

For an SNMP Management Information Base (MIB) specification, though, what counts as "interoperation" is way less obvious 😭 This document explains how the IESG has decided to judge "MIB specification interoperability" in the context of the IETF Standards Process.

There are a bunch of reasonable ways to interpret MIB specification interoperability. Lots of them have merit, but they come with very different costs and difficulties when you try to actually do them 🍓

The goal is to make sure both specification clarity and feature evaluation get met. The interpretation they landed on 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 way more data oriented. To over-generalize a little, in a typical MIB specification the data type and instance specifications outnumber the inter-object procedural or causal semantics by a lot 📊

Here's the central issue: a MIB specification doesn't stand alone. It forms the access interface to the instrumentation underneath it. Without that instrumentation, a MIB has form but no values 🫠 Add in the huge number of objects even a simple MIB has, and it ends up feeling more like an API or a dictionary than a state machine protocol 📖

It's important to tell apart checking the interoperability of applications that may use or interact with MIBs, and checking the MIBs themselves. It's pretty obvious that "black-box testing" can be applied to those applications, and that the approach is pretty mature in software engineering. A MIB specification, on the other hand, isn't really friendly to black box test plans 🙃

5. Discussion and Recommended Process 💜

To meet their obligations under the IETF Standards Process, the Operations and Management Area Directors and the IESG must be convinced of three things. Each MIB specification advanced to Draft Standard or Internet Standard status has to be clearly written, has to have the required multiple interoperable implementations, and has to have all of its options implemented. There's more than one way to get there, and Appendix A lists some testing approaches that could be used when trying to document multiple implementations 🎯

The Full Coverage and Stimulus-Response approaches are very thorough, and they'd boost confidence that the requirement has been met, if they were applied. But real-world software engineering makes it clear that this confidence costs an extremely high price 💸 Even with the most exhaustive testing, it's often unclear exactly what was demonstrated. Both of those standards of evidence are well beyond what can reasonably be done operationally, and getting the required semantic specifications is even less likely 😩

So the Operations and Management Area and the IESG went with a more pragmatic approach to deciding whether a MIB specification is ready to advance 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 it meets the multiple implementation and feature support requirements of the IETF Standards Process. How to make that argument is up to the advocate, but it will normally include reports that basic object comparison testing has been done ✨

So any recommendation to advance a MIB specification must come with an implementation report, same as every request to advance an IETF specification. The implementation report must explain why the IESG should believe there are multiple implementations of the MIB specification in question, and that all of the MIB objects in the specification being advanced are supported in more than one implementation. But the IESG's main concern is that the underlying reasons for interoperable implementations are met. That means the specification text has to be clear and unambiguous, and any features that didn't get support have to be removed 🧹

The implementation report will be posted on the IETF web page with the other pre-advancement implementation reports, and it'll be specifically referenced in the IETF Last-Call. As with all such reports, the Area Director(s) of the relevant IETF Area decide whether it's adequate. That decision can be challenged during the Last-Call period 📣

6. Security Considerations 🔥

Some people might think this policy could lower the level of confidence people can have in MIB specifications. But the O&M Area Directors and the IESG feel it will adequately ensure a reasonable evaluation of how clear MIB specifications are, and that unused options can be identified and removed before a specification advances 🛡️

Good, clearly written MIB specifications can be a huge help in managing the Internet and other networks, and that helps reduce some types of security threats. So clarity really is a security feature, periodt 💀💖

Full Copyright Statement ✨

Copyright (C) The Internet Society (1998). All Rights Reserved. 💖

okay so, this document and translations of it can be copied and handed out to others 📄. You can also make derivative works that comment on or explain it, or help people implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restriction of any kind. The one condition is that the copyright notice and this paragraph stay on every copy and derivative work 🫶.

What you can't do is change this document itself. That includes deleting the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. The first is when you need to develop Internet standards, and then you have to follow the copyright procedures in the Internet Standards process 🔥. The second is when you need to translate it into a language other than English 🌍.

The permissions granted above are perpetual, and the Internet Society and its successors or assigns will never revoke them 🦋.

Now the sus part 🙈. This document and the information in it are provided "AS IS", 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 💀. Translation: no promises, no guarantees, use it at your own risk, bestie 💅✨.