doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc1909.txt b/doc/rfc/rfc1909.txt
new file mode 100644
index 0000000..d516239
--- /dev/null
+++ b/doc/rfc/rfc1909.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                              K. McCloghrie, Editor
+Request for Comments: 1909                           Cisco Systems, Inc.
+Category: Experimental                                     February 1996
+
+
+              An Administrative Infrastructure for SNMPv2
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   2. Overview ....................................................    2
+   2.1 Contexts ...................................................    3
+   2.2 Authorization: Access Rights and MIB Views .................    3
+   2.3 Authentication and Privacy .................................    4
+   2.4 Access Control .............................................    5
+   2.5 Security Models ............................................    5
+   2.6 Proxy ......................................................    5
+   3. Elements of the Model .......................................    7
+   3.1 SNMPv2 Entity ..............................................    7
+   3.2 SNMPv2 Agent ...............................................    7
+   3.3 SNMPv2 Manager .............................................    8
+   3.4 SNMPv2 Dual-Role Entity ....................................    8
+   3.5 View Subtree and Families ..................................    9
+   3.6 MIB View ...................................................    9
+   3.7 SNMPv2 Context .............................................   10
+   3.7.1 Local SNMPv2 Context .....................................   11
+   3.7.2 Proxy SNMPv2 Context .....................................   11
+   3.8 SNMPv2 PDUs and Operations .................................   12
+   3.8.1 The Report-PDU ...........................................   12
+   3.9 SNMPv2 Access Control Policy ...............................   13
+   4. Security Considerations .....................................   13
+   5. Editor's Address ............................................   14
+   6. Acknowledgements ............................................   14
+   7. References ..................................................   14
+   Appendix A Disambiguating the SNMPv2 Protocol Definition .......   16
+   Appendix B Who Sends Inform-Requests?  .........................   17
+   Appendix B.1 Management Philosophy .............................   17
+   Appendix B.2 The Danger of Trap Storms .........................   17
+   Appendix B.3 Inform-Requests ...................................   18
+
+
+
+
+
+McCloghrie                    Experimental                      [Page 1]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+1.  Introduction
+
+   A management system contains:  several (potentially many) nodes, each
+   with a processing entity, termed an agent, which has access to
+   management instrumentation; at least one management station; and, a
+   management protocol, used to convey management information between
+   the agents and management stations.  Operations of the protocol are
+   carried out under an administrative framework which defines
+   authentication, authorization, access control, and privacy policies.
+
+   Management stations execute management applications which monitor and
+   control managed elements.  Managed elements are devices such as
+   hosts, routers, terminal servers, etc., which are monitored and
+   controlled via access to their management information.
+
+   It is the purpose of this document, An Administrative Infrastructure
+   for SNMPv2, to define an administrative framework which realizes
+   effective management in a variety of configurations and environments.
+   The SNMPv2 framework is fully described in [1-6].  This framework is
+   derived from the original Internet-standard Network Management
+   Framework (SNMPv1), which consists of these three documents:
+
+      STD 16, RFC 1155 [7] which defines the Structure of Management
+      Information (SMI), the mechanisms used for describing and naming
+      objects for the purpose of management.
+
+      STD 16, RFC 1212 [8] which defines a more concise description
+      mechanism, which is wholly consistent with the SMI.
+
+      STD 15, RFC 1157 [9] which defines the Simple Network Management
+      Protocol (SNMP), the protocol used for network access to managed
+      objects.
+
+   For information on coexistence between SNMPv1 and SNMPv2, consult
+   [10].
+
+2.  Overview
+
+   A management domain typically contains a large amount of management
+   information.  Each individual item of management information is an
+   instance of a managed object type.  The definition of a related set
+   of managed object types is contained in a Management Information Base
+   (MIB) module.  Many such MIB modules are defined.  For each managed
+   object type it describes, a MIB module defines not only the semantics
+   and syntax of that managed object type, but also the method of
+   identifying an individual instance so that multiple instances of the
+   same managed object type can be distinguished.
+
+
+
+
+McCloghrie                    Experimental                      [Page 2]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+2.1.  Contexts
+
+   Typically, there are many instances of each managed object type
+   within a management domain.  For simplicity, the method for
+   identifying instances specified by the MIB module does not allow each
+   instance to be distinguished amongst the set of all instances within
+   the management domain; rather, it allows each instance to be
+   identified only within some scope or "context", where there are
+   multiple such contexts within the management domain.  Often, a
+   context is a physical device, or perhaps, a logical device, although
+   a context can also encompass multiple devices, or a subset of a
+   single device, or even a subset of multiple devices.  Thus, in order
+   to identify an individual item of management information within the
+   management domain, its context must be identified in addition to its
+   object type and its instance.
+
+   For example, the managed object type, ifDescr [11], is defined as the
+   description of a network interface.  To identify the description of
+   device-X's first network interface, three pieces of information are
+   needed, e.g., device-X (the context), ifDescr (the managed object
+   type), and "1" (the instance).
+
+   Note that each context has (at least) one globally-unique
+   identification within the management domain.  Note also that the same
+   item of management information can exist in multiple contexts.  So,
+   an item of management information can have multiple globally-unique
+   identifications, either because it exists in multiple contexts,
+   and/or because each such context has multiple globally-unique
+   identifications.
+
+2.2.  Authorization: Access Rights and MIB Views
+
+   For security reasons, it is often valuable to be able to restrict the
+   access rights of some management applications to only a subset of the
+   management information in the management domain.  To provide this
+   capability, access to a context is via a "MIB view" which details a
+   specific set of managed object types (and optionally, the specific
+   instances of object types) within that context.  For example, for a
+   given context, there will typically always be one MIB view which
+   provides access to all management information in that context, and
+   often there will be other MIB views each of which contains some
+   subset of the information.  So, by providing access rights to a
+   management application in terms of the particular (subset) MIB view
+   it can access for that context, then the management application is
+   restricted in the desired manner.
+
+   Since managed object types (and their instances) are identified via
+   the tree-like naming structure of ISO's OBJECT IDENTIFIERs [12, 1],
+
+
+
+McCloghrie                    Experimental                      [Page 3]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   it is convenient to define a MIB view as the combination of a set of
+   "view subtrees", where each view subtree is a sub-tree within the
+   managed object naming tree.  Thus, a simple MIB view (e.g., all
+   managed objects within the Internet Network Management Framework) can
+   be defined as a single view sub-tree, while more complicated MIB
+   views (e.g., all information relevant to a particular network
+   interface) can be represented by the union of multiple view sub-
+   trees.
+
+   While any set of managed objects can be described by the union of
+   some number of view subtrees, situations can arise that would require
+   a very large number of view subtrees.  This could happen, for
+   example, when specifying all columns in one conceptual row of a MIB
+   table because they would appear in separate subtrees, one per column,
+   each with a very similar format.  Because the formats are similar,
+   the required set of subtrees can easily be aggregated into one
+   structure.  This structure is named a family of view subtrees after
+   the set of subtrees that it conceptually represents.  A family of
+   view subtrees can either be included or excluded from a MIB view.
+
+   In addition to restricting access rights by identifying (sub-)sets of
+   management information, it is also valuable to restrict the requests
+   allowed on the management information within a particular context.
+   For example, one management application might be prohibited from
+   write-access to a particular context, while another might be allowed
+   to perform any type of operation.
+
+2.3.  Authentication and Privacy
+
+   The enforcement of access rights requires the means not only to
+   identify the entity on whose behalf a request is generated but also
+   to authenticate such identification.  Another security capability
+   which is (optionally) provided is the ability to protect the data
+   within an SNMPv2 operation from disclosure (i.e., to encrypt the
+   data).  This is particularly useful when sensitive data (e.g.,
+   passwords, or security keys) are accessed via SNMPv2 requests.
+
+   Recommendations for which algorithms are best for authentication and
+   privacy are subject to change.  Such changes may occur as and when
+   new research results on the vulnerability of various algorithms are
+   published, and/or with the prevailing status of export control and
+   patent issues.  Thus, it is valuable to allow these algorithms to be
+   specified as parameters, so that new algorithms can be accommodated
+   over time.  In particular, one type of algorithm which may become
+   useful in the future is the set of algorithms associated with
+   asymmetric (public key) cryptography.
+
+   Note that not all accesses via SNMPv2 requests need to be secure.
+
+
+
+McCloghrie                    Experimental                      [Page 4]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   Indeed, there are purposes for which insecure access is required.
+   One example of this is the ability of a management application to
+   learn about devices of which it has no previous knowledge.  Another
+   example is to perform any synchronization which the security
+   algorithms need before they can be used to communicate securely.
+   This need for insecure access is accommodated by defining one of the
+   algorithms for authentication as providing no authentication, and
+   similarly, one of the algorithms for privacy as providing no
+   protection against disclosure.  (The combination of these two
+   insecure algorithms is sometimes referred to as "noAuth/noPriv".)
+
+2.4.  Access Control
+
+   An access control policy specifies the types of SNMPv2 requests and
+   associated MIB views which are authorized for a particular identity
+   (on whose behalf a request is generated) when using a particular
+   level of security to access a particular context.
+
+2.5.  Security Models
+
+   A security model defines the mechanisms used to achieve an
+   administratively-defined level of security for protocol interactions:
+
+(1)  by defining the security parameters associated with a
+     communication, including the authentication and privacy algorithms
+     and the security keys (if any) used.
+
+(2)  by defining how entities on whose behalf requests are generated are
+     identified.
+
+(3)  by defining how contexts are identified.
+
+(4)  by defining the mechanisms by which an access control policy is
+     derived whenever management information is to be accessed.
+
+2.6.  Proxy
+
+   It is an SNMPv2 agent which responds to requests for access to
+   management information.  Each such request is contained within an
+   SNMPv2 message which provides the capability to perform a single
+   operation on a list of items of management information.  Rather than
+   having to identify the context as well as the managed object type and
+   instance for each item of management information, each SNMPv2 message
+   is concerned with only a single context.  Thus, an SNMPv2 agent must
+   be able to process requests for all items of management information
+   within the one or more contexts it supports.
+
+
+
+
+
+McCloghrie                    Experimental                      [Page 5]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   In responding to a request, an SNMPv2 agent might be acting as a
+   proxy for some other agent.  The term "proxy" has historically been
+   used very loosely, with multiple different meanings.  These different
+   meanings include (among others):
+
+(1)  the forwarding of SNMPv2 requests on to other SNMP agents without
+     regard for what managed object types are being accessed; for
+     example, in order to forward SNMPv2 request from one transport
+     domain to another, or to translate SNMPv2 requests into SNMPv1
+     requests;
+
+(2)  the translation of SNMPv2 requests into operations of some non-SNMP
+     management protocol;
+
+(3)  support for aggregated managed objects where the value of one
+     managed object instance depends upon the values of multiple other
+     (remote) items of management information.
+
+   Each of these scenarios can be advantageous; for example, support for
+   aggregation for management information can significantly reduce the
+   bandwidth requirements of large-scale management activities.
+   However, using a single term to cover multiple different scenarios
+   causes confusion.
+
+   To avoid such confusion, this SNMPv2 administrative framework uses
+   the term "proxy" with a much more tightly defined meaning, which
+   covers only the first of those listed above.  Specifically, the
+   distinction between a "regular SNMPv2 agent" and a "proxy SNMPv2
+   agent" is simple:
+
+  -  a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on
+     to other agents according to the context, and irrespective of the
+     specific managed object types being accessed;
+
+  -  in contrast, an SNMPv2 agent which processes SNMPv2 requests
+     according to the (names of the) individual managed object types and
+     instances being accessed, is NOT a proxy SNMPv2 agent from the
+     perspective of this administrative model.
+
+   Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for a
+   particular context, although information on how to forward the
+   request is specifically associated with that context, the proxy
+   SNMPv2 agent has no need of a detailed definition of the MIB view
+   (since the proxy SNMPv2 agent forwards the request irrespective of
+   the managed object types).
+
+   In contrast, a SNMPv2 agent operating without proxy must have the
+   detailed definition of the MIB view, and even if it needs to issue
+
+
+
+McCloghrie                    Experimental                      [Page 6]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   requests to other agents, that need is dependent on the individual
+   managed object instances being accessed (i.e., not only on the
+   context).
+
+3.  Elements of the Model
+
+   This section provides a more formal description of the model.
+
+3.1.  SNMPv2 Entity
+
+   An SNMPv2 entity is an actual process which performs management
+   operations by generating and/or responding to SNMPv2 protocol
+   messages in the manner specified in [4].  An SNMPv2 entity assumes
+   the identity of a particular administrative entity when processing an
+   SNMPv2 message.
+
+   An SNMPv2 entity is not required to process multiple protocol
+   messages concurrently, regardless of whether such messages require it
+   to assume the identity of the same or different administrative
+   entity.  Thus, an implementation of an SNMPv2 entity which supports
+   more than one administrative entity need not be multi-threaded.
+   However, there may be situations where implementors may choose to use
+   multi-threading.
+
+   An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on
+   each transport service address for which it is configured to do so.
+   It is a local matter whether an SNMPv2 entity also listens for SNMPv2
+   messages on any other transport service addresses.  In the absence of
+   any other information on where to listen, an SNMPv2 entity must
+   listen on the transport service addresses corresponding to the
+   standard transport-layer "ports" [5] on its local network-layer
+   addresses.
+
+3.2.  SNMPv2 Agent
+
+   An SNMPv2 agent is the operational role assumed by an SNMPv2 entity
+   when it acts in an agent role.  Specifically, an SNMPv2 agent
+   performs SNMPv2 management operations in response to received SNMPv2
+   protocol messages (except for inform notifications).
+
+   In order to be manageable, all network components need to be
+   instrumented.  SNMPv2 access to the instrumented information is via
+   the managed objects supported by an SNMPv2 agent in one or more
+   contexts.
+
+
+
+
+
+
+
+McCloghrie                    Experimental                      [Page 7]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+3.3.  SNMPv2 Manager
+
+   An SNMPv2 manager is the operational role assumed by an SNMPv2 entity
+   when it acts in a manager role on behalf of management applications.
+   Specifically, an SNMPv2 manager initiates SNMPv2 management
+   operations by the generation of appropriate SNMPv2 protocol messages,
+   or when it receives and processes trap and inform notifications.
+
+   It is interesting to consider the case of managing an SNMPv2 manager.
+   It is highly desirable that an SNMPv2 manager, just like any other
+   networking application, be instrumented for the purposes of being
+   managed.  Such instrumentation of an SNMPv2 manager (just like for
+   any other networking application) is accessible via the managed
+   objects supported by an SNMPv2 agent.  As such, an SNMPv2 manager is
+   no different from any other network application in that it has
+   instrumentation, but does not itself have managed objects.
+
+   That is, an SNMPv2 manager does not itself have managed objects.
+   Rather, it is an associated SNMPv2 agent supporting managed objects
+   which provides access to the SNMPv2 manager's instrumentation.
+
+3.4.  SNMPv2 Dual-Role Entity
+
+   An SNMPv2 entity which sometimes acts in an agent role and sometimes
+   acts in a manager role, is termed an SNMPv2 dual-role entity.  An
+   SNMPv2 dual-role entity initiates requests by acting in a manager
+   role, and processes requests regarding management information
+   accessible to it (locally or via proxy) through acting in an agent
+   role.  In the case of sending inform notifications, an SNMPv2 dual-
+   role entity acts in a manager role in initiating an inform
+   notification containing management information which is accessible to
+   it when acting in an agent role.
+
+   An SNMPv2 entity which can act only in an SNMPv2 manager role is not
+   SNMP-manageable, since there is no way to access its management
+   instrumentation.  In order to be SNMP-manageable, an SNMPv2 entity
+   must be able to act in an SNMPv2 agent role in order to allow its
+   instrumentation to be accessed.  Thus, it is highly desirable that
+   all SNMPv2 entities be either SNMPv2 agents or SNMPv2 dual-role
+   entities.
+
+   There are two categories of SNMPv2 dual-role entities:  proxy SNMPv2
+   agents and (so-called) mid-level managers.  Proxy SNMPv2 agents only
+   forward requests/responses; they do not originate requests.  In
+   contrast, mid-level managers often originate requests.  (Note that
+   the term proxy SNMPv2 agent does not include an SNMPv2 agent which
+   translates SNMPv2 requests into the requests of some other management
+   protocol; see section 2.6.)
+
+
+
+McCloghrie                    Experimental                      [Page 8]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+3.5.  View Subtree and Families
+
+   A view subtree is the set of all MIB object instances which have a
+   common ASN.1 OBJECT IDENTIFIER prefix to their names.  A view subtree
+   is identified by the OBJECT IDENTIFIER value which is the longest
+   OBJECT IDENTIFIER prefix common to all (potential) MIB object
+   instances in that subtree.
+
+   A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
+   (called the family name) together with a bitstring value (called the
+   family mask).  The family mask indicates which sub-identifiers of the
+   associated family name are significant to the family's definition.
+
+   For each possible managed object instance, that instance belongs to a
+   particular view subtree family if both of the following conditions
+   are true:
+
+o    the OBJECT IDENTIFIER name of the managed object instance contains
+     at least as many sub-identifiers as does the family name, and
+
+o    each sub-identifier in the OBJECT IDENTIFIER name of the managed
+     object instance matches the corresponding sub-identifier of the
+     family name whenever the corresponding bit of the associated family
+     mask is non-zero.
+
+   When the configured value of the family mask is all ones, the view
+   subtree family is identical to the single view subtree identified by
+   the family name.
+
+   When the configured value of the family mask is shorter than required
+   to perform the above test, its value is implicitly extended with
+   ones.  Consequently, a view subtree family having a family mask of
+   zero length always corresponds to a single view subtree.
+
+3.6.  MIB View
+
+   A MIB view is a subset of the set of all instances of all object
+   types defined according to the SMI [1] within an SNMPv2 context,
+   subject to the following constraints:
+
+o    It is possible to specify a MIB view which contains the full set of
+     all object instances within an SNMPv2 context.
+
+o    Each object instance within a MIB view is uniquely named by an
+     ASN.1 OBJECT IDENTIFIER value.
+
+   As such, identically named instances of a particular object type must
+   be contained within different SNMPv2 contexts.  That is, a particular
+
+
+
+McCloghrie                    Experimental                      [Page 9]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   object instance name resolves within a particular SNMPv2 context to
+   at most one object instance.
+
+   A MIB view is defined as a collection of view subtree families, where
+   each view subtree family has a type.  The type determines whether the
+   view subtree family is included in, or excluded from, the MIB view.
+
+   A managed object instance is contained/not contained within the MIB
+   view according to the view subtree families to which the instance
+   belongs:
+
+o    If a managed object instance belongs to none of the relevant
+     subtree families, then that instance is not in the MIB view.
+
+o    If a managed object instance belongs to exactly one of the relevant
+     subtree families, then that instance is included in, or excluded
+     from, the relevant MIB view according to the type of that subtree
+     family.
+
+o    If a managed object instance belongs to more than one of the
+     relevant subtree families, then that instance is included in, or
+     excluded from, the relevant MIB view according to the type of a
+     particular one of the subtree families to which it belongs.  The
+     particular subtree family is the one for which, first, the
+     associated family name comprises the greatest number of sub-
+     identifiers, and, second, the associated family name is
+     lexicographically greatest.
+
+3.7.  SNMPv2 Context
+
+   An SNMPv2 context is a collection of management information
+   accessible by an SNMPv2 entity.  The collection of management
+   information identified by a context is either local or proxy.
+
+   For a local SNMPv2 context which is realized by an SNMPv2 entity,
+   that SNMPv2 entity uses locally-defined mechanisms to access the
+   management information identified by the SNMPv2 context.
+
+   For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2
+   agent to access the management information identified by the SNMPv2
+   context.
+
+   The term remote SNMPv2 context is used at an SNMPv2 manager to
+   indicate a SNMPv2 context (either local or proxy) which is not
+   realized by the local SNMPv2 entity (i.e.,  the local SNMPv2 entity
+   uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2
+   agent, to access the management information identified by the SNMPv2
+   context).
+
+
+
+McCloghrie                    Experimental                     [Page 10]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+3.7.1.  Local SNMPv2 Context
+
+   A local context refers to a collection of MIB objects which
+   (logically) belong to a single entity within a managed device.  When
+   an SNMPv2 entity accesses that management information, it does so
+   using locally-defined mechanisms.
+
+   Because a device may contain several such local entities, each local
+   context has associated with it a "local entity" name.  Further,
+   because management information changes over time, each local context
+   also has associated with it an associated temporal domain, termed its
+   "local time".  This allows, for example, one context to refer to the
+   current values of a device's parameters, and a different context to
+   refer to the values that the same parameters for the same device will
+   have after the device's next restart.
+
+3.7.2.  Proxy SNMPv2 Context
+
+   A proxy relationship exists when a proxy SNMPv2 agent processes a
+   received SNMPv2 message (a request or a response) by forwarding it to
+   another entity, solely according to the SNMPv2 context of the
+   received message.  Such a context is called a proxy SNMPv2 context.
+   When an SNMPv2 entity processes management requests/responses for a
+   proxy context, it is operating as a proxy SNMPv2 agent.
+
+   The transparency principle that defines the behavior of an SNMPv2
+   entity in general, applies in particular to a proxy SNMPv2 context:
+
+     The manner in which a receiving SNMPv2 entity processes SNMPv2
+     protocol messages sent by another SNMPv2 entity is entirely
+     transparent to the sending SNMPv2 entity.
+
+   Implicit in the transparency principle is the requirement that the
+   semantics of SNMPv2 management operations are preserved between any
+   two SNMPv2 peers.  In particular, the "as if simultaneous" semantics
+   of a
+
+   Set operation are extremely difficult to guarantee if its scope
+   extends to management information resident at multiple network
+   locations.  Note however, that agents which support the forwarding of
+   Set operations concerning information at multiple locations are not
+   considered to be proxy SNMPv2 agents (see section 2.6 above).
+
+   Also implicit in the transparency principle is the requirement that,
+   throughout its interaction with a proxy SNMPv2 agent, an SNMPv2
+   manager is supplied with no information about the nature or progress
+   of the proxy mechanisms used to perform its requests.  That is, it
+   should seem to the SNMPv2 manager (except for any distinction in an
+
+
+
+McCloghrie                    Experimental                     [Page 11]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   underlying transport address) as if it were interacting via SNMPv2
+   directly with the proxied device.  Thus, a timeout in the
+   communication between a proxy SNMPv2 agent and its proxied device
+   should be represented as a timeout in the communication between the
+   SNMPv2 manager and the proxy SNMPv2 agent.  Similarly, an error
+   response from a proxied device should - as much as possible - be
+   represented by the corresponding error response in the interaction
+   between the proxy SNMPv2 agent and SNMPv2 manager.
+
+3.8.  SNMPv2 PDUs and Operations
+
+   An SNMPv2 PDU is defined in [4].  Each SNMPv2 PDU specifies a
+   particular operation, one of:
+
+               GetBulkRequest
+               GetNextRequest
+               GetRequest
+               Inform
+               Report
+               Response
+               SNMPv2-Trap
+               SetRequest
+
+3.8.1.  The Report-PDU
+
+   [4] requires that an administrative framework which makes use of the
+   Report-PDU must define its usage and semantics.  With this
+   administrative framework, the Report-PDU differs from the other PDU
+   types described in [4] in that it is not a protocol operation between
+   SNMPv2 managers and agents, but rather is an aspect of error-
+   reporting between SNMPv2 entities. Specifically, it is an interaction
+   between two protocol engines.
+
+   A communication between SNMPv2 entities is in the form of an SNMPv2
+   message.  Such a message is formatted as a "wrapper" encapsulating a
+   PDU according to the "Elements of Procedure" for the security model
+   used for transmission of the message.
+
+   While processing a received communication, an SNMPv2 entity may
+   determine that the received message is unacceptable due to a problem
+   associated with the contents of the message "wrapper".  In this case,
+   an appropriate counter is incremented and the received message is
+   discarded without further processing (and without transmission of a
+   Response-PDU).
+
+   However, if an SNMPv2 entity acting in the agent role makes such a
+   determination, then after incrementing the appropriate counter, it
+   may be required to generate a Report-PDU and to send it to the
+
+
+
+McCloghrie                    Experimental                     [Page 12]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   transport address which originated the received message.
+
+   If the agent is able to determine the value of the request-id field
+   of the received PDU [4], then it must use that value for the
+   request-id field of the Report-PDU.  Otherwise, the value 2147483647
+   is used.
+
+   The error-status and error-index fields of the Report-PDU are always
+   set to zero.  The variable-bindings field contains a single variable:
+   the identity of the counter which was incremented and its new value.
+
+   There is at least one case in which a Report-PDU must not be sent by
+   an SNMPv2 entity acting in the agent role: if the received message
+   was tagged as a Report-PDU.  Particular security models may identify
+   other such cases.
+
+3.9.  SNMPv2 Access Control Policy
+
+   An SNMPv2 access policy specifies the types of SNMPv2 operations
+   authorized for a particular identity using a particular level of
+   security, and if the operation is to be performed on a local SNMPv2
+   context, two accessible MIB views.  The two MIB views are a read-view
+   and a write-view.  A read-view is a set of object instances
+   authorized for the identity when reading objects.  Reading objects
+   occurs when processing a retrieval (get, get-next, get-bulk)
+   operation and when sending a notification.  A write-view is the set
+   of object instances authorized for the identity when writing objects.
+   Writing objects occurs when processing a set operation.  An
+   identity's access rights may be different at different agents.
+
+   A security model defines how an SNMPv2 access policy is derived;
+   however, the application of an SNMPv2 access control policy is
+   performed only:
+
+o    on receipt of GetRequest, GetNextRequest, GetBulkRequest, and
+     SetRequest operations; and
+
+o    prior to transmission of SNMPv2-Trap and Inform operations.
+
+   Note that application of an SNMPv2 access control policy is never
+   performed for Response or Report operations.
+
+4.  Security Considerations
+
+   Security issues are not directly discussed in this memo.
+
+
+
+
+
+
+McCloghrie                    Experimental                     [Page 13]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+5.  Editor's Address
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+   US
+
+   Phone: +1 408 526 5260
+   EMail: kzm@cisco.com
+
+6.  Acknowledgements
+
+   This document is the result of significant work by three major
+   contributors:
+
+     Keith McCloghrie (Cisco Systems, kzm@cisco.com)
+     Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
+     Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca)
+
+   The authors wish to acknowledge James M. Galvin of Trusted
+   Information Systems who contributed significantly to earlier work on
+   which this memo is based, and the general contributions of members of
+   the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov and
+   Steven L. Waldbusser.
+
+   A special thanks is extended for the contributions of:
+
+     Uri Blumenthal (IBM)
+     Shawn Routhier (Epilogue)
+     Barry Sheehan (IBM)
+     Bert Wijnen (IBM)
+
+7.  References
+
+[1]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Structure of Management Information for Version 2
+     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
+     January 1996.
+
+[2]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
+
+[3]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S., Waldbusser, "Conformance Statements for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
+
+
+
+
+McCloghrie                    Experimental                     [Page 14]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+[4]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+[5]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     Waldbusser, S., "Transport Mappings for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+[6]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     Waldbusser, S., "Management Information Base for Version 2 of the
+     Simple Network Management Protocol (SNMPv2)", RFC 1907,
+     January 1996.
+
+[7]  Rose, M., and K. McCloghrie, "Structure and Identification of
+     Management Information for TCP/IP-based internets", STD 16, RFC
+     1155, May 1990.
+
+[8]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
+     RFC 1212, March 1991.
+
+[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+     Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+     Performance Systems International, MIT Laboratory for Computer
+     Science, May 1990.
+
+[10] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     Waldbusser, S., "Coexistence between Version 1 and Version 2 of the
+     Internet-standard Network Management Framework", RFC 1908, January
+     1996.
+
+[11] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces
+     Group of MIB-II", RFC 1573, Cisco Systems, FTP Software, January
+     1994.
+
+[12] Information processing systems - Open Systems Interconnection -
+     Specification of Abstract Syntax Notation One (ASN.1),
+     International Organization for Standardization.  International
+     Standard 8824, (December, 1987).
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie                    Experimental                     [Page 15]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+APPENDIX A - Disambiguating the SNMPv2 Protocol Definition
+
+The descriptions in [4] of the role in which an SNMPv2 entity acts when
+sending an Inform-Request PDU are ambiguous.  The following updates
+serve to remove those ambiguities.
+
+(1)  Add the following sentence to section 2.1:
+
+          Further, when an SNMPv2 entity sends an inform notification,
+          it acts in a manager role in respect to initiating the
+          operation, but the management information contained in the
+          inform notification is associated with that entity acting in
+          an agent role.  By convention, the inform is sent from the
+          same transport address as the associated agent role is
+          listening on.
+
+(2)  Modify the last sentence of the second paragraph in section 2.3:
+
+          This type is used by one SNMPv2 entity, acting in a manager
+          role, to notify another SNMPv2 entity, also acting in a
+          manager role, of management information associated with the
+          sending SNMPv2 entity acting in an agent role.
+
+(3)  Modify the second paragraph of section 4.2 (concerning the
+     generation of Inform-Request PDUs):
+
+          It is mandatory that all SNMPv2 entities acting in a manager
+          role be able to generate the following PDU types: GetRequest-
+          PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
+          and Response-PDU; further, all such implementations must be
+          able to receive the following PDU types: Response-PDU,
+          SNMPv2-Trap-PDU, InformRequest-PDU.  It is mandatory that all
+          dual-role SNMPv2 entities must be able to generate an Inform-
+          Request PDU.
+
+(4)  Modify the first paragraph of section 4.2.7:
+
+          An InformRequest-PDU is generated and transmitted at the
+          request of an application in a SNMPv2 entity acting in a
+          manager role, that wishes to notify another application (via
+          an SNMPv2 entity also acting in a manager role) of information
+          in a MIB view which is accessible to the sending SNMPv2 entity
+          when acting in an agent role.
+
+
+
+
+
+
+
+
+McCloghrie                    Experimental                     [Page 16]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+APPENDIX B - Who Sends Inform-Requests?
+
+B.1.   Management Philosophy
+
+   Ever since its beginnings as SGMP, through its definition as SNMPv1,
+   and continuing with the definition of SNMPv2, SNMP has embodied more
+   than just a management protocol and the definitions of MIB objects.
+   Specifically, SNMP has also had a fundamental philosophy of
+   management, consisting of a number of design strategies.  These
+   strategies have always included the following:
+
+(1)  The impact of incorporating an SNMP agent into a system should be
+     minimal, so that both: a) it is feasible to do so even in the
+     smallest/cheapest of systems, and b) the operational role and
+     performance of a system is not compromised by the inclusion of an
+     SNMP agent.  This promotes widespread development, which allows
+     ubiquitous deployment of manageable systems.
+
+(2)  Every system (potentially) incorporates an SNMP agent.  In
+     contrast, the number of SNMP managers is limited.  Thus, there is a
+     significantly larger number of SNMP agents than SNMP managers.
+     Therefore, overall system development/complexity/cost is optimized
+     if the SNMP agent is allowed to be simple and any required
+     complexity is performed by an SNMP manager.
+
+(3)  The number of unsolicited messages generated by SNMP agents is
+     minimized.  This enables the amount of network management traffic
+     to be controlled by the small number of SNMP managers which are
+     (more) directly controlled by network operators.  In fact, this
+     control is considered of greater importance than any additional
+     protocol overhead which might be incurred.  Monitoring of network
+     state at any significant level of detail is accomplished primarily
+     by SNMP managers polling for the appropriate information, with the
+     use of unsolicited messages confined to those situations where it
+     is necessary to properly guide an SNMP manager regarding the timing
+     and focus of its polling.  This strategy is sometimes referred to
+     as "trap-directed polling".
+
+B.2.   The Danger of Trap Storms
+
+   The need for such control over the amount of network management
+   traffic is due to the potential that the SNMP manager receiving an
+   unsolicited message does not want, no longer wants, or already knows
+   of the information contained in the message.  This potential is
+   significantly reduced by having the majority of messages be specific
+   requests for information by SNMP managers and responses (to those
+   requests) from SNMP agents.
+
+
+
+
+McCloghrie                    Experimental                     [Page 17]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   The danger of not having the amount of network management be
+   controlled in this manner is the potential for a "storm" of useless
+   traps.  As a simple example of "useless", consider that after a
+   building power outage, every device in the network sends a coldStart
+   trap, even though every SNMP manager and every network operator
+   already knows what happened.  For a simple example of "storm",
+   consider the result if each transmitted trap caused the sending of
+   another.  The greater the number of problems in the state of the
+   network, the greater the risk of such a storm occurring, especially
+   in the unstructured, heterogeneous environment typical of today's
+   internets.
+
+   While SNMP philosophy considers the above to be more important than
+   any lack of reliability in unsolicited messages, some
+   users/developers have been wary of using traps because of the use
+   (typically) of an unreliable transport protocol and because traps are
+   not acknowledged.  However, following this logic would imply that
+   having acknowledged-traps would make them reliable; of course, this
+   is false since no amount of re- transmission will succeed if the
+   receiver and/or the connectivity to the receiver is down.  A SNMP
+   manager cannot just sit and wait and assume the network is fine just
+   because it is not receiving any unsolicited messages.
+
+B.3.   Inform-Requests
+
+   One of the new features of SNMPv2 is the Inform-request PDU.  The
+   Inform-Request contains management information specified in terms of
+   MIB objects for a context supported by the sender.  Since by
+   definition, an SNMPv2 manager does not itself have managed objects
+   (see sections 3.3), the managed objects contained in the Inform-
+   request belong to a context of an SNMPv2 agent, just like the managed
+   objects contained in an SNMPv2-Trap.
+
+   However, it is not the purpose of an Inform-request to change the
+   above described philosophy, i.e., it would be wrong to consider it as
+   an "acknowledged trap".  To do so, would make the likelihood and
+   effect of trap storms worse.  Recall the building power outage
+   example:  with regular traps, the SNMP manager's buffer just
+   overflows when it receives messages faster than it can cope with; in
+   contrast, if every device in the network were to send a coldStart
+   Inform-request, then after a power outage, all will re-transmit their
+   Inform-request several times unless the receiving SNMP managers send
+   responses.  In the best case when no messages are lost or re-
+   transmitted, there are twice as many useless messages; in the worst
+   case, the SNMP manager is unable to respond at all and every message
+   is re-transmitted its maximum number of times.
+
+
+
+
+
+McCloghrie                    Experimental                     [Page 18]
+
+RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996
+
+
+   The above serves to explain the rationale behind the definition (see
+   Appendix A's update to section 4.2.7 of [4]) that:
+
+     An InformRequest-PDU is generated and transmitted at the request of
+     an application in a SNMPv2 entity acting in a manager role, that
+     wishes to notify another application (via an SNMPv2 entity also
+     acting in a manager role) of information in a MIB view which is
+     accessible to the sending SNMPv2 entity when acting in an agent
+     role.
+
+   This definition says that SNMPv2 agents do not send Inform-Requests,
+   which has three implications (ordered in terms of importance):
+
+(1)  the number of devices which send Inform-requests is required to be
+     a small subset of all devices in the network;
+
+(2)  while some devices traditionally considered to be SNMP agents are
+     perfectly capable of sending Inform-requests, the overall system
+     development/complexity/cost is not increased as it would be by
+     having to configure/re-configure every SNMPv2 agent as to which
+     Inform-requests to send where and how often; and
+
+(3)  the cost of implementing an SNMPv2 agent in the smallest/cheapest
+     system is not increased.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie                    Experimental                     [Page 19]
+