RFC 1503 (rfc1503) - Page 2 of 14
Algorithms for Automating Administration in SNMPv2 Managers
Alternative Format: Original Text Document
RFC 1503 Automating Administration in SNMPv2 Manager August 1993
approach should be readily adaptable to other models.
(Human) User
*
*
===========User Interface (UI)===========
*
+--------------------------+
... | Management Application N |
+---------------------------+ |
| Management Application 2 |-----+
+--------------------------+ | *
| Management Application 1 |----+ *
+--------------------------+ * *
* * *
========Management API======================
* *
* ________ *
+-------------+ / Local \ +---------------+
| Context |***/ Party \***| SNMP protocol |
| Resolver(s) | \ Database / | engine(s) |
+-------------+ \________/ +---------------+
*
*
===========Transport APIs============
*
+---------------------------------+
| Transport Stacks (e.g., UDP/IP) |
+---------------------------------+
*
Network(s)
Figure 2.1 SNMPv2 Manager Implementation Model
Note that there might be just one SNMP protocol engine and one
"context resolver" which are accessed by all local management
applications, or, each management application might have its own SNMP
protocol engine and its own "context resolver", all of which have
shared access to the local party database [2].
In addition to the elements shown in the figure, there would need to
be an interface for the administrator to access the local party
database, e.g., for configuring initial information, including
secrets. There might also be facilities for different users to have
different access privileges, and/or other reasons for there to be
multiple (coordinated) subsets of the local party database.
McCloghrie & Rose