RFC 1212
Concise MIB definitions
Concise MIB Definitions 🎀
okay bestie, this is RFC 1212 and it's called Concise MIB Definitions 💖. It came out of the Network Working Group in March 1991 📅. The editors are M. Rose from Performance Systems International and K. McCloghrie from Hughes LAN Systems ✨. It's an IAB standards track document, and the title block has no Obsoletes or Updates lines, so it isn't replacing or touching anything listed up there 🧚.
Status of This Memo ✨
okay so this memo defines a format for producing MIB modules 💅. This RFC specifies an IAB standards track document for the Internet community, and it's basically asking everyone for discussion and suggestions for improvements 🫶. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol 📚. Distribution of this memo is unlimited 🌈.
Table of Contents 🧚
1. Abstract.............................................. 2
2. Historical Perspective ............................... 2
3. Columnar Objects ..................................... 3
3.1 Row Deletion ........................................ 4
3.2 Row Addition ........................................ 4
4. Defining Objects ..................................... 5
4.1 Mapping of the OBJECT-TYPE macro .................... 7
4.1.1 Mapping of the SYNTAX clause ...................... 7
4.1.2 Mapping of the ACCESS clause ...................... 8
4.1.3 Mapping of the STATUS clause ...................... 8
4.1.4 Mapping of the DESCRIPTION clause ................. 8
4.1.5 Mapping of the REFERENCE clause ................... 8
4.1.6 Mapping of the INDEX clause ....................... 8
4.1.7 Mapping of the DEFVAL clause ...................... 10
4.1.8 Mapping of the OBJECT-TYPE value .................. 11
4.2 Usage Example ....................................... 11
5. Appendix: DE-osifying MIBs ........................... 13
5.1 Managed Object Mapping .............................. 14
5.1.1 Mapping to the SYNTAX clause ...................... 15
5.1.2 Mapping to the ACCESS clause ...................... 15
5.1.3 Mapping to the STATUS clause ...................... 15
5.1.4 Mapping to the DESCRIPTION clause ................. 15
5.1.5 Mapping to the REFERENCE clause ................... 16
5.1.6 Mapping to the INDEX clause ....................... 16
5.1.7 Mapping to the DEFVAL clause ...................... 16
5.2 Action Mapping ...................................... 16
5.2.1 Mapping to the SYNTAX clause ...................... 16
5.2.2 Mapping to the ACCESS clause ...................... 16
5.2.3 Mapping to the STATUS clause ...................... 16
5.2.4 Mapping to the DESCRIPTION clause ................. 16
5.2.5 Mapping to the REFERENCE clause ................... 16
6. Acknowledgements ..................................... 17
7. References ........................................... 18
8. Security Considerations............................... 19
9. Authors' Addresses.................................... 191. Abstract ✨
so this memo is all about a straight-forward way to make MIB modules that are concise 🎀 but still descriptive 💖. It's intended that all future MIB modules be written in this format 👑.
2. Historical Perspective 📜
okay so, as reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], there was a two-prong strategy for network management of TCP/IP-based internets 💅. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was going to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was going to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these were designed to be compatible with both SNMP and the OSI network management framework 🫶.
this strategy was honestly iconic in the short-term 🔥. Internet-based network management technology got fielded by both the research and commercial communities within a few months. Because of that, portions of the Internet community became network manageable in a timely fashion ✨.
then, as reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [2], the requirements of SNMP and the OSI network management frameworks turned out to be more different than anticipated 💀. So the requirement for compatibility between the SMI/MIB and both frameworks got suspended 🙈. That let the operational network management framework, based on SNMP, respond to new operational needs in the Internet community by producing MIB-II 👑.
in May of 1990, the core documents got elevated to "Standard Protocols" with "Recommended" status 🎉. So the Internet-standard network management framework now consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [4]; and the Simple Network Management Protocol, RFC 1157 [5], which defines the protocol used to manage these objects 🦋. Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined in the Internet-standard MIB was derived by only taking those elements which are considered essential 🍓. However, the SMI defined three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non-standard objects through the experimental subtree; and three, the addition of private objects through the enterprises subtree 🌈. Those additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential 🧪.
as more objects get defined using the second method, experience has shown that the resulting MIB descriptions contain redundant information 😭. To get MIB descriptions that are more concise but just as informative, an enhancement is suggested 💜. This enhancement lets the author of a MIB remove the redundant information while keeping the important descriptive text ✨.
before we get to the approach, we need a quick look at how SNMP handles columnar object stuff. This explains and further motivates the value of the enhancement 🎀.
3. Columnar Objects 🌸
so SNMP supports operations on MIB objects whose syntax is ObjectSyntax as defined in the SMI. Informally, SNMP operations apply exclusively to scalar objects 🫣. BUT it's convenient for developers of management applications to impose imaginary, tabular structures on the ordered collection of objects that make up the MIB 📊. Each conceptual table has zero or more rows, and each row may contain one or more scalar objects, called columnar objects 💖. Historically, this conceptualization has been formalized by using the OBJECT-TYPE macro to define both an object which corresponds to a table and an object which corresponds to a row in that table. (The ACCESS clause for such objects is not-accessible, of course.) However, it must be emphasized that, at the protocol level, relationships among columnar objects in the same row is a matter of convention, not of protocol 🙅.
there are good reasons why the tabular structure isn't a matter of protocol 🤓. Think about what the SNMP Get-Next-PDU does when it acts on the last columnar object of an instance of a conceptual row: it returns the next column of the first conceptual row, or the first object instance occurring after the table. If the rows were a matter of protocol, it would instead return an error 💀. By not returning an error, one single PDU exchange tells the manager that the end of the conceptual row/table has been reached, and it also gives info on the next object instance. That means the information density of the PDU exchange goes way up 🔥.
3.1. Row Deletion 🧹
it's still highly useful to have a way to remove a conceptual row from a table. In MIB-II, this was done by defining, for each conceptual row, an integer-valued columnar object. If a management station sets the value of this object to some value, usually termed "invalid", then the effect is invalidating the corresponding row in the table. However, it's an implementation-specific matter whether an agent actually removes an invalidated entry from the table 🤷. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use 👀. Proper interpretation of such entries requires examining the columnar object that indicates the in-use status 🔍.
3.2. Row Addition ➕
it's also highly useful to have a clear understanding of how a conceptual row may be added to a table 💅. In the SNMP, at the protocol level, a management station issues an SNMP set operation containing an arbitrary set of variable bindings. If an agent detects that one or more of those variable bindings refers to an object instance not currently available in that agent, then, according to the rules of the SNMP, it may behave according to any of the following paradigms 🧠:
(1) It may reject the SNMP set operation as referring to non-existent object instances by returning a response with the error-status field set to noSuchName and the error-index field set to refer to the first vacuous reference.
(2) It may accept the SNMP set operation as requesting the creation of new object instances corresponding to each of the object instances named in the variable bindings. The value of each (potentially) newly created object instance is specified by the value component of the relevant variable binding. In this case, if the request specifies a value for a newly (or previously) created object that it deems inappropriate by reason of value or syntax, then it rejects the SNMP set operation by responding with the error-status field set to badValue and the error-index field set to refer to the first offending variable binding.
(3) It may accept the SNMP set operation and create new object instances as described in (2) above and, in addition, at its discretion, create supplemental object instances to complete a row in a conceptual table of which the new object instances specified in the request may be a part.
it should be emphasized that all three of the above behaviors are fully conformant to the SNMP specification and are fully acceptable 💖, subject to any restrictions which may be imposed by access control and/or the definitions of the MIB objects themselves 🫶.
4. Defining Objects ✨
Okay bestie, so the Internet-standard SMI does this two-level thing for defining objects 💅 A MIB definition is really two parts: a textual part, where objects get sorted into groups, and a MIB module, where each object is described only using the ASN.1 macro OBJECT-TYPE, which the SMI defines 🦋
Here's what the textual one looks like 🎀
OBJECT:
-------
sysLocation { system 6 }
Syntax:
DisplayString (SIZE (0..255))
Definition:
The physical location of this node (e.g., "telephone
closet, 3rd floor").
Access:
read-only.
Status:
mandatory.And here's the MIB module version 🌸
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
::= { system 6 }Honestly? Writing both out is a lot of chances to mess something up 😭 So it's giving combine-them-into-one energy. To save time and dodge editing mistakes, you can do that by making an extension to the OBJECT-TYPE macro 🧚
IMPORTS
ObjectName
FROM RFC1155-SMI
DisplayString
FROM RFC1158-MIB;
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
-- must conform to
-- RFC1155's ObjectSyntax
"SYNTAX" type(ObjectSyntax)
"ACCESS" Access
"STATUS" Status
DescrPart
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::= value (VALUE ObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
| "deprecated"
DescrPart ::=
"DESCRIPTION" value (description DisplayString)
| empty
ReferPart ::=
"REFERENCE" value (reference DisplayString)
| empty
IndexPart ::=
"INDEX" "{" IndexTypes "}"
| empty
IndexTypes ::=
IndexType | IndexTypes "," IndexType
IndexType ::=
-- if indexobject, use the SYNTAX
-- value of the correspondent
-- OBJECT-TYPE invocation
value (indexobject ObjectName)
-- otherwise use named SMI type
-- must conform to IndexSyntax below
| type (indextype)
DefValPart ::=
"DEFVAL" "{" value (defvalue ObjectSyntax) "}"
| empty
END
IndexSyntax ::=
CHOICE {
number
INTEGER (0..MAX),
string
OCTET STRING,
object
OBJECT IDENTIFIER,
address
NetworkAddress,
ipAddress
IpAddress
}4.1. Mapping of the OBJECT-TYPE macro 💅
Quick heads-up: expanding the OBJECT-TYPE macro is something that conceptually happens during implementation, and not at run-time 🙈
4.1.1. Mapping of the SYNTAX clause 🧚
The SYNTAX clause MUST be present. It defines the abstract data structure that corresponds to that object type, and the ASN.1 language [6] is what gets used for this. BUT the SMI purposely restricts which ASN.1 constructs you're allowed to use, and that's all for simplicity 🍓
4.1.2. Mapping of the ACCESS clause 🦋
The ACCESS clause MUST be present, and it defines the minimum level of support required for that object type. As a local matter, an implementation MAY support other access types (for example, an implementation may elect to permit writing to a variable that's marked read-only). Also, protocol-specific "views" (like the ones indirectly implied by an SNMP community) MAY make further restrictions on access to a variable 🔒
4.1.3. Mapping of the STATUS clause 🌈
The STATUS clause MUST be present, and it defines the implementation support required for that object type ✅
4.1.4. Mapping of the DESCRIPTION clause 📝
The DESCRIPTION clause need not be present. It contains a textual definition of that object type that gives all the semantic definitions needed for implementation, and it SHOULD embody any info that would otherwise be communicated in ASN.1 commentary annotations associated with the object. Heads up: to conform to the ASN.1 syntax, the entire value of this clause MUST be enclosed in double quotation marks, though the value MAY be multi-line 💜
Also, if the MIB module doesn't contain a textual description of the object type somewhere else, then the DESCRIPTION clause MUST be present ⭐
4.1.5. Mapping of the REFERENCE clause 🔗
The REFERENCE clause need not be present. It contains a textual cross-reference to an object defined in some other MIB module, which is super useful when de-osifying a MIB that was produced by some other organization 🧚
4.1.6. Mapping of the INDEX clause 👑
The INDEX clause MAY be present only if that object type corresponds to a conceptual row, and it defines the instance identification info for that object type. (Historically, every MIB definition had a section called "Identification of OBJECT instances for use with the SNMP". Thanks to the INDEX clause, that section no longer needs to show up, since this clause concisely captures the precise semantics needed for instance identification 💅)
If the INDEX clause is not present, and the object type corresponds to a non-columnar object, then instances of the object are identified by appending a sub-identifier of zero to the name of that object. Further, if the MIB module doesn't contain a textual description of how instance identification info is derived for columnar objects, then the INDEX clause MUST be present 🚨
To define the instance identification info, figure out which object value(s) will unambiguously distinguish a conceptual row. The syntax of those objects tells you how to form the instance-identifier 🔍
- integer-valued: a single sub-identifier taking the integer value (this works only for non-negative integers);
- string-valued, fixed-length strings:
`n'sub-identifiers, where`n'is the length of the string (each octet of the string is encoded in a separate sub-identifier); - string-valued, variable-length strings:
`n+1'sub-identifiers, where`n'is the length of the string (the first sub-identifier is`n'itself, following this, each octet of the string is encoded in a separate sub-identifier); - object identifier-valued:
`n+1'sub-identifiers, where`n'is the number of sub-identifiers in the value (the first sub-identifier is`n'itself, following this, each sub-identifier in the value is copied); - NetworkAddress-valued:
`n+1'sub-identifiers, where`n'depends on the kind of address being encoded (the first sub-identifier indicates the kind of address, value 1 indicates an IpAddress); or, - IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d notation.
Note that if an "indextype" value is present (e.g., INTEGER rather than ifIndex), then a DESCRIPTION clause MUST be present. The text in there is what explains the semantics of the "indextype" value 🌸
By way of example, in the context of MIB-II [7], the following INDEX clauses might be present 🍓
objects under INDEX clause
----------------- ------------
ifEntry { ifIndex }
atEntry { atNetIfIndex,
atNetAddress }
ipAddrEntry { ipAdEntAddr }
ipRouteEntry { ipRouteDest }
ipNetToMediaEntry { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
tcpConnEntry { tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemoteAddress,
tcpConnRemotePort }
udpEntry { udpLocalAddress,
udpLocalPort }
egpNeighEntry { egpNeighAddr }4.1.7. Mapping of the DEFVAL clause 🎀
The DEFVAL clause need not be present. It defines an acceptable default value that MAY be used when an object instance is created at the discretion of the agent acting in conformance with the third paradigm described in Section 4.2 above 💖
During conceptual row creation, if an instance of a columnar object isn't one of the operands in the correspondent SNMP set operation, then the value of the DEFVAL clause, if present, indicates an acceptable default value that the agent might use 🌈
The value of the DEFVAL clause MUST, of course, correspond to the SYNTAX clause for the object. Heads up: if an operand to the SNMP set operation is an instance of a read-only object, then the error noSuchName will be returned. So the DEFVAL clause can be used to provide an acceptable default value that the agent might use 😭
It's possible that no acceptable default value may exist for any of the columnar objects in a conceptual row for which creating new object instances is allowed. In that case, the objects specified in the INDEX clause MUST have a corresponding ACCESS clause value of read-write 💀
By way of example, consider these possible DEFVAL clauses 🙈
ObjectSyntax DEFVAL clause
----------------- ------------
INTEGER 1 -- same for Counter, Gauge, TimeTicks
OCTET STRING 'ffffffffffff'h
DisplayString "any NVT ASCII string"
OBJECT IDENTIFIER sysDescr
OBJECT IDENTIFIER { system 2 }
NULL NULL
NetworkAddress { internet 'c0210415'h }
IpAddress 'c0210415'h -- 192.33.4.214.1.8. Mapping of the OBJECT-TYPE value 💜
The value of an invocation of the OBJECT-TYPE macro is the name of the object, and that name is an object identifier 🦋
4.2. Usage Example 💅
okay bestie, let's look at how the ipNetToMediaTable from MIB-II could be fully described 🎀
-- the IP Address Translation tables
-- The Address Translation tables contain IpAddress to
-- "physical" address equivalences. Some interfaces do not
-- use translation tables for determining address equivalences
-- (e.g., DDN-X.25 has an algorithmic method); if all
-- interfaces are of this type, then the Address Translation
-- table is empty, i.e., has zero entries.
ipNetToMediaTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpNetToMediaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The IP Address Translation table used for mapping
from IP addresses to physical addresses."
::= { ip 22 }
ipNetToMediaEntry OBJECT-TYPE
SYNTAX IpNetToMediaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Each entry contains one IpAddress to 'physical'
address equivalence."
INDEX { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
::= { ipNetToMediaTable 1 }
IpNetToMediaEntry ::=
SEQUENCE {
ipNetToMediaIfIndex
INTEGER,
ipNetToMediaPhysAddress
OCTET STRING,
ipNetToMediaNetAddress
IpAddress,
ipNetoToMediaType
INTEGER
}
ipNetToMediaIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The interface on which this entry's equivalence
is effective. The interface identified by a
particular value of this index is the same
interface as identified by the same value of
ifIndex."
::= { ipNetToMediaEntry 1 }
ipNetToMediaPhysAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The media-dependent 'physical' address."
::= { ipNetToMediaEntry 2 }
ipNetToMediaNetAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IpAddress corresponding to the media-
dependent 'physical' address."
::= { ipNetToMediaEntry 3 }
ipNetToMediaType OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- none of the following
invalid(2), -- an invalidated mapping
dynamic(3),
static(4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The type of mapping.
Setting this object to the value invalid(2) has
the effect of invalidating the corresponding entry
in the ipNetToMediaTable. That is, it effectively
disassociates the interface identified with said
entry from the mapping identified with said entry.
It is an implementation-specific matter as to
whether the agent removes an invalidated entry
from the table. Accordingly, management stations
must be prepared to receive tabular information
from agents that corresponds to entries not
currently in use. Proper interpretation of such
entries requires examination of the relevant
ipNetToMediaType object."
::= { ipNetToMediaEntry 4 }5. Appendix: DE-osifying MIBs 🦋
lately there's been SO much work on taking MIBs from other organizations (like the IEEE 👀) and de-osifying them so they fit the Internet-standard network management framework 🌸. The steps are straight-forward, tbh tedious 😭. Of course it helps if you've already got experience writing MIB modules for that framework 💅.
The first step is to construct a skeletal MIB module, e.g.,
RFC1213-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental, OBJECT-TYPE, Counter
FROM RFC1155-SMI;
-- contact IANA for actual number
root OBJECT IDENTIFIER ::= { experimental xx }
ENDThe next step is to categorize the objects into groups. For experimental MIBs, optional objects are permitted. However, when a MIB module is placed in the Internet-standard space, these optional objects are either removed, or placed in an optional group, which, if implemented, all objects in the group must be implemented. For the first pass, it is wisest to simply ignore any optional objects in the original MIB. Experience shows it is better to define a core MIB module first, containing only essential objects; later, if experience demands, other objects can be added. 🧚
It must be emphasized that groups are "units of conformance" within a MIB 👑. Everything in a group is "mandatory", and implementations do either whole groups or none.
5.1. Managed Object Mapping
Next, for each managed object class, determine whether there can exist multiple instances of that managed object class. If not, then for each of its attributes, use the OBJECT-TYPE macro to make an equivalent definition.
Otherwise, if multiple instances of the managed object class can exist, then define a conceptual table having conceptual rows, each containing a columnar object for each of the managed object class's attributes. If the managed object class is contained within the containment tree of another managed object class, then the assignment of an object type is normally required for each of the "distinguished attributes" of the containing managed object class. If they do not already exist within the MIB module, then they can be added via the definition of additional columnar objects in the conceptual row corresponding to the contained managed object class.
In defining a conceptual row, it is useful to consider the optimization of network management operations which will act upon its columnar objects. In particular, it is wisest to avoid defining more columnar objects within a conceptual row than can fit in a single PDU. As a rule of thumb, a conceptual row should contain no more than approximately 20 objects. Similarly, or as a way to abide by the "20 object guideline", columnar objects should be grouped into tables according to the expected grouping of network management operations upon them. As such, the content of conceptual rows should reflect typical access scenarios. E.g., they should be organized along functional lines, such as one row for statistics and another row for parameters, or along usage lines, such as commonly-needed objects versus rarely-needed objects. 🌈
On the other hand, the definition of conceptual rows where the number of columnar objects used as indexes outnumbers the number used to hold information should also be avoided. In particular, the splitting of a managed object class's attributes into many conceptual tables should not be used as a way to obtain the same degree of flexibility/complexity as is often found in MIB's with a myriad of optionals. 🙈
5.1.1. Mapping to the SYNTAX clause
When mapping to the SYNTAX clause of the OBJECT-type macro:
- An object with
BOOLEANsyntax becomes anINTEGERtaking either of the valuestrue(1)orfalse(2). 💖 - An object with ENUMERATED syntax becomes an
INTEGER, taking any of the values given. 🍓 - An object with BIT STRING syntax containing no more than 32 bits becomes an
INTEGERdefined as a sum. Otherwise, if more than 32 bits are present, the object becomes an OCTET STRING, with the bits numbered from left-to-right, in which the least significant bits of the last octet may be "reserved for future use". ✨ - An object with a character string syntax becomes either an OCTET STRING or a DisplayString, depending on the repertoire of the character string. 🦋
- A non-tabular object with a complex syntax, such as REAL or EXTERNAL, must be decomposed, usually into an OCTET STRING (if sensible). As a rule, any object with a complicated syntax should be avoided. 🙅♀️
- Tabular objects must be decomposed into rows of columnar objects. 🌸
5.1.2. Mapping to the ACCESS clause
This is straight-forward, bestie 💅.
5.1.3. Mapping to the STATUS clause
This is usually straight-forward. However, some osified-MIBs use the term "recommended". In this case, a choice must be made between "mandatory" and "optional". 🤔
5.1.4. Mapping to the DESCRIPTION clause
This is straight-forward: simply copy the text, making sure that any embedded double quotation marks are sanitized (i.e., replaced with single-quotes or removed). 🎀
5.1.5. Mapping to the REFERENCE clause
This is straight-forward: simply include a textual reference to the object being mapped, the document which defines the object, and perhaps a page number in the document. 📚
5.1.6. Mapping to the INDEX clause
Decide how instance-identifiers for columnar objects are to be formed, and define this clause accordingly. 🧩
5.1.7. Mapping to the DEFVAL clause
Decide if a meaningful default value can be assigned to the object being mapped, and if so, define the DEFVAL clause accordingly. ⭐
5.2. Action Mapping
Actions are modeled as read-write objects, in which writing a particular value results in the action taking place. this is so clever, ngl 🔥
5.2.1. Mapping to the SYNTAX clause
Usually an INTEGER syntax is used, with a distinguished value provided for each action that the object provides access to. In addition, there is usually one other distinguished value, which is the one returned when the object is read. 🌸
5.2.2. Mapping to the ACCESS clause
Always use read-write. 💜
5.2.3. Mapping to the STATUS clause
This is straight-forward. 🦋
5.2.4. Mapping to the DESCRIPTION clause
This is straight-forward: simply copy the text, making sure that any embedded double quotation marks are sanitized (i.e., replaced with single-quotes or removed). 🎀
5.2.5. Mapping to the REFERENCE clause
This is straight-forward: simply include a textual reference to the action being mapped, the document which defines the action, and perhaps a page number in the document. 📖
6. Acknowledgements ✨
okay so this doc was cooked up by the SNMP Working Group, and the list of people who helped is LONG 😭🫶 every single name gets a shoutout, with their company or school right next to it. the whole squad:
Anne Ambler, Spider
Karl Auerbach, Sun
Fred Baker, ACC
Ken Brinkerhoff
Ron Broersma, NOSC
Jack Brown, US Army
Theodore Brunner, Bellcore
Jeffrey Buffum, HP
John Burress, Wellfleet
Jeffrey D. Case, University of Tennessee at Knoxville
Chris Chiptasso, Spartacus
Paul Ciarfella, DEC
Bob Collet
John Cook, Chipcom
Tracy Cox, Bellcore
James R. Davin, MIT-LCS
Eric Decker, cisco
Kurt Dobbins, Cabletron
Nadya El-Afandi, Network Systems
Gary Ellis, HP
Fred Engle
Mike Erlinger
Mark S. Fedor, PSI
Richard Fox, Synoptics
Karen Frisa, CMU
Chris Gunner, DEC
Fred Harris, University of Tennessee at Knoxville
Ken Hibbard, Xylogics
Ole Jacobsen, Interop
Ken Jones
Satish Joshi, Synoptics
Frank Kastenholz, Racal-Interlan
Shimshon Kaufman, Spartacus
Ken Key, University of Tennessee at Knoxville
Jim Kinder, Fibercom
Alex Koifman, BBN
Christopher Kolb, PSI
Cheryl Krupczak, NCR
Paul Langille, DEC
Peter Lin, Vitalink
John Lunny, TWG
Carl Malamud
Randy Mayhew, University of Tennessee at Knoxville
Keith McCloghrie, Hughes LAN Systems
Donna McMaster, David Systems
Lynn Monsanto, Sun
Dave Perkins, 3COM
Jim Reinstedler, Ungerman Bass
Anil Rijsinghani, DEC
Kathy Rinehart, Arnold AFB
Kary Robertson
Marshall T. Rose, PSI (chair)
L. Michael Sabo, NCSC
Jon Saperia, DEC
Greg Satz, cisco
Martin Schoffstall, PSI
John Seligson
Steve Sherry, Xyplex
Fei Shu, NEC
Sam Sjogren, TGV
Mark Sleeper, Sparta
Lance Sprung
Mike St.Johns
Bob Stewart, Xyplex
Emil Sturniold
Kaj Tesink, Bellcore
Dean Throop, Data General
Bill Townsend, Xylogics
Maurice Turcotte, Racal-Milgo
Kannan Varadhou
Sudhanshu Verma, HP
Bill Versteeg, Network Research Corporation
Warren Vik, Interactive Systems
David Waitzman, BBN
Steve Waldbusser, CMU
Dan Wintringhan
David Wood
Wengyik Yeong, PSI
Jeff Young, Cray Researchthe whole room was literally carrying this spec 🌈👑
7. References 📚
these are the receipts bestie, every source the doc leans on, with all the details kept 💅
[1] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[4] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[6] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization International
Standard 8824, December 1987.
[7] Rose M., Editor, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1213,
Performance Systems International, March 1991.8. Security Considerations 🔒
okay the security section is literally one line, so here it is in full: security issues are not discussed in this memo. that's the whole vibe 💀
Full stop, bestie: this memo does not discuss security issues at all. Read the room and go check the rest of your setup before you assume anything is locked down 🙈🔒
9. Authors' Addresses 🎀
and here's where you can find the two queens who wrote it 👑
Marshall T. Rose
Performance Systems International
5201 Great America Parkway
Suite 3106
Santa Clara, CA 95054
Phone: +1 408 562 6222
EMail: mrose@psi.com
X.500: rose, psi, us
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.comand that's a wrap on the whole doc, periodt 🦋✨
📦 where this page comes from
- ietf: rfc1212 1991-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms