Distributed Management Framework
             <draft-ietf-disman-framework-01.txt>

                      December 15, 1996
             <draft-ietf-disman-framework-02.txt>

                       August 23, 1998

                           Authors:

                         Andy Bierman
                        Cisco Systems
                      abierman@cisco.com

                         Maria Greene
                         Ascom Nexion
                       greene@nexen.com

                         Bob Stewart
                        Cisco Systems
                      bstewart@cisco.com

                       Steve Waldbusser
             International Network Services (INS)
                      waldbusser@ins.com

1.  Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months.  Internet-Drafts
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is not
appropriate inappropriate to use Internet-Drafts Internet-
Drafts as reference material or to cite them other than as a ``working draft'' or ``work
"work in
progress.'' progress."

To learn view the current status entire list of any Internet-Draft, current Internet-Drafts, please
check the 1id-abstracts.txt "1id-abstracts.txt" listing contained in the Internet-
Drafts

Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net,
venera.isi.edu, or munnari.oz.au. ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).

2.  Abstract

This memo defines a distributed management architecture for
use with the SNMP network management architecture.

This memo does not specify a standard for the Internet
community.

3.  Overview

Distributed Management is the delegation of control from one
management station to another. While the SNMP Network
Management Framework does not specifically address distributed
management, this function is desired and has been implemented
and deployed in the internet using proprietary architectures.
It is desired that there be a standard upon which to promote
interoperability, as well as a common framework upon which
various systems can be built.

The goals of distributed management are:

  o Scalability through Distribution
    In order to build network management systems that have the
    power to manage very large networks, it is important to
    reduce bottlenecks in the management system. Therefore, a
    distributed systems approach is often helpful when
    building large management systems. A distributed approach
    is often very effective at reducing load on the central
    management station, and may be effective at reducing the
    load that the central management station places on
    backbone networks. However, a distributed approach usually
    has no benefit in reducing load on remote networks and has
    no benefit in reducing load on management agents. Further,
    in a distributed data collection architecture, if all data
    collected is eventually forwarded to the central
    management station (without aggregation or compression),
    then no benefit in backbone load or central management
    station load should be expected (except perhaps to time-
    shift this load to a time of excess capacity, at the
    expense of a lack of timeliness of data.

  o Disconnected or Low-Bandwidth Operation
    There are sometimes conditions when a management station
    will not be in constant contact with all portions of the
    managed network. This is sometimes by design in an attempt
    to lower communications costs (especially when
    communicating over a WAN or dialup link), or by accident
    as network failures affect the communications between the
    management station and portions of the managed network.

    For this reason, a distributed management station will be
    configured to perform network management functions, even
    when communication with the management station may not be
    possible or efficient.  The distributed management station
    may then attempt to notify the management station when an
    exceptional condition occurs.  Thus, even in circumstances
    where communication with the distributed management
    station is not continuous, network management operations
    may run continuously, communicating with the management
    station conveniently and efficiently, on an as-needed
    basis.

  o Mirroring organization boundaries and processes
    Business organizations are typically set up in a
    hierarchical fashion. Multiple people in the hierarchy
    have different roles, responsibilites, and authority. The
    network management system often has to be configured to
    match this organization. Distributed network managers can
    be set up in a hierarchy that matches the roles of various
    people in the organization.

  o Promotes a modular system architecture
    A modular system architecture allows flexibility and re-
    usability of network management components. This also
    enables a multi-vendor approach to building management
    systems. A distributed network management system with
    well-defined interfaces creates this modular scheme.

    This document defines an architectural framework for
    standards-based distributed management

4.  The Network  Relationship to the SNMP Management Framework

A distributed network management station is a management
station that receives requests from another manager and
executes those requests by performing management operations on
agents or other managers. Note that these requests may take a
long time to execute, and may be registered indefinitely.

With This
framework uses the addition services of the distributed network management
station, the SNMP Network Management Framework.

4.1.  The SNMP Management Framework

The SNMP Management Framework presently consists of five major
components:

    o   An overall architecture, described in RFC 2271 [1].

    o   Mechanisms for describing and naming objects and
        events for the
following entities:

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 purpose of management. The first
        version of this Structure of Management Information
        (SMI) is called SMIv1 and described in RFC 1155 [2],
        RFC 1212 [3] and RFC 1215 [4]. The second version,
        called SMIv2, is described in RFC 1902 [5], RFC 1903
        [6] and RFC 1904 [7].

    o   Message protocols for transferring management
stations.  Operations
        information. The first version of the SNMP message
        protocol are carried out under an
administrative framework which defines authentication,
authorization, access control, and privacy policies.

Management stations execute management applications which
monitor is called SNMPv1 and control managed elements or other (distributed)
management stations. described in RFC 1157
        [8]. A distributed management station second version of the SNMP message protocol,
        which is a
type not an Internet standards track protocol, is
        called SNMPv2c and described in RFC 1901 [9] and RFC
        1906 [10]. The third version of management station that the message protocol
        is controlled by another
management station.  Managed elements are devices such as
hosts, routers, terminal servers, etc., which are monitored called SNMPv3 and controlled via access to their described in RFC 1906 [10], RFC
        2272 [11] and RFC 2274 [12].

    o   Protocol operations for accessing management
        information.

Management information The first set of protocol operations and
        associated PDU formats is viewed as a collection described in RFC 1157 [8]. A
        second set of managed
objects, residing protocol operations and associated PDU
        formats is described in RFC 1905 [13].

    o   A set of fundamental applications described in RFC
        2273 [14] and the view-based access control mechanism
        described in RFC 2275 [15].  Managed objects are
        accessed via a virtual information store, termed the
        Management Information Base (MIB).  Collections of related
objects are defined or MIB.  Objects in the
        MIB modules.  These modules are written defined using a subset of OSI's Abstract Syntax Notation One (ASN.1)
[1], termed the Structure of Management Information (SMI) [2].

The management protocol, SNMPv2 [3], provides for mechanisms defined in the exchange
of messages which convey management information between
        SMI.  This memo specifies a MIB module that is
        compliant to the
agents and SMIv2. A MIB conforming to the management stations.  It is SMIv1
        can be produced through the purpose appropriate translations.
        The resulting translated MIB must be semantically
        equivalent, except where objects or events are omitted
        because no translation is possible (use of Counter64).
        Some machine readable information in SMIv2 will be
        converted into textual descriptions in SMIv1 during
        the translation process. However, this
document loss of machine
        readable information is not considered to define managed objects which describe change the behavior
        semantics of a SNMPv2 entity. the MIB.

5.  Distributed Management Framework

The distributed management framework consists of applications
and services.

A distributed management application performs some management
function, often by monitoring and controlling managed
elements. These applications perform functions such as
threshold polling, historical data polling, or discovery.  The
specifications and communications protocols of some of these
applications will be defined by standards, while others will
be enterprise specific.

Distributed management services are a collection of services
that make up the run-time environment for the distributed
management application. These services are crucial to ensuring
the usability, scalability, and efficiency of the distributed
management applications that depend on them. Some of these
services are mandatory, while others are optional. Further,
even the mandatory services allow varying depths of support,
as described further, below.

Each of these services is made available through a MIB
interface.

The purpose of these services is to provide true enterprise
management that allows distributed management functions to be
used on an enterprise-wide basis without undue amounts of
administrative difficulty. These services also make a set of
applications more efficient because the service can perform
functions or store information once for all applications on
the local system. Further, less work is required to be put
into writing the application because some of the core
functions are performed elsewhere.

5.1.  Known Systems

The Known Systems service provides a list of all systems which
the distributed management system knows about and is prepared
to perform management operations upon. This list may be
populated by a continuously-running auto-discovery process, it
may be populated with SNMP SET requests, or it may be a static
list dictated by the system.

This service also stores type and attribute information for
each of the known systems.

The purpose of this service is to allow a management
application to be executed on a list of systems so that true
enterprise management is possible rather than more ad-hoc
management functions. Further, the targets of management
applications can be configured separately from the
applications to reduce administrative burden as the list of
known systems changes.

An example of a known systems list is a list of all systems at
a site discovered by the autodiscovery module, along with
various addressing, type, and attribute information for each.

5.2.  Management Domains

The Management Domains service provides a list of known
systems which is a subset of the entire list of known systems.
The subset is defined by a rule, or filter, which selects only
the known systems that match or those that don't match certain
criteria.

These domains are multiple, potentially overlapping, sets of
devices based on (human) organizational boundaries that define
the extents over which management operations should be
performed.

The purpose of this service is to allow a management
application to be executed on a list of known systems within a
particular domain.  Further, as the domains change over time,
the application will automatically be kept up to date and will
only monitor the correct systems.

An example of a management domain is the subset of all known
systems that is on the engineering LAN.

5.3.  Management Operations Targets

The Management Operations Targets service provides a list of
known systems in a set of domains that match certain criteria
that indicate that it makes sense to perform a particular
management function on them.

The purpose of this service is to direct management operations
to be performance only on those systems where that operation
would make sense. Because this is described as a filter, there
are no static configuration requirements that would be
unacceptable in a dynamically changing network environment.

An example of a management operation target list is the subset
of all known routers on the engineering LAN.

5.4.  Credential Delegation

The Credential Delegation Service allows credentials of a
network management user to be delegated to a distributed
management application so that it can perform secure
operations on behalf of that user.

Fundamental to this distributed management architecture is the
notion that distributed management operations must not run
with the credentials of the distributed manager. To do so
would require that the authorization of these credentials (or
subsets of this authorization) would need to be apportioned to
users of that distributed manager in a pre-defined and secure
way. This would require the creation of a access control
architecture mirroring the SNMP View-Based Access Control
architecture that would control what subsets of authority are
available to what users. The existing View-Based Access
Control mechanism was not designed for this task and is not
appropriate. Further, it would require that the distributed
manager be configured in a way that was consistent with the
access control policy embodied in the managed systems. This
would be extremely problematic because:

  1. This would require a massive amount of configuration to
  be replicated on the distribute distributed manager

  2. If any part of this configuration on the distribute distributed
  manager is inconsistent with that on the managed systems, a
  security hole could be exposed.

Because it is assumed that the distributed manager adds no
credentials to management operations, when a manager wishes to
configure a distributed manager to perform secure transactions
on its behalf, it must download to the distributed manager the
appropriate credentials to be placed in secure SNMP messages,
identifying them as the manager.  A credential contains at

least the securityModel, securityName, securityLevel,
authentication and privacy keys, and an indication of which
management targets the credential should be used for.

5.4.1.  Definitions

-----------           ---------------              --------------
|         |           |             |              |            |
| Manager |---------->| Distributed |------------->| Management |
|         |  Disman   |   Manager   |    Target    |   Target   |
|         |   User    |             |     User     |            |
|         |           |             |   Identity   |            |
|         |           |             |              |            |
-----------           ---------------              --------------

  1. Disman User - The user whose credentials are used to
  configure the distribute distributed manager for an operation and to
  download credentials for that operation. There is no
  relationship implied between the disman user and the
  user(s) who's credentials are installed (in other words,
  "joe" can install credentials for "ops-center-east" as
  well as "joe").

  2. Target User Identity - The user identity used in SNMP
  messages between the distributed manager and management
  targets.

  3. Credential - The set of secrets that are transferred
  to the distributed manager giving it the authority to act
  as an identity.

  4. Owner - The disman user who sets up a distributed
  management function, including the credentials for the
  function.

  5. Invoker - The user who invokes a previously setup
  distributed management function. The owner may choose to
  allow others to invoke a function, potentially allowing
  that function to operate with the owner's credentials (of
  course the owner would want to tightly constrain what the
  function was configured to perform).

  6. Invokation Identity - The identity of the credentials
  a function is operating with. These may be of the owner,
  of the invoker, or possibly the union of both
  credentials.

Because multiple Disman Users will have access to a
Distributed Manager, the Credential Delegation Service will be
responsible for ensuring that credentials are only used by
authorized users. The Credential Delegation Service will
include:

  1. Credential Store - a MIB in which to transfer and
  store credentials

  2. MIB prototype - a prototype MIB fragment that will be
  added to disman functions that wish to use the Credential
  Store

  3. Access Control Policy - a policy for configuration of
  the VACM MIB for use with the Credential Delegation
  Service. This will limit access to the credential store.

5.5.  Delegation Control

The Delegation Control Service provides functions that limit
the resource usage of a distributed management application
that has had control delegated to it.

Network management applications are often responsible for
adding stress on the network and causing problems. Examples
are excessive polling load on slow-speed networks or on router
CPUs. This problem will become even more dangerous when
network management functions are delegated to distributed
management stations.

Policies need to be configured that limit average and burst
polling, notification, and broadcast rates.  These rates may
be defined for the sending system as a whole, per end node, or
per management application on the sending system.

It is also important to have a "Deadman's switch" so that
delegated applications will not continue indefinitely if their
"sponsor" has forgotten about them.

5.6.  Scheduling

The Scheduling Service allows the execution of distributed
management applications to be controlled so that they run at a
particular time, periodically, or based on the occurance of
another event.

5.7.  Reliable Notification

The Reliable Notification Service provides services that
ensure that notifications are received correctly.

For example, all the information that describes an event may
not fit within a single PDU, so an eventID varbind is defined
that associates multiple PDU's as describing the same event.
It is also necessary to know if the entire notification has
been received or if more PDU's are still outstanding.

Further, a receiving management station must be given more
information so that it can distinguish duplicated inform PDU's
because events are not idempotent. No rule makes it mandatory
for the requestID to be unique for all PDUs sent from a
system.

In addition, a logging mechanism provides for retrieval of
notifications after a communications failure.

