Because MIB view definitions may, in certain cases, comprise a
very large number of view subtrees, a convention for
abbreviating MIB view definitions is desirable.
The convention adopted in [4] supports abbreviation of MIB
view definitions in terms of families of view subtrees that
are either included in or excluded from the definition of the
relevant MIB view. By this convention, a table locally
maintained by each SNMPv2 entity defines the MIB view
associated with each SNMPv2 context that refers to local
object resources. Each entry in the table represents a family
of view subtrees that (according to the type of that entry) is
either included in or excluded from the MIB view of some
RFC1445 Administrative Model for SNMPv2 April 1993
SNMPv2 context. Each table entry represents a subtree family
as 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 definition of
the represented subtree family. For each possible MIB object
instance, that instance belongs to the view subtree family
represented by a particular table entry if
o the OBJECT IDENTIFIER name of that MIB object instance
comprises at least as many sub-identifiers as does the
family name for said table entry, and
o each sub-identifier in the name of said MIB object
instance matches the corresponding sub-identifier of the
relevant family name whenever the corresponding bit of
the associated family mask is non-zero.
The appearance of a MIB object instance in the MIB view for a
particular SNMPv2 context is related to the membership of that
instance in the subtree families associated with that SNMPv2
context in local table entries:
o If a MIB object instance belongs to none of the relevant
subtree families, then that instance is not in the MIB
view for the relevant SNMPv2 context.
o If a MIB object instance belongs to the subtree family
represented by exactly one of the relevant table entries,
then that instance is included in, or excluded from, the
relevant MIB view according to the type of that entry.
o If a MIB object instance belongs to the subtree families
represented by more than one of the relevant table
entries, then that instance is included in, or excluded
from, the relevant MIB view according to the type of the
single such table entry for which, first, the associated
family name comprises the greatest number of sub-
identifiers, and, second, the associated family name is
lexicographically greatest.
The subtree family represented by a table entry for which the
associated family mask is all ones corresponds to the single
view subtree identified by the family name for that entry.
Because the convention of [4] provides for implicit extension
RFC1445 Administrative Model for SNMPv2 April 1993
of family mask values with ones, the subtree family
represented by a table entry with a family mask of zero length
always corresponds to a single view subtree.
Context Type Family Name Family Mask
lucy included internet ''H
Table 6: View Definition for Minimal Agent
Using this convention for abbreviating MIB view definitions,
some of the most common definitions of MIB views may be
conveniently expressed. For example, Table 6 illustrates the
MIB view definitions required for a minimal SNMPv2 entity that
having a single SNMPv2 context for which the associated MIB
view embraces all instances of all MIB objects defined within
the SNMPv2 Network Management Framework. The represented
table has a single entry. The SNMPv2 context (lucy) for which
that entry defines the MIB view is identified in the first
column. The type of that entry (included) signifies that any
MIB object instance belonging to the subtree family
represented by that entry may appear in the MIB view for the
SNMPv2 context lucy. The family name for that entry is
internet, and the zero-length family mask value signifies that
the relevant subtree family corresponds to the single view
subtree rooted at that node.
Another example of MIB view definition (see Table 7) is that
of a SNMPv2 entity having multiple SNMPv2 contexts with
distinct MIB views. The MIB view associated with the SNMPv2
context lucy comprises all instances of all MIB objects
defined within the SNMPv2 Network Management Framework, except
those pertaining to the administration of SNMPv2 parties. In
contrast, the MIB view attributed to the SNMPv2 context ricky
contains only MIB object instances defined in the system group
of the Internet-standard MIB together with those object
instances by which SNMPv2 parties are administered.
RFC1445 Administrative Model for SNMPv2 April 1993
Context Type Family Name Family Mask
lucy included internet ''H
lucy excluded snmpParties ''H
ricky included system ''H
ricky included snmpParties ''H
Table 7: View Definition for Multiple Contexts
A more complicated example of MIB view configuration
illustrates the abbreviation of related collections of view
subtrees by view subtree families (see Table 8). In this
example, the MIB view associated with the SNMPv2 context lucy
includes all object instances in the system group of the
Internet-standard MIB together with some information related
to the second network interface attached to the managed
device. However, this interface-related information does not
include the speed of the interface. The family mask value
'FFA0'H in the second table entry signifies that a MIB object
instance belongs to the relevant subtree family if the initial
prefix of its name places it within the ifEntry portion of the
registration hierarchy and if the eleventh sub-identifier of
its name is 2. The MIB object instance representing the speed
of the second network interface belongs to the subtree
families represented by both the second and third entries of
the table, but that particular instance is excluded from the
MIB view for the SNMPv2 context lucy because the
lexicographically greater of the relevant family names appears
in the table entry with type excluded.
The MIB view for the SNMPv2 context ricky is also defined in
this example. The MIB view attributed to the SNMPv2 context
ricky includes all object instances in the icmp group of the
Internet-standard MIB, together with all information relevant
to the fifth network interface attached to the managed device.
In addition, the MIB view attributed to the SNMPv2 context
ricky includes the number of octets received on the fourth
attached network interface.
RFC1445 Administrative Model for SNMPv2 April 1993
Context Type Family Name Family Mask
lucy included system ''H
lucy included { ifEntry 0 2 } 'FFA0'H
lucy excluded { ifSpeed 2 } ''H
ricky included icmp ''H
ricky included { ifEntry 0 5 } 'FFA0'H
ricky included { ifInOctets 4 } ''H
Table 8: More Elaborate View Definitions
While, as suggested by the examples above, a wide range of MIB
view configurations are efficiently supported by the
abbreviated representation of [4], prudent MIB design can
sometimes further reduce the size and complexity of the most
likely MIB view definitions. On one hand, it is critical that
mechanisms for MIB view configuration impose no absolute
constraints either upon the access policies of local
administrations or upon the structure of MIB namespaces; on
the other hand, where the most common access policies are
known, the configuration costs of realizing those policies may
be slightly reduced by assigning to distinct portions of the
registration hierarchy those MIB objects for which local
policies most frequently require distinct treatment.
4.4. Proxy Configuration
This section presents examples of SNMPv2 proxy configurations.
On one hand, foreign proxy configurations provide the
capability to manage non-SNMP devices. On the other hand,
native proxy configurations allow an administrator to shift
the computational burden of rich management functionality away
from network devices whose primary task is not management. To
the extent that SNMPv2 proxy agents function as points of
aggregation for management information, proxy configurations
may also reduce the bandwidth requirements of large-scale
management activities.
The example configurations in this section are simplified for
clarity: actual configurations may require additional parties
in order to support clock synchronization and distribution of
secrets.
RFC1445 Administrative Model for SNMPv2 April 1993
4.4.1. Foreign Proxy Configuration
This section presents an example configuration by which a
SNMPv2 management station may manage network elements that do
not themselves support the SNMPv2. This configuration centers
on a SNMPv2 proxy agent that realizes SNMPv2 management
operations by interacting with a non-SNMPv2 device using a
proprietary protocol.
Table 9 presents information about SNMPv2 parties that is
recorded in the SNMPv2 proxy agent's local database of party
information. Table 10 presents information about proxy
relationships that is recorded in the SNMPv2 proxy agent's
local database of context information. Table 11 presents
information about SNMPv2 parties that is recorded in the
SNMPv2 management station's local database of party
information. Table 12 presents information about the database
of access policy information specified by the local
administration.
Identity groucho chico harpo
(manager) (proxy agent) (proxy dst)
Domain snmpUDPDomain snmpUDPDomain acmeMgmtPrtcl
Address 1.2.3.4, 2002 1.2.3.5, 161 0x98765432
Auth Prot v2md5AuthProtocol v2md5AuthProtocol noAuth
Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" ""
Auth Pub Key "" "" ""
Auth Clock 0 0 0
Auth Lifetime 300 300 0
Priv Prot noPriv noPriv noPriv
Priv Priv Key "" "" ""
Priv Pub Key "" "" ""
Table 9: Party Information for Proxy Agent
RFC1445 Administrative Model for SNMPv2 April 1993
Context Proxy Destination Proxy Source Proxy Context
ducksoup harpo n/a n/a
Table 10: Proxy Relationships for Proxy Agent
Identity groucho chico
(manager) (proxy agent)
Domain snmpUDPDomain snmpUDPDomain
Address 1.2.3.4, 2002 1.2.3.5, 161
Auth Prot v2md5AuthProtocol v2md5AuthProtocol
Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789"
Auth Pub Key "" ""
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 11: Party Information for Management Station
Target Subject Context Privileges
chico groucho ducksoup 35 (Get, GetNext & GetBulk)
groucho chico ducksoup 132 (Response & SNMPv2-Trap)
Table 12: Access Information for Foreign Proxy
As represented in Table 9, the proxy agent party operates at
UDP port 161 at IP address 1.2.3.5 using the party identity
chico; and, the example manager operates at UDP port 2002 at
IP address 1.2.3.4 using the identity groucho. Both groucho
and chico authenticate all messages that they generate by
using the protocol v2md5AuthProtocol and their distinct,
private authentication keys. Although these private
authentication key values ("0123456789ABCDEF" and
"GHIJKL0123456789") are presented here for expository
RFC1445 Administrative Model for SNMPv2 April 1993
purposes, knowledge of private keys is not normally afforded
to human beings and is confined to those portions of the
protocol implementation that require it.
The party harpo does not send or receive SNMPv2 protocol
messages; rather, all communication with that party proceeds
via a hypothetical proprietary protocol identified by the
value acmeMgmtPrtcl. Because the party harpo does not
participate in the SNMPv2, many of the attributes recorded for
that party in the local database of party information are
ignored.
Table 10 shows the proxy relationships known to the proxy
agent. In particular, the SNMPv2 context ducksoup refers to a
relationship that is satisfied by the party harpo. (The
transport domain of the proxy destination party determines the
interpretation of the proxy source and proxy context
identities - in this case, use of the acmeMgmtPrtcl indicates
that the proxy source and context identities are ignored.)
In order to interrogate the proprietary device associated with
the party harpo, the management station groucho constructs a
SNMPv2 GetNext request contained within a SnmpMgmtCom value
which references the SNMPv2 context ducksoup, and transmits it
to the party chico operating (see Table 11) at UDP port 161,
and IP address 1.2.3.5. This request is authenticated using
the private authentication key "0123456789ABCDEF".
When that request is received by the party chico, the
originator of the message is verified as being the party
groucho by using local knowledge (see Table 9) of the private
authentication key "0123456789ABCDEF". Because party groucho
is authorized to issue GetNext (as well as Get and GetBulk)
requests with respect to party chico and the SNMPv2 context
ducksoup by the relevant access control policy (Table 12), the
request is accepted. Because the local database of context
information indicates that the SNMPv2 context ducksoup refers
to a proxy relationship, the request is satisfied by its
translation into appropriate operations of the acmeMgmtPrtcl
directed at party harpo. These new operations are transmitted
to the party harpo at the address 0x98765432 in the
acmeMgmtPrtcl domain.
When and if the proprietary protocol exchange between the
proxy agent and the proprietary device concludes, a SNMPv2
RFC1445 Administrative Model for SNMPv2 April 1993
Response management operation is constructed by the SNMPv2
party chico to relay the results to party groucho again
referring to the SNMPv2 context ducksoup. This response
communication is authenticated as to origin and integrity
using the authentication protocol v2md5AuthProtocol and
private authentication key "GHIJKL0123456789" specified for
transmissions from party chico. It is then transmitted to the
SNMPv2 party groucho operating at the management station at IP
address 1.2.3.4 and UDP port 2002 (the source address for the
corresponding request).
When this response is received by the party groucho, the
originator of the message is verified as being the party chico
by using local knowledge (see Table 11) of the private
authentication key "GHIJKL0123456789". Because party chico is
authorized to issue Response communications with respect to
party groucho and SNMPv2 context ducksoup by the relevant
access control policy (Table 12), the response is accepted,
and the interrogation of the proprietary device is complete.
It is especially useful to observe that the local database of
party information recorded at the proxy agent (Table 9) need
be neither static nor configured exclusively by the management
station. For instance, suppose that, in this example, the
acmeMgmtPrtcl was a proprietary, MAC-layer mechanism for
managing stations attached to a local area network. In such
an environment, the SNMPv2 party chico would reside at a
SNMPv2 proxy agent attached to such a LAN and could, by
participating in the LAN protocols, detect the attachment and
disconnection of various stations on the LAN. In this
scenario, the SNMPv2 proxy agent could easily adjust its local
database of party information to support indirect management
of the LAN stations by the SNMPv2 management station. For
each new LAN station detected, the SNMPv2 proxy agent would
add to its local database of party information an entry
analogous to that for party harpo (representing the new LAN
station itself), and also add to its local database of context
information an entry analogous to that for SNMPv2 context
ducksoup (representing a proxy relationship for that new
station in the SNMPv2 domain).
By using the SNMPv2 to interrogate the local database of party
information held by the SNMPv2 proxy agent, a SNMPv2
management station can discover and interact with new stations
as they are attached to the LAN.
RFC1445 Administrative Model for SNMPv2 April 1993
4.4.2. Native Proxy Configuration
This section presents an example configuration that supports
SNMPv2 native proxy operations - indirect interaction between
a SNMPv2 agent and a management station that is mediated by a
second SNMPv2 (proxy) agent.
This example configuration is similar to that presented in the
discussion of SNMPv2 foreign proxy above. In this example,
however, the party associated with the identity harpo receives
messages via the SNMPv2, and, accordingly interacts with the
SNMPv2 proxy agent chico using authenticated SNMPv2
communications.
Table 13 presents information about SNMPv2 parties that is
recorded in the SNMPv2 proxy agent's local database of party
information. Table 14 presents information about proxy
relationships that is recorded in the SNMPv2 proxy agent's
local database of context information. Table 11 presents
information about SNMPv2 parties that is recorded in the
SNMPv2 management station's local database of party
information. Table 15 presents information about the database
of access policy information specified by the local
administration.
RFC1445 Administrative Model for SNMPv2 April 1993
Identity groucho chico
(manager) (proxy agent)
Domain snmpUDPDomain snmpUDPDomain
Address 1.2.3.4, 2002 1.2.3.5, 161
Auth Prot v2md5AuthProtocol v2md5AuthProtocol
Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789"
Auth Pub Key "" ""
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Identity harpo zeppo
(proxy dst) (proxy src)
Domain snmpUDPDomain snmpUDPDomain
Address 1.2.3.6, 161 1.2.3.5, 161
Auth Prot v2md5AuthProtocol v2md5AuthProtocol
Auth Priv Key "MNOPQR0123456789" "STUVWX0123456789"
Auth Pub Key "" ""
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 13: Party Information for Proxy Agent
Context Proxy Destination Proxy Source Proxy Context
ducksoup harpo zeppo bigstore
bigstore groucho chico ducksoup
Table 14: Proxy Relationships for Proxy Agent
RFC1445 Administrative Model for SNMPv2 April 1993
Target Subject Context Privileges
chico groucho ducksoup 35 (Get, GetNext & GetBulk)
groucho chico ducksoup 132 (Response & SNMPv2-Trap)
harpo zeppo bigstore 35 (Get, GetNext & GetBulk)
zeppo harpo bigstore 132 (Response & SNMPv2-Trap)
Table 15: Access Information for Native Proxy
As represented in Table 13, the proxy agent party operates at
UDP port 161 at IP address 1.2.3.5 using the party identity
chico; the example manager operates at UDP port 2002 at IP
address 1.2.3.4 using the identity groucho; the proxy source
party operates at UDP port 161 at IP address 1.2.3.5 using the
party identity zeppo; and, the proxy destination party
operates at UDP port 161 at IP address 1.2.3.6 using the party
identity harpo. Messages generated by all four SNMPv2 parties
are authenticated as to origin and integrity by using the
authentication protocol v2md5AuthProtocol and distinct,
private authentication keys. Although these private
authentication key values ("0123456789ABCDEF",
"GHIJKL0123456789", "MNOPQR0123456789", and
"STUVWX0123456789") are presented here for expository
purposes, knowledge of private keys is not normally afforded
to human beings and is confined to those portions of the
protocol implementation that require it.
Table 14 shows the proxy relationships known to the proxy
agent. In particular, the SNMPv2 context ducksoup refers to a
relationship that is satisfied when the SNMPv2 party zeppo
communicates with the SNMPv2 party harpo and references the
SNMPv2 context bigstore.
In order to interrogate the proxied device associated with the
party harpo, the management station groucho constructs a
SNMPv2 GetNext request contained with a SnmpMgmtCom value
which references the SNMPv2 context ducksoup, and transmits it
to the party chico operating (see Table 11) at UDP port 161
and IP address 1.2.3.5. This request is authenticated using
the private authentication key "0123456789ABCDEF".
When that request is received by the party chico, the
originator of the message is verified as being the party
groucho by using local knowledge (see Table 13) of the private
RFC1445 Administrative Model for SNMPv2 April 1993
authentication key "0123456789ABCDEF". Because party groucho
is authorized to issue GetNext (as well as Get and GetBulk)
requests with respect to party chico and the SNMPv2 context
ducksoup by the relevant access control policy (Table 15), the
request is accepted. Because the local database of context
information indicates that the SNMPv2 context ducksoup refers
to a proxy relationship, the request is satisfied by its
translation into a corresponding SNMPv2 GetNext request
directed from party zeppo to party harpo referencing SNMPv2
context bigstore. This new communication is authenticated
using the private authentication key "STUVWX0123456789" and
transmitted to party harpo at the IP address 1.2.3.6.
When this new request is received by the party harpo, the
originator of the message is verified as being the party zeppo
by using local knowledge of the private authentication key
"STUVWX0123456789". Because party zeppo is authorized to
issue GetNext (as well as Get and GetBulk) requests with
respect to party harpo and the SNMPv2 context bigstore by the
relevant access control policy (Table 15), the request is
accepted. A SNMPv2 Response message representing the results
of the query is then generated by party harpo to party zeppo
referencing SNMPv2 context bigstore. This response
communication is authenticated as to origin and integrity
using the private authentication key "MNOPQR0123456789" and
transmitted to party zeppo at IP address 1.2.3.5 (the source
address for the corresponding request).
When this response is received by party zeppo, the originator
of the message is verified as being the party harpo by using
local knowledge (see Table 13) of the private authentication
key "MNOPQR0123456789". Because party harpo is authorized to
issue Response communications with respect to party zeppo and
SNMPv2 context bigstore by the relevant access control policy
(Table 15), the response is accepted, and is used to construct
a response to the original GetNext request, indicating a
SNMPv2 context of ducksoup. This response, from party chico
to party groucho, is authenticated as to origin and integrity
using the private authentication key "GHIJKL0123456789" and is
transmitted to the party groucho at IP address 1.2.3.4 (the
source address for the original request).
When this response is received by the party groucho, the
originator of the message is verified as being the party chico
by using local knowledge (see Table 13) of the private
RFC1445 Administrative Model for SNMPv2 April 1993
authentication key "GHIJKL0123456789". Because party chico is
authorized to issue Response communications with respect to
party groucho and SNMPv2 context ducksoup by the relevant
access control policy (Table 15), the response is accepted,
and the interrogation is complete.
4.5. Public Key Configuration
This section presents an example configuration predicated upon
a hypothetical security protocol. This hypothetical protocol
would be based on asymmetric (public key) cryptography as a
means for providing data origin authentication (but not
protection against disclosure). This example illustrates the
consistency of the administrative model with public key
technology, and the extension of the example to support
protection against disclosure should be apparent.
Identity ollie stan
(agent) (manager)
Domain snmpUDPDomain snmpUDPDomain
Address 1.2.3.4, 161 1.2.3.5, 2004
Auth Prot pkAuthProtocol pkAuthProtocol
Auth Priv Key "0123456789ABCDEF" ""
Auth Pub Key "0123456789abcdef" "ghijkl0123456789"
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 16: Party Information for Public Key Agent
The example configuration comprises a single SNMPv2 agent that
interacts with a single SNMPv2 management station. Tables 16
and 17 present information about SNMPv2 parties that is by the
agent and manager, respectively, while Table 5 presents
information about the local access policy that is known to
both manager and agent.
RFC1445 Administrative Model for SNMPv2 April 1993
Identity ollie stan
(agent) (manager)
Domain snmpUDPDomain snmpUDPDomain
Address 1.2.3.4, 161 1.2.3.5, 2004
Auth Prot pkAuthProtocol pkAuthProtocol
Auth Priv Key "" "GHIJKL0123456789"
Auth Pub Key "0123456789abcdef" "ghijkl0123456789"
Auth Clock 0 0
Auth Lifetime 300 300
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 17: Party Information for Public Key Management Station
As represented in Table 16, the example agent party operates
at UDP port 161 at IP address 1.2.3.4 using the party identity
ollie; the example manager operates at UDP port 2004 at IP
address 1.2.3.5 using the identity stan. Both ollie and stan
authenticate all messages that they generate as to origin and
integrity by using the hypothetical SNMPv2 authentication
protocol pkAuthProtocol and their distinct, private
authentication keys. Although these private authentication
key values ("0123456789ABCDEF" and "GHIJKL0123456789") are
presented here for expository purposes, knowledge of private
keys is not normally afforded to human beings and is confined
to those portions of the protocol implementation that require
it.
In most respects, the interaction between manager and agent in
this configuration is almost identical to that in the example
of the minimal, secure SNMPv2 agent described above. The most
significant difference is that neither SNMPv2 party in the
public key configuration has knowledge of the private key by
which the other party authenticates its transmissions.
Instead, for each received authenticated SNMPv2 communication,
the identity of the originator is verified by applying an
asymmetric cryptographic algorithm to the received message
together with the public authentication key for the
originating party. Thus, in this configuration, the agent
knows the manager's public key ("ghijkl0123456789") but not
its private key ("GHIJKL0123456789"); similarly, the manager
knows the agent's public key ("0123456789abcdef") but not its
RFC1445 Administrative Model for SNMPv2 April 1993
private key ("0123456789ABCDEF").
RFC1445 Administrative Model for SNMPv2 April 1993
5. Security Considerations
In order to participate in the administrative model set forth
in this memo, SNMPv2 implementations must support local, non-
volatile storage of the local database of party information.
Accordingly, every attempt has been made to minimize the
amount of non-volatile storage required.
RFC1445 Administrative Model for SNMPv2 April 1993
6. Acknowledgements
This document is based, almost entirely, on RFC1351.
RFC1445 Administrative Model for SNMPv2 April 1993
7. References
[1] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple
Network Management Protocol", STD 15, RFC1157, SNMP
Research, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1448, SNMP Research,
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, April 1993.
[3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC1442,
SNMP Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
[4] McCloghrie, K., and Galvin, J., "Party MIB for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC
1447, Hughes LAN Systems, Trusted Information Systems,
April 1993.
[5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Transport Mappings for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1449, SNMP Research,
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, April 1993.
[6] Galvin, J., and McCloghrie, K., "Security Protocols for
version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC1446, Trusted Information Systems, Hughes
LAN Systems, April 1993.
[7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Management Information Base for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1450, SNMP
Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
RFC1445 Administrative Model for SNMPv2 April 1993
8. Authors' Addresses
James M. Galvin
Trusted Information Systems, Inc.
3060 Washington Road, Route 97
Glenwood, MD 21738
Phone: +1 301 854-6889
EMail: galvin@tis.com
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
US
Phone: +1 415 966 7934
Email: kzm@hls.com