📄 rfc1212.txt
字号:
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 } ENDSNMP Working Group [Page 13] RFC 1212 Concise MIB Definitions March 1991 The 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 a 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 toSNMP Working Group [Page 14] RFC 1212 Concise MIB Definitions March 1991 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: (1) An object with BOOLEAN syntax becomes an INTEGER taking either of values true(1) or false(2). (2) An object with ENUMERATED syntax becomes an INTEGER, taking any of the values given. (3) An object with BIT STRING syntax containing no more than 32 bits becomes an INTEGER defined 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". (4) An object with a character string syntax becomes either an OCTET STRING or a DisplayString, depending on the repertoire of the character string. (5) An 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. (6) Tabular objects must be decomposed into rows of columnar objects.5.1.2. Mapping to the ACCESS clause This is straight-forward.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 anySNMP Working Group [Page 15] RFC 1212 Concise MIB Definitions March 1991 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.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 theSNMP Working Group [Page 16] RFC 1212 Concise MIB Definitions March 1991 action being mapped, the document which defines the action, and perhaps a page number in the document.6. Acknowledgements This document was produced by the SNMP Working Group: 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, TWGSNMP Working Group [Page 17] RFC 1212 Concise MIB Definitions March 1991 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 Research7. References [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 ofSNMP Working Group [Page 18] RFC 1212 Concise MIB Definitions March 1991 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 Security issues are not discussed in this memo.9. Authors' Addresses 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.comSNMP Working Group [Page 19] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -