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/rfc1215.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc1215.txt (limited to 'doc/rfc/rfc1215.txt') diff --git a/doc/rfc/rfc1215.txt b/doc/rfc/rfc1215.txt new file mode 100644 index 0000000..431933b --- /dev/null +++ b/doc/rfc/rfc1215.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group M. Rose, Editor +Request for Comments: 1215 Performance Systems International + March 1991 + + + A Convention for Defining Traps + for use with the SNMP + +Status of this Memo + + This memo suggests a straight-forward approach towards defining traps + used with the SNMP. Readers should note that the use of traps in the + Internet-standard network management framework is controversial. As + such, this memo is being put forward for information purposes. + Network management practitioners who employ traps are encouraged to + make use of this document. Practitioners who do not employ traps can + safely ignore this document. + + This memo provides information for the Internet community. It does + not specify any standard. Distribution of this memo is unlimited. + +Table of Contents + + 1. Historical Perspective ................................ 1 + 2. Defining Traps ........................................ 2 + 2.1 Mapping of the TRAP-TYPE macro ....................... 3 + 2.1.1 Mapping of the ENTERPRISE clause ................... 3 + 2.1.2 Mapping of the VARIABLES clause .................... 4 + 2.1.3 Mapping of the DESCRIPTION clause .................. 4 + 2.1.4 Mapping of the REFERENCE clause .................... 4 + 2.1.5 Mapping of the TRAP-TYPE value ..................... 4 + 2.2 Usage Examples ....................................... 5 + 2.2.1 Enterprise-specific Trap ........................... 5 + 2.2.2 Generic-Traps for use with the SNMP ................ 5 + 3. Acknowledgements ...................................... 7 + 4. References ............................................ 9 + 5. Security Considerations................................ 9 + 6. Author's Address....................................... 9 + +1. Historical Perspective + + As reported in RFC 1052, IAB Recommendations for the Development of + Internet Network Management Standards [1], a two-prong strategy for + network management of TCP/IP-based internets was undertaken. In the + short-term, the Simple Network Management Protocol (SNMP), defined in + RFC 1067, was to be used to manage nodes in the Internet community. + In the long-term, the use of the OSI network management framework was + be examined. Two documents were produced to define the management + + + +SNMP Working Group [Page 1] + +RFC 1215 Convention for Defining Traps March 1991 + + + information: RFC 1065, which defined the Structure of Management + Information (SMI), and RFC 1066, which defined the Management + Information Base (MIB). Both of these documents were designed so as + to be compatible with both the SNMP and the OSI network management + framework. + + This strategy was quite successful in the short-term: Internet-based + network management technology was fielded, by both the research and + commercial communities, within a few months. As a result of this, + portions of the Internet community became network manageable in a + timely fashion. + + As reported in RFC 1109, Report of the Second Ad Hoc Network + Management Review Group [2], the requirements of the SNMP and the OSI + network management frameworks were more different than anticipated. + As such, the requirement for compatibility between the SMI/MIB and + both frameworks was suspended. This action permitted the operational + network management framework, based on the SNMP, to respond to new + operational needs in the Internet community by producing MIB-II. + + In May of 1990, the core documents were elevated to "Standard + Protocols" with "Recommended" status. As such, the Internet-standard + network management framework 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. + +2. Defining Traps + + Due to its initial requirement to be protocol-independent, the + Internet-standard SMI does not provide a means for defining traps. + Instead, the SNMP defines a few standardized traps and provides a + means for management enterprises to transmit enterprise-specific + traps. + + However, with the introduction of experimental MIBs, some of which + have a need to define experiment-specific traps, a convenient means + of defining traps is desirable. The TRAP-TYPE macro is suggested for + this purpose: + + IMPORTS + ObjectName + FROM RFC1155-SMI; + + + + +SNMP Working Group [Page 2] + +RFC 1215 Convention for Defining Traps March 1991 + + + TRAP-TYPE MACRO ::= + BEGIN + TYPE NOTATION ::= "ENTERPRISE" value + (enterprise OBJECT IDENTIFIER) + VarPart + DescrPart + ReferPart + VALUE NOTATION ::= value (VALUE INTEGER) + + VarPart ::= + "VARIABLES" "{" VarTypes "}" + | empty + VarTypes ::= + VarType | VarTypes "," VarType + VarType ::= + value (vartype ObjectName) + + DescrPart ::= + "DESCRIPTION" value (description DisplayString) + | empty + + ReferPart ::= + "REFERENCE" value (reference DisplayString) + | empty + + END + + It must be emphasized however, that the use of traps is STRONGLY + discouraged in the Internet-standard Network Management Framework. + The TRAP-TYPE macro is intended to allow concise definitions of + existing traps, not to spur the definition of new traps. + +2.1. Mapping of the TRAP-TYPE macro + + It should be noted that the expansion of the TRAP-TYPE macro is + something which conceptually happens during implementation and not + during run-time. + +2.1.1. Mapping of the ENTERPRISE clause + + The ENTERPRISE clause, which must be present, defines the management + enterprise under whose registration authority this trap is defined + (for a discussion on delegation of registration authority, see the + SMI [3]). This value is placed inside the enterprise field of the + SNMP Trap-PDU. + + By convention, if the value of the ENTERPRISE clause is + + + + +SNMP Working Group [Page 3] + +RFC 1215 Convention for Defining Traps March 1991 + + + snmp OBJECT IDENTIFIER ::= { mib-2 11 } + + as defined in MIB-II [7], then instead of using this value, the value + of sysObjectID is placed in the enterprise field of the SNMP Trap- + PDU. This provides a simple means of using the TRAP-TYPE macro to + represent the existing standard SNMP traps; it is not intended to + provide a means to define additional standard SNMP traps. + +2.1.2. Mapping of the VARIABLES clause + + The VARIABLES clause, which need not be present, defines the ordered + sequence of MIB objects which are contained within every instance of + the trap type. Each variable is placed, in order, inside the + variable-bindings field of the SNMP Trap-PDU. Note that at the + option of the agent, additional variables may follow in the + variable-bindings field. + + However, if the value of the ENTERPRISE clause is + + snmp OBJECT IDENTIFIER ::= { mib-2 11 } + + as defined in MIB-II [7], then the introduction of additional + variables must not result in the serialized SNMP Message being larger + than 484 octets. + +2.1.3. Mapping of the DESCRIPTION clause + + The DESCRIPTION clause, which need not be present, contains a textual + definition of the trap type. Note that in order to conform to the + ASN.1 syntax, the entire value of this clause must be enclosed in + double quotation marks, although the value may be multi-line. + + Further, note that if the MIB module does not contain a textual + description of the trap elsewhere then the DESCRIPTION clause must be + present. + +2.1.4. Mapping of the REFERENCE clause + + The REFERENCE clause, which need not be present, contains a textual + cross-reference to a trap, event, or alarm, defined in some other MIB + module. This is useful when de-osifying a MIB produced by some other + organization. + +2.1.5. Mapping of the TRAP-TYPE value + + The value of an invocation of the TRAP-TYPE macro is the (integer) + number which is uniquely assigned to the trap by the registration + authority indicated by the ENTERPRISE clause. This value is placed + + + +SNMP Working Group [Page 4] + +RFC 1215 Convention for Defining Traps March 1991 + + + inside the specific-trap field of the SNMP Trap-PDU, and the + generic-trap field is set to "enterpriseSpecific(6)". + + By convention, if the value of the ENTERPRISE clause is + + snmp OBJECT IDENTIFIER ::= { mib-2 11 } + + as defined in MIB-II [7], then the value of an invocation of the + TRAP-TYPE macro is placed inside the generic-trap field of the SNMP + Trap-PDU, and the specific-trap field is set to 0. This provides a + simple means of using the TRAP-TYPE macro to represent the existing + standard SNMP traps; it is not intended to provide a means to define + additional standard SNMP traps. + +2.2. Usage Examples + +2.2.1. Enterprise-specific Trap + + Consider a simple example of an enterprise-specific trap that is sent + when a communication link failure is encountered: + + myEnterprise OBJECT IDENTIFIER ::= { enterprises 9999 } + + myLinkDown TRAP-TYPE + ENTERPRISE myEnterprise + VARIABLES { ifIndex } + DESCRIPTION + "A myLinkDown trap signifies that the sending + SNMP application entity recognizes a failure + in one of the communications links represented + in the agent's configuration." + ::= 2 + +2.2.2. Generic-Traps for use with the SNMP + + Consider how the standard SNMP traps might be defined: + + coldStart TRAP-TYPE + ENTERPRISE snmp + DESCRIPTION + "A coldStart trap signifies that the sending + protocol entity is reinitializing itself such + that the agent's configuration or the rotocol + entity implementation may be altered." + ::= 0 + + warmStart TRAP-TYPE + ENTERPRISE snmp + + + +SNMP Working Group [Page 5] + +RFC 1215 Convention for Defining Traps March 1991 + + + DESCRIPTION + "A warmStart trap signifies that the sending + protocol entity is reinitializing itself such + that neither the agent configuration nor the + protocol entity implementation is altered." + ::= 1 + + linkDown TRAP-TYPE + ENTERPRISE snmp + VARIABLES { ifIndex } + DESCRIPTION + "A linkDown trap signifies that the sending + protocol entity recognizes a failure in one of + the communication links represented in the + agent's configuration." + ::= 2 + + linkUp TRAP-TYPE + ENTERPRISE snmp + VARIABLES { ifIndex } + DESCRIPTION + "A linkUp trap signifies that the sending + protocol entity recognizes that one of the + communication links represented in the agent's + configuration has come up." + ::= 3 + + authenticationFailure TRAP-TYPE + ENTERPRISE snmp + DESCRIPTION + "An authenticationFailure trap signifies that + the sending protocol entity is the addressee + of a protocol message that is not properly + authenticated. While implementations of the + SNMP must be capable of generating this trap, + they must also be capable of suppressing the + emission of such traps via an implementation- + specific mechanism." + ::= 4 + + + + + + + + + + + + +SNMP Working Group [Page 6] + +RFC 1215 Convention for Defining Traps March 1991 + + + egpNeighborLoss TRAP-TYPE + ENTERPRISE snmp + VARIABLES { egpNeighAddr } + DESCRIPTION + "An egpNeighborLoss trap signifies that an EGP + neighbor for whom the sending protocol entity + was an EGP peer has been marked down and the + peer relationship no longer obtains." + ::= 5 + +3. 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 + + + +SNMP Working Group [Page 7] + +RFC 1215 Convention for Defining Traps March 1991 + + + 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 Research + + + + + + +SNMP Working Group [Page 8] + +RFC 1215 Convention for Defining Traps March 1991 + + +4. 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 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. + +5. Security Considerations + + Security issues are not discussed in this memo. + +6. Author's Address + + 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 + + + + + +SNMP Working Group [Page 9] + \ No newline at end of file -- cgit v1.2.3