respectively. If the OBJECTS clause is present in the invocation of
the corresponding NOTIFICATION-TYPE macro, then each corresponding
variable, as instantiated by this notification, is copied, in order,
to the variable-bindings field. If any additional variables are
being included (at the option of the generating SNMP entity), then
each is copied to the variable-bindings field.
4.2.7. The InformRequest-PDU
An InformRequest-PDU is generated and transmitted by an SNMP entity
on behalf of a notification originator application. The
InformRequest-PDU is often used to notify a notification receiver
application that an event has occurred or that a condition is
present. This is a confirmed notification delivery mechanism,
although there is, of course, no guarantee of delivery.
The destination(s) to which an InformRequest-PDU is sent is specified
by the notification originator application. The first two variable
bindings in the variable binding list of an InformRequest-PDU are
sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] respectively. If
the OBJECTS clause is present in the invocation of the corresponding
NOTIFICATION-TYPE macro, then each corresponding variable, as
instantiated by this notification, is copied, in order, to the
variable-bindings field. If any additional variables are being
included (at the option of the generating SNMP entity), then each is
copied to the variable-bindings field.
Upon receipt of an InformRequest-PDU, the receiving SNMP entity
determines the size of a message encapsulating a Response-PDU with
the same values in its request-id, error-status, error-index and
variable-bindings fields as the received InformRequest-PDU. If the
determined message size is greater than either a local constraint or
the maximum message size of the originator, then an alternate
Response-PDU is generated, transmitted to the originator of the
InformRequest-PDU, and processing of the InformRequest-PDU terminates
immediately thereafter. This alternate Response-PDU is formatted
with the same values in its request-id field as the received
InformRequest-PDU, with the value of its error-status field set to
"tooBig", the value of its error-index field set to zero, and an
empty variable-bindings field. This alternate Response-PDU is then
encapsulated into a message. If the size of the resultant message is
less than or equal to both a local constraint and the maximum message
size of the originator, it is transmitted to the originator of the
InformRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter
is incremented and the resultant message is discarded. Regardless,
processing of the InformRequest-PDU terminates.
Otherwise, the receiving SNMP entity:
(1) presents its contents to the appropriate application;
(2) generates a Response-PDU with the same values in its request-id
and variable-bindings fields as the received InformRequest-PDU,
with the value of its error-status field set to "noError" and
the value of its error-index field set to zero; and
(3) transmits the generated Response-PDU to the originator of the
InformRequest-PDU.
5. Notice on Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. Acknowledgments
This document is the product of the SNMPv3 Working Group. Some
special thanks are in order to the following Working Group members:
Randy Bush
Jeffrey D. Case
Mike Daniele
Rob Frye
Lauren Heintz
Keith McCloghrie
Russ Mundy
David T. Perkins
Randy Presuhn
Aleksey Romanov
Juergen Schoenwaelder
Bert Wijnen
This version of the document, edited by Randy Presuhn, was initially
based on the work of a design team whose members were:
Jeffrey D. Case
Keith McCloghrie
David T. Perkins
Randy Presuhn
Juergen Schoenwaelder
The previous versions of this document, edited by Keith McCloghrie,
was the result of significant work by four major contributors:
Jeffrey D. Case
Keith McCloghrie
Marshall T. Rose
Steven Waldbusser
Additionally, the contributions of the SNMPv2 Working Group to the
previous versions are also acknowledged. In particular, a special
thanks is extended for the contributions of:
Alexander I. Alten
Dave Arneson
Uri Blumenthal
Doug Book
Kim Curran
Jim Galvin
Maria Greene
Iain Hanson
Dave Harrington
Nguyen Hien
Jeff Johnson
Michael Kornegay
Deirdre Kostick
David Levi
Daniel Mahoney
Bob Natale
Brian O'Keefe
Andrew Pearson
Dave Perkins
Randy Presuhn
Aleksey Romanov
Shawn Routhier
Jon Saperia
Juergen Schoenwaelder
Bob Stewart
Kaj Tesink
Glenn Waters
Bert Wijnen
7. Security Considerations
The protocol defined in this document by itself does not provide a
secure environment. Even if the network itself is secure (for
example by using IPSec), there is no control as to who on the secure
network is allowed access to management information.
It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model STD 62, RFC3414 [RFC3414] and the
View-based Access Control Model STD 62, RFC3415 [RFC3415] is
recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity is properly configured so that:
- only those principals (users) having legitimate rights can
access or modify the values of any MIB objects supported by
that entity;
- the occurrence of particular events on the entity will be
communicated appropriately;
- the entity responds appropriately and with due credence to
events and information that have been communicated to it.
8. References
8.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC768,
August 1980.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC2580, April 1999.
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC3411,
December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC3412,
December 2002.
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security
Model (USM) for Version 3 of the Simple Network
Management Protocol (SNMPv3)", STD 62, RFC3414, December
2002.
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC3415, December
2002.
[RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Transport Mappings for the Simple Network
Management Protocol", STD 62, RFC3417, December 2002.
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[ASN1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, December
1987.
8.2. Informative References
[FRAG] Kent, C. and J. Mogul, "Fragmentation Considered
Harmful," Proceedings, ACM SIGCOMM '87, Stowe, VT, August
1987.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
STD 16, RFC1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol", STD 15, RFC1157,
May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC1212, March 1991.
[RFC1213] McCloghrie, K. and M. Rose, Editors, "Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II", STD 17, RFC1213, March 1991.
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC1215, March 1991.
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC1901,
January 1996.
[RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-Standard Network Management Framework",
RFC2576, March 2000.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC2863, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC3410, December 2002.
9. Changes from RFC1905
These are the changes from RFC1905:
- Corrected spelling error in copyright statement;
- Updated copyright date;
- Updated with new editor's name and contact information;
- Added notice on intellectual property;
- Cosmetic fixes to layout and typography;
- Added table of contents;
- Title changed;
- Updated document headers and footers;
- Deleted the old clause 2.3, entitled "Access to Management
Information";
- Changed the way in which request-id was defined, though with
the same ultimate syntax and semantics, to avoid coupling with
SMI. This does not affect the protocol in any way;
- Replaced the word "exception" with the word "error" in the old
clause 4.1. This does not affect the protocol in any way;
- Deleted the first two paragraphs of the old clause 4.2;
- Clarified the maximum number of variable bindings that an
implementation must support in a PDU. This does not affect the
protocol in any way;
- Replaced occurrences of "SNMPv2 application" with
"application";
- Deleted three sentences in old clause 4.2.3 describing the
handling of an impossible situation. This does not affect the
protocol in any way;
- Clarified the use of the SNMPv2-Trap-Pdu in the old clause
4.2.6. This does not affect the protocol in any way;
- Aligned description of the use of the InformRequest-Pdu in old
clause 4.2.7 with the architecture. This does not affect the
protocol in any way;
- Updated references;
- Re-wrote introduction clause;
- Replaced manager/agent/SNMPv2 entity terminology with
terminology from RFC2571. This does not affect the protocol
in any way;
- Eliminated IMPORTS from the SMI, replaced with equivalent in-
line ASN.1. This does not affect the protocol in any way;
- Added notes calling attention to two different manifestations
of reaching the end of a table in the table walk examples;
- Added content to security considerations clause;
- Updated ASN.1 comment on use of Report-PDU. This does not
affect the protocol in any way;
- Updated acknowledgments section;
- Included information on handling of BITS;
- Deleted spurious comma in ASN.1 definition of PDUs;
- Added abstract;
- Made handling of additional variable bindings in informs
consistent with that for traps. This was a correction of an
editorial oversight, and reflects implementation practice;
- Added reference to RFC2914.
10. Editor's Address
Randy Presuhn
BMC Software, Inc.
2141 North First Street
San Jose, CA 95131
USA
Phone: +1 408 546 1006
EMail: randy_presuhn@bmc.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.