5.8.  Notification Destinations

The Notification Destination Service provides services for
configuring destinations for notifications.

When management functions are delegated and MLMs are given the
autonomy to generate notifications, they need to be configured
as to where the notifications should be sent.  Additionally,
retry counts and numbers need to be configured. Average and
burst notification rates need to be defined.

-- Remove hacks

6.  Acknowledgments

This document was produced by the IETF Distributed Network
Management Working Group.

7.  References

[1]  Harrington, D., Presuhn, R., and B. Wijnen, "An
     Architecture for Unsigned32 Describing SNMP Management Frameworks",
     RFC 2271, Cabletron Systems, Inc., BMC Software, Inc.,
     IBM T. J. Watson Research, January 1998

[2]  Rose, M., and BITS datatypes. I need these because
-- my version K. McCloghrie, "Structure and
     Identification of SMIC is RFC1442 compliant, not RFC1902.

DISMAN-SERVICES-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, zeroDotZero,
    NOTIFICATION-TYPE, Counter32, Gauge32, Counter64 -- , Unsigned32, BITS
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, AutonomousType, DisplayString, DateAndTime,
    RowStatus, TDomain, TimeStamp, TestAndIncr
        FROM SNMPv2-TC
    snmpUDPDomain
        FROM SNMPv2-TM
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF
    OwnerString
        FROM RMON-MIB
    ;

dismanMIB MODULE-IDENTITY
     LAST-UPDATED "9612221200Z"
     ORGANIZATION "IETF Distributed Management Working Group"
     CONTACT-INFO
         "Working group mailing list: disman@nexen.com"
     DESCRIPTION
         "The Information for TCP/IP-based
     Internets", RFC 1155, Performance Systems International,
     Hughes LAN Systems, May 1990

[3]  Rose, M., and K. McCloghrie, "Concise MIB module containing SNMP variables Definitions",
     RFC 1212, Performance Systems International, Hughes LAN
     Systems, March 1991

[4]  M. Rose, "A Convention for controlling
         distributed managers."
 -- Get real experimental number from IANA.
 --    ::= { experimental XX }
     ::= { experimental 1 }

 -- Hack to deal Defining Traps for use with a RFC1442 version
     the SNMP", RFC 1215, Performance Systems International,
     March 1991

[5]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
     "Structure of MIB compiler instead Management Information for Version 2 of
 -- RFC1902.
 Unsigned32 ::= Counter32

--****************************************************************
-- Textual the
     Simple Network Management Protocol (SNMPv2)", RFC 1902,
     SNMP Research,Inc., Cisco Systems, Inc., Dover Beach
     Consulting, Inc., International Network Services, January
     1996.

[6]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
     "Textual Conventions
--****************************************************************

ElementName ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A string that uniquely identifies a management element which
        may be a system or a collection of systems."
    SYNTAX      DisplayString (SIZE (1..64))

IANAAddrFamily ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "An address family. Values are defined in Assigned Numbers,
        RFC1700. Note that not all these values make sense in all
        contexts where this type is used in this MIB, but they are
        included for completeness."
    REFERENCE
        "Assigned Numbers, RFC1700, ADDRESS FAMILY NUMBERS"
    SYNTAX      INTEGER {
                    other(0),
                    ipV4(1),
                    ipV6(2),
                    nsap(3),
                    hdlc(4),
                    bbn1822(5),
                    ieee802(6),
                    e163(7),
                    e164(8),
                    f69(9),
                    x121(10),
                    ipx(11),
                    appleTalk(12),
                    decnetIV(13),
                    banyanVines(14),
                    e164WithNsap(15)
                }

GenAddr ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "The value Version 2 of an address."
    SYNTAX      OCTET STRING (SIZE (0..60))

--****************************************************************
-- Managed Object definitions
--****************************************************************

mgmtObjects         OBJECT IDENTIFIER ::= { dismanMIB 1 }
mgmtGeneralObjects  OBJECT IDENTIFIER ::= { mgmtObjects 1 }

mgmtLock OBJECT-TYPE
    SYNTAX      TestAndIncr
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "An advisory lock for all writable objects in the entire
        Distributed Simple Network
     Management Services MIB."
    ::= { mgmtGeneralObjects 1 }

mgmtOwner OBJECT-TYPE
    SYNTAX      OwnerString
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "The manager entity that 'owns' this distributed manager's
        configuration."
    ::= { mgmtGeneralObjects Protocol (SNMPv2)", RFC 1903, SNMP Research,
     Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Network Services, January 1996.

[7]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
     "Conformance Statements for Version 2 }

mgmtAdminStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    enabled(1),
                    disabled(2),
                    disabledReset(3)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "The desired status of this distributed manager. The value
        'enabled(1)' indicates the distributed manager should be
        active. The value 'disabled(2)' indicates that the desired
        operational status is also 'disabled(2)'. A top-level manager
        may disable a distributed manager in order to change its
        configuration and have the changes take effect all at once or
        it may keep the distributed manager disabled as a redundant or
        back-up manager. The value 'disabledReset(3)' is used to
        disable a distributed manager and simultaneously remove all
        entries from its DISMAN MIB tables that support row
        creation. This allows the top-level manager to put the
        distributed manager into a known state before downloading a
        new configuration."
    ::= { mgmtGeneralObjects 3 }

mgmtOperStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    enabled(1),
                    disabled(2)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The actual status of this distributed manager."
    ::= { mgmtGeneralObjects 4 }

mgmtStatusLastChange OBJECT-TYPE
    SYNTAX      TimeStamp
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value of sysUpTime the last time mgmtOperStatus changed
        value."
    ::= { mgmtGeneralObjects 5 }

--
-- Managed Element Services
--
-- In order for a distributed management application to use these
-- managemed element services, it must specify both a domain rule index
-- and a target rule index. For example, the trivial application below

-- would simply return the values of the systems identified by a
-- particular domain rule index and target rule index.
--
-- testAppEntry ::= SEQUENCE {
--     testAppIndex        Integer32, # INDEX
--     testAppDomainIndex  Integer32,
--     testAppTargetIndex  Integer32,
--     testAppRowStatus    RowStatus
-- }
--
-- testAppResultsEntry ::= SEQUENCE {
--     # Indexed by { testAppIndex, testAppResultsIndex }
--     testAppResultsIndex         Integer32,
--     testAppResultsSystemName    ElementName
-- }
--
--
-- An example distributed management system might contain:
--
-- mgmtKnownSystemTable
-- Name        DateTime    Algorithm   ManualDomain    SystemID
-- router1     ...         ...         ...             acme5000
-- router2     ...         ...         ...             acme3000
-- router3     ...         ...         ...             acme5000
--
-- mgmtSysAccessTable
-- Name    Index   AddrType    Addr    SNMPPort    AuthString  RowStatus
-- router1 1       IP          1.1.1.1 161         ...         active
-- router1 2       IP          1.1.2.1 161         ...         active
-- router2 3       IP          1.1.1.5 161         ...         active
-- router3 4       IP          1.1.1.4 161         ...         active
-- router3 5       IP          1.1.4.9 161         ...         active
--
-- mgmtRuleTable
-- Index   Name        RowStatus
-- 1       "Finance"   active
-- 2       "Acme 5000" active
--
-- mgmtRuleFilterTable
-- Index   FilterIndex Type            Filter      RowStatus
-- 1       1           matchAddress    "^1.1.2"  active
-- 1       2           matchAddress    "^1.1.4"  active
-- # Rule 1 matches all hosts on subnet 2 and subnet 4
-- 2       3           matchSystemID   "acme5000"  active
--

-- testAppTable
-- Index   domainIndex targetIndex RowStatus
-- 1       1           2           active
--
-- testAppResultsTable
-- Index   ResultsIndex    systemName
-- 1       1               "router1"
-- 1       2               "router3"
--
-- If this was a script application, the script would execute on
-- router1 and router3.

mgmtElementObjects OBJECT IDENTIFIER ::= { mgmtObjects 3 }

--
-- The Known System Table
--

mgmtKnownSystemTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF MgmtKnownSystemEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of all known systems that are potential management
        targets."
    ::= { mgmtElementObjects 1 }

mgmtKnownSystemEntry OBJECT-TYPE
    SYNTAX      MgmtKnownSystemEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Information about a single management system. While most
        known systems will usually be populated by the agent, new
        systems can be created using the mgmtKnownSystemRowStatus
        variable."
    INDEX       { IMPLIED mgmtKnownSystemName }
    ::= { mgmtKnownSystemTable 1 }

MgmtKnownSystemEntry ::= SEQUENCE {
    mgmtKnownSystemName             ElementName,
    mgmtKnownSystemDateTimeCreated  DateAndTime,
    mgmtKnownSystemAlgorithm        AutonomousType,
    mgmtKnownSystemManualDomain     OCTET STRING,
    mgmtKnownSystemID               AutonomousType,
    mgmtKnownSystemRowStatus        RowStatus
}

mgmtKnownSystemName OBJECT-TYPE
    SYNTAX      ElementName
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The name of the element. If this record is created automatically
        (e.g., as part of a discovery process), this name can be
        algorithmically assigned using any algorithm that guarantees
        uniqueness. It is recommended that this value be human readable,
        and for that reason an ascii representation of the address is
        often suitable in cases where more detail is not known."
    ::= { mgmtKnownSystemEntry 1 }

mgmtKnownSystemDateTimeCreated OBJECT-TYPE
    SYNTAX      DateAndTime
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The date and time when this object was added to the distributed
        managers database."
    ::= { mgmtKnownSystemEntry 2 }

mgmtKnownSystemAlgorithm OBJECT-TYPE
    SYNTAX      AutonomousType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The method used to create this entry. The value { 0 0 } (a
        NULL object identifier) indicates that the entry was added
        'manually' via the table's RowStatus column. Other values may
        indicate various discovery algorithms."
    DEFVAL      { zeroDotZero }
    ::= { mgmtKnownSystemEntry 3 }

mgmtKnownSystemManualDomain OBJECT-TYPE
    SYNTAX  OCTET STRING
    MAX-ACCESS  read-create
    STATUS  current
    DESCRIPTION
        "A bit mask of domains the system is a member of. Every 1 bit
        in this string indicates that this system is a part of the
        domain who's rule index is equal to the bit position of the
        bit. The first bit in the string is equal to the rule index
        of 1. If this object indicates that a system is part of a
        domain, it is understood to be part of that domain no matter
        what the rule set is for the domain (i.e. domain membership is
        an OR function of this object and the domain rules).

        This object only has an effect on rules that are used as
        domains. In particular this means that if a bit is set for a
        rule and that rule is used as a target, the bit will have no
        effect."
    ::= { mgmtKnownSystemEntry 4 }

mgmtKnownSystemID OBJECT-TYPE
    SYNTAX      AutonomousType
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The type of the system. This will typically be
        the same value as the sysObjectID for the system.
        The value zeroDotZero indicates an unknown type."
    DEFVAL      { zeroDotZero }
    ::= { mgmtKnownSystemEntry 5 }

mgmtKnownSystemRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The control that allows creation/deletion of system entries."
    ::= { mgmtKnownSystemEntry 6 }

--
-- The System Management Access Table
--

mgmtSysAccessTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF MgmtSysAccessEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of access information for the management entities
        (either SNMP managers or SNMP agents) running on systems."
    ::= { mgmtElementObjects 2 }

mgmtSysAccessEntry OBJECT-TYPE
    SYNTAX      MgmtSysAccessEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Information about a single management entity."
    INDEX       { mgmtKnownSystemName, mgmtSysAccessIndex }
    ::= { mgmtSysAccessTable 1 }

MgmtSysAccessEntry ::= SEQUENCE {
    mgmtSysAccessIndex          Integer32,
    mgmtSysAccessAddrType       IANAAddrFamily,
    mgmtSysAccessAddr           GenAddr,
    mgmtSysAccessSNMPPort       Integer32,
    mgmtSysAccessAuthString     OCTET STRING,
    mgmtSysAccessRowStatus      RowStatus
}

mgmtSysAccessIndex OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "An index number for the access information so that the agent
        can keep track of multiple managers and multiple agents
        running on the same system (presumably at different transport
        addresses.)"
    ::= { mgmtSysAccessEntry 1 }

mgmtSysAccessAddrType OBJECT-TYPE
    SYNTAX      IANAAddrFamily
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The type of the address identified by mgmtSysAccessAddr."
    DEFVAL      { ipV4 }
    ::= { mgmtSysAccessEntry 2 }

mgmtSysAccessAddr OBJECT-TYPE
    SYNTAX      GenAddr
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The management address for the manager or agent.  A
        zero-length string indicates an unknown address."
    DEFVAL      { ''H }
    ::= { mgmtSysAccessEntry 3 }

mgmtSysAccessSNMPPort OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The port for an SNMP agent on this system."
    DEFVAL      { 161 }
    ::= { mgmtSysAccessEntry 4 }

mgmtSysAccessAuthString OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Authentication information for accessing this system at this port."
    ::= { mgmtSysAccessEntry 5 }

mgmtSysAccessRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "A control that allows creation/deletion of system management
        entity entries."
    ::= { mgmtSysAccessEntry 6 }
--
-- Rules
--

mgmtRuleTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF MgmtRuleEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of rules.

        A rule is a set of filters by which a list of systems can be
        selected from a larger list, based on a match of one or more
        filters.

        Rules are used in 2 contexts, to select a domain, or to
        select managed operations targets. A domain defines those
        systems within a particular organizational boundary within
        which certain operations should be performed. A set of
        management operations targets is a subset of a domain that
        restricts an operation to only those systems upon which the
        operation `makes sense'. Domain rules are distinguishable from
        target rules only by the context in which they are
        used. However, in general, it is not useful to use a filter
        designed to select a target in the context of a domain, or
        vice versa.

        A system matches a rule if it was part of the appropriate
        input set (ALL, or member of a domain), and one or more
        ruleFilters evaluates to true for the system."
    ::= { mgmtElementObjects 3 }

mgmtRuleEntry OBJECT-TYPE
    SYNTAX      MgmtRuleEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Information about a single rule. New rules
        can be created using the mgmtRuleRowStatus variable."
    INDEX       { mgmtRuleIndex }
    ::= { mgmtRuleTable 1 }

MgmtRuleEntry ::= SEQUENCE {
    mgmtRuleIndex       Integer32,
    mgmtRuleName        DisplayString,
    mgmtRuleRowStatus   RowStatus
}

mgmtRuleIndex OBJECT-TYPE
    SYNTAX      Integer32 (1..2147483647)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A unique index for this rule."
    ::= { mgmtRuleEntry 1 }

mgmtRuleName OBJECT-TYPE
    SYNTAX      DisplayString
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "A human readable name for this rule. This name
        should describe the purpose/scope of the rule, for
        example `Headquarters' or `Acme Routers'."
    ::= { mgmtRuleEntry 2 }

mgmtRuleRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The control that allows creation/deletion of rule entries."
    ::= { mgmtRuleEntry 3 }

mgmtRuleFilterTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF MgmtRuleFilterEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of filters for a rule.

        If this filter is executed in the context of a domain, it
        selects a subset of all of the systems in the
        mgmtKnownSystemTable. If this filter is executed in the
        context of a target, it selects a subset of all systems
        matched by the associated domain rule.

        If a rule has multiple filters, the rule selects the union of
        all systems selected by the filters."
    ::= { mgmtElementObjects 4 }

mgmtRuleFilterEntry OBJECT-TYPE
    SYNTAX      MgmtRuleFilterEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Information about a single filter. New filters
        can be created using the mgmtRuleFilterRowStatus variable.
        A row can only be created if it contains a value of
        mgmtRuleIndex that already exists. Further, if a
        mgmtRuleIndex is deleted from the mgmtRuleTable, all
        associated entries shall be deleted from the
        mgmtRuleFilterTable."
    INDEX       { mgmtRuleIndex, mgmtRuleFilterIndex }
    ::= { mgmtRuleFilterTable 1 }

MgmtRuleFilterEntry ::= SEQUENCE {
    mgmtRuleFilterIndex     Integer32,
    mgmtRuleFilterType      INTEGER,
    mgmtRuleFilter          DisplayString,
    mgmtRuleFilterRowStatus RowStatus
}

mgmtRuleFilterIndex OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A unique index for this rule."
    ::= { mgmtRuleFilterEntry 1 }

mgmtRuleFilterType OBJECT-TYPE
    SYNTAX      INTEGER {
                    matchAddress(1),
                    matchDomainName(2),
                    matchSystemID(3)
                }
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "If this object has the value `matchAddress(1)', the ascii
        representation (TBD) of each address in the mgmtSysAccessTable
        will be evaluated against the regular expression in the
        associated mgmtRuleFilter object. If the match succeeds, the
        system associated with the mgmtSysAccessEntry matches this
        filter.

        If this object has the value `matchDomainName(2)', the domain
        name of each address in the mgmtSysAccessTable
        will be evaluated against the regular expression in the
        associated mgmtRuleFilter object. If the match succeeds, the
        system associated with the mgmtSysAccessEntry matches this
        filter.

        If this object has the value `matchSystemID(1)', the ascii
        representation (TBD) of each mgmtKnownSystemID
        will be evaluated against the regular expression in the
        associated mgmtRuleFilter object. If the match succeeds, the
        system associated with the mgmtKnownSystemID matches this
        filter."
    ::= { mgmtRuleFilterEntry 2 }

mgmtRuleFilter OBJECT-TYPE
    SYNTAX      DisplayString
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The value matched against systems for this filter."
    ::= { mgmtRuleFilterEntry 3 }

mgmtRuleFilterRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The control that allows creation/deletion of RuleFilter
        entries."
    ::= { mgmtRuleFilterEntry 4 }
END

6.  Acknowledgments

This document was produced by the IETF Distributed Network
Management Working Group.

7.  References

[1]  V. Cerf, IAB Recommendations for the Development of
     Internet Simple
     Network Management Standards.  Internet Working
     Group Request for Comments 1052. Protocol (SNMPv2)", RFC 1904, SNMP
     Research, Inc., Cisco Systems, Inc., Dover Beach
     Consulting, Inc., International Network Information
     Center, SRI International, Menlo Park, California,
     (April, 1988).

[2]  V. Cerf, Report of the Second Ad Hoc Services, January
     1996.

[8]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
     "Simple Network Management
     Review Group, Internet Working Group Request for Comments
     1109.  Network Information Center, SRI Protocol", RFC 1157, SNMP
     Research, Performance Systems International,
     Menlo Park, California, (August, 1989).

[3]  M.T. Rose and K. Performance
     Systems International, MIT Laboratory for Computer
     Science, May 1990.

[9]  Case, J., McCloghrie, Structure K., Rose, M., and Identification
     of Management Information for TCP/IP-based internets,
     Internet Working Group Request for Comments 1155. S. Waldbusser,
     "Introduction to Community-based SNMPv2", RFC 1901, SNMP
     Research, Inc., Cisco Systems, Inc., Dover Beach
     Consulting, Inc., International Network Information Center, SRI International, Menlo
     Park, California, (May, 1990).

[4]  K. McCloghrie and M.T. Services, January
     1996.

[10] Case, J., McCloghrie, K., Rose, Management Information Base M., and S. Waldbusser,
     "Transport Mappings for Version 2 of the Simple Network
     Management of TCP/IP-based internets: MIB-II,
     Internet Working Group Request for Comments 1213 Protocol (SNMPv2)", RFC 1906, SNMP Research,
     Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Network
     Information Center, SRI International, Menlo Park,
     California, (March, 1991).

[5]  J.D. Services, January 1996.

[11] Case, M.S. Fedor, M.L. Schoffstall, J., Harrington D., Presuhn R., and B. Wijnen,
     "Message Processing and J.R. Davin, Dispatching for the Simple
     Network Management Protocol, Internet Working
     Group Request Protocol (SNMP)", RFC 2272, SNMP
     Research, Inc., Cabletron Systems, Inc., BMC Software,
     Inc., IBM T. J. Watson Research, January 1998.

[12] Blumenthal, U., and B. Wijnen, "User-based Security Model
     (USM) for Comments 1157. version 3 of the Simple Network Information
     Center, SRI International, Menlo Park, California, (May,
     1990).

[6]  K. McCloghrie Management
     Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research,
     January 1998.

[13] Case, J., McCloghrie, K., Rose, M., and F. Kastenholz, Evolution S. Waldbusser,
     "Protocol Operations for Version 2 of the
     Interfaces Group of MIB-II, Internet Working Group
     Request for Comments 1573. Simple Network Information Center,
     SRI International, Menlo Park, California, (Jan, 1994).

[7]  Information processing systems -- Open Systems
     Interconnection -- Specification of Abstract Syntax
     Notation One (ASN.1), International Organization for
     Standardization.  International Standard 8824, (December,
     1987).

[8]  Information processing systems -- Open Systems
     Interconnection -- Specification of Basic Encoding Rules
     for Abstract Notation One (ASN.1), International
     Organization for Standardization.
     Management Protocol (SNMPv2)", RFC 1905, SNMP Research,
     Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
     International Standard
     8825, (December, 1987).

[9]  M.T. Rose, Network Services, January 1996.

[14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
     Applications", RFC 2273, SNMP Research, Inc., Secure
     Computing Corporation, Cisco Systems, January 1998

[15] Wijnen, B., Presuhn, R., and K. McCloghrie, Editors, Concise MIB
     Definitions, Internet Working Group Request for Comments
     1212.  Network Information Center, SRI International,
     Menlo Park, California, (March, 1991).

[10] M.T. Rose, Editor, A Convention for Defining Traps "View-based
     Access Control Model (VACM) for
     use with the SNMP, Internet Working Group Request for
     Comments 1215. Simple Network Information Center, SRI
     International, Menlo Park, California, (March, 1991).
     Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson
     Research, BMC Software, Inc., Cisco Systems, Inc.,
     January 1998

Table of Contents

1 Status of this Memo ...................................    1
2 Abstract ..............................................    2
3 Overview ..............................................    3
4 Relationship to the SNMP Management Framework .........    4
4.1 The Network SNMP Management Framework ...................... .......................    4
5 Distributed Management Framework ......................    5    6
5.1 Known Systems .......................................    6
5.2 Management Domains ..................................    7
5.3 Management Operations Targets .......................    7
5.4 Credential Delegation ...............................    7    8
5.4.1 Definitions .......................................    8    9
5.5 Delegation Control ..................................   10
5.6 Scheduling ..........................................   10   11
5.7 Reliable Notification ...............................   10   11
5.8 Notification Destinations ...........................   11
6 Acknowledgments .......................................   24   11
7 References ............................................   24   12