draft-ietf-disman-framework-01.txt   draft-ietf-disman-framework-02.txt 
Distributed Management Framework Distributed Management Framework
<draft-ietf-disman-framework-01.txt> <draft-ietf-disman-framework-02.txt>
December 15, 1996 August 23, 1998
Authors: Authors:
Andy Bierman Andy Bierman
Cisco Systems Cisco Systems
abierman@cisco.com abierman@cisco.com
Maria Greene Maria Greene
Ascom Nexion Ascom Nexion
greene@nexen.com greene@nexen.com
skipping to change at page 1, line 34 skipping to change at page 1, line 34
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or months and may be updated, replaced, or obsoleted by other
obsoleted by other documents at any time. It is not documents at any time. It is inappropriate to use Internet-
appropriate to use Internet-Drafts as reference material or to Drafts as reference material or to cite them other than as
cite them other than as a ``working draft'' or ``work in "work in progress."
progress.''
To learn the current status of any Internet-Draft, please To view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
check the 1id-abstracts.txt listing contained in the Internet- Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
venera.isi.edu, or munnari.oz.au. Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).
2. Abstract 2. Abstract
This memo defines a distributed management architecture for This memo defines a distributed management architecture for
use with the SNMP network management architecture. use with the SNMP network management architecture.
This memo does not specify a standard for the Internet This memo does not specify a standard for the Internet
community. community.
3. Overview 3. Overview
skipping to change at page 4, line 32 skipping to change at page 4, line 32
o Promotes a modular system architecture o Promotes a modular system architecture
A modular system architecture allows flexibility and re- A modular system architecture allows flexibility and re-
usability of network management components. This also usability of network management components. This also
enables a multi-vendor approach to building management enables a multi-vendor approach to building management
systems. A distributed network management system with systems. A distributed network management system with
well-defined interfaces creates this modular scheme. well-defined interfaces creates this modular scheme.
This document defines an architectural framework for This document defines an architectural framework for
standards-based distributed management standards-based distributed management
4. The Network Management Framework 4. Relationship to the SNMP Management Framework
A distributed network management station is a management A distributed network management station is a management
station that receives requests from another manager and station that receives requests from another manager and
executes those requests by performing management operations on executes those requests by performing management operations on
agents or other managers. Note that these requests may take a agents or other managers. Note that these requests may take a
long time to execute, and may be registered indefinitely. long time to execute, and may be registered indefinitely. This
framework uses the services of the SNMP Management Framework.
With the addition of the distributed network management 4.1. The SNMP Management Framework
station, the SNMP Network Management Framework consists of the
following entities:
A management system contains: several (potentially many) The SNMP Management Framework presently consists of five major
nodes, each with a processing entity, termed an agent, which components:
has access to management instrumentation; at least one
management station; and, a management protocol, used to convey
management information between the agents and management o An overall architecture, described in RFC 2271 [1].
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 o Mechanisms for describing and naming objects and
monitor and control managed elements or other (distributed) events for the purpose of management. The first
management stations. A distributed management station is a version of this Structure of Management Information
type of management station that is controlled by another (SMI) is called SMIv1 and described in RFC 1155 [2],
management station. Managed elements are devices such as RFC 1212 [3] and RFC 1215 [4]. The second version,
hosts, routers, terminal servers, etc., which are monitored called SMIv2, is described in RFC 1902 [5], RFC 1903
and controlled via access to their management information. [6] and RFC 1904 [7].
Management information is viewed as a collection of managed o Message protocols for transferring management
objects, residing in a virtual information store, termed the information. The first version of the SNMP message
Management Information Base (MIB). Collections of related protocol is called SNMPv1 and described in RFC 1157
objects are defined in MIB modules. These modules are written [8]. A second version of the SNMP message protocol,
using a subset of OSI's Abstract Syntax Notation One (ASN.1) which is not an Internet standards track protocol, is
[1], termed the Structure of Management Information (SMI) [2]. called SNMPv2c and described in RFC 1901 [9] and RFC
1906 [10]. The third version of the message protocol
is called SNMPv3 and described in RFC 1906 [10], RFC
2272 [11] and RFC 2274 [12].
The management protocol, SNMPv2 [3], provides for the exchange o Protocol operations for accessing management
of messages which convey management information between the information. The first set of protocol operations and
agents and the management stations. It is the purpose of this associated PDU formats is described in RFC 1157 [8]. A
document to define managed objects which describe the behavior second set of protocol operations and associated PDU
of a SNMPv2 entity. 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 or MIB. Objects in the
MIB are defined using the mechanisms defined in the
SMI. This memo specifies a MIB module that is
compliant to the SMIv2. A MIB conforming to the SMIv1
can be produced through the 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 loss of machine
readable information is not considered to change the
semantics of the MIB.
5. Distributed Management Framework 5. Distributed Management Framework
The distributed management framework consists of applications The distributed management framework consists of applications
and services. and services.
A distributed management application performs some management A distributed management application performs some management
function, often by monitoring and controlling managed function, often by monitoring and controlling managed
elements. These applications perform functions such as elements. These applications perform functions such as
threshold polling, historical data polling, or discovery. The threshold polling, historical data polling, or discovery. The
skipping to change at page 8, line 23 skipping to change at page 8, line 37
way. This would require the creation of a access control way. This would require the creation of a access control
architecture mirroring the SNMP View-Based Access Control architecture mirroring the SNMP View-Based Access Control
architecture that would control what subsets of authority are architecture that would control what subsets of authority are
available to what users. The existing View-Based Access available to what users. The existing View-Based Access
Control mechanism was not designed for this task and is not Control mechanism was not designed for this task and is not
appropriate. Further, it would require that the distributed appropriate. Further, it would require that the distributed
manager be configured in a way that was consistent with the manager be configured in a way that was consistent with the
access control policy embodied in the managed systems. This access control policy embodied in the managed systems. This
would be extremely problematic because: would be extremely problematic because:
1. This would require a massive amount of configuration 1. This would require a massive amount of configuration to
to be replicated on the distribute manager be replicated on the distributed manager
2. If any part of this configuration on the distribute 2. If any part of this configuration on the distributed
manager is inconsistent with that on the managed systems, manager is inconsistent with that on the managed systems, a
a security hole could be exposed. security hole could be exposed.
Because it is assumed that the distributed manager adds no Because it is assumed that the distributed manager adds no
credentials to management operations, when a manager wishes to credentials to management operations, when a manager wishes to
configure a distributed manager to perform secure transactions configure a distributed manager to perform secure transactions
on its behalf, it must download to the distributed manager the on its behalf, it must download to the distributed manager the
appropriate credentials to be placed in secure SNMP messages, appropriate credentials to be placed in secure SNMP messages,
identifying them as the manager. A credential contains at identifying them as the manager. A credential contains at
least the securityModel, securityName, securityLevel, least the securityModel, securityName, securityLevel,
authentication and privacy keys, and an indication of which authentication and privacy keys, and an indication of which
management targets the credential should be used for. management targets the credential should be used for.
5.4.1. Definitions 5.4.1. Definitions
----------- --------------- -------------- ----------- --------------- --------------
| | | | | | | | | | | |
| Manager |---------->| Distributed |------------->| Management | | Manager |---------->| Distributed |------------->| Management |
| | Disman | Manager | Target | Target | | | Disman | Manager | Target | Target |
skipping to change at page 9, line 4 skipping to change at page 9, line 19
5.4.1. Definitions 5.4.1. Definitions
----------- --------------- -------------- ----------- --------------- --------------
| | | | | | | | | | | |
| Manager |---------->| Distributed |------------->| Management | | Manager |---------->| Distributed |------------->| Management |
| | Disman | Manager | Target | Target | | | Disman | Manager | Target | Target |
| | User | | User | | | | User | | User | |
| | | | Identity | | | | | | Identity | |
| | | | | | | | | | | |
----------- --------------- -------------- ----------- --------------- --------------
1. Disman User - The user whose credentials are used to 1. Disman User - The user whose credentials are used to
configure the distribute manager for an operation and to configure the distributed manager for an operation and to
download credentials for that operation. There is no download credentials for that operation. There is no
relationship implied between the disman user and the relationship implied between the disman user and the
user(s) who's credentials are installed (in other words, user(s) who's credentials are installed (in other words,
"joe" can install credentials for "ops-center-east" as "joe" can install credentials for "ops-center-east" as
well as "joe"). well as "joe").
2. Target User Identity - The user identity used in SNMP 2. Target User Identity - The user identity used in SNMP
messages between the distributed manager and management messages between the distributed manager and management
targets. targets.
skipping to change at page 11, line 27 skipping to change at page 11, line 43
The Notification Destination Service provides services for The Notification Destination Service provides services for
configuring destinations for notifications. configuring destinations for notifications.
When management functions are delegated and MLMs are given the When management functions are delegated and MLMs are given the
autonomy to generate notifications, they need to be configured autonomy to generate notifications, they need to be configured
as to where the notifications should be sent. Additionally, as to where the notifications should be sent. Additionally,
retry counts and numbers need to be configured. Average and retry counts and numbers need to be configured. Average and
burst notification rates need to be defined. burst notification rates need to be defined.
6. Acknowledgments
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 MIB module containing SNMP variables for controlling
distributed managers."
-- Get real experimental number from IANA.
-- ::= { experimental XX }
::= { experimental 1 }
-- Hack to deal with a RFC1442 version of MIB compiler instead of
-- RFC1902.
Unsigned32 ::= Counter32
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 of an address."
SYNTAX OCTET STRING (SIZE (0..60))
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 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 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 }
mgmtElementObjects OBJECT IDENTIFIER ::= { mgmtObjects 3 }
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 }
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 }
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 This document was produced by the IETF Distributed Network
name of each address in the mgmtSysAccessTable Management Working Group.
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 7. References
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 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An
SYNTAX DisplayString Architecture for Describing SNMP Management Frameworks",
MAX-ACCESS read-create RFC 2271, Cabletron Systems, Inc., BMC Software, Inc.,
STATUS current IBM T. J. Watson Research, January 1998
DESCRIPTION
"The value matched against systems for this filter."
::= { mgmtRuleFilterEntry 3 }
mgmtRuleFilterRowStatus OBJECT-TYPE [2] Rose, M., and K. McCloghrie, "Structure and
SYNTAX RowStatus Identification of Management Information for TCP/IP-based
MAX-ACCESS read-create Internets", RFC 1155, Performance Systems International,
STATUS current Hughes LAN Systems, May 1990
DESCRIPTION
"The control that allows creation/deletion of RuleFilter
entries."
::= { mgmtRuleFilterEntry 4 }
END
6. Acknowledgments [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN
Systems, March 1991
This document was produced by the IETF Distributed Network [4] M. Rose, "A Convention for Defining Traps for use with
Management Working Group. the SNMP", RFC 1215, Performance Systems International,
March 1991
7. References [5] 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,
SNMP Research,Inc., Cisco Systems, Inc., Dover Beach
Consulting, Inc., International Network Services, January
1996.
[1] V. Cerf, IAB Recommendations for the Development of [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Internet Network Management Standards. Internet Working "Textual Conventions for Version 2 of the Simple Network
Group Request for Comments 1052. Network Information Management Protocol (SNMPv2)", RFC 1903, SNMP Research,
Center, SRI International, Menlo Park, California, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
(April, 1988). International Network Services, January 1996.
[2] V. Cerf, Report of the Second Ad Hoc Network Management [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Review Group, Internet Working Group Request for Comments "Conformance Statements for Version 2 of the Simple
1109. Network Information Center, SRI International, Network Management Protocol (SNMPv2)", RFC 1904, SNMP
Menlo Park, California, (August, 1989). Research, Inc., Cisco Systems, Inc., Dover Beach
Consulting, Inc., International Network Services, January
1996.
[3] M.T. Rose and K. McCloghrie, Structure and Identification [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
of Management Information for TCP/IP-based internets, "Simple Network Management Protocol", RFC 1157, SNMP
Internet Working Group Request for Comments 1155. Research, Performance Systems International, Performance
Network Information Center, SRI International, Menlo Systems International, MIT Laboratory for Computer
Park, California, (May, 1990). Science, May 1990.
[4] K. McCloghrie and M.T. Rose, Management Information Base [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
for Network Management of TCP/IP-based internets: MIB-II, "Introduction to Community-based SNMPv2", RFC 1901, SNMP
Internet Working Group Request for Comments 1213 Network Research, Inc., Cisco Systems, Inc., Dover Beach
Information Center, SRI International, Menlo Park, Consulting, Inc., International Network Services, January
California, (March, 1991). 1996.
[5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Simple Network Management Protocol, Internet Working "Transport Mappings for Version 2 of the Simple Network
Group Request for Comments 1157. Network Information Management Protocol (SNMPv2)", RFC 1906, SNMP Research,
Center, SRI International, Menlo Park, California, (May, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
1990). International Network Services, January 1996.
[6] K. McCloghrie and F. Kastenholz, Evolution of the [11] Case, J., Harrington D., Presuhn R., and B. Wijnen,
Interfaces Group of MIB-II, Internet Working Group "Message Processing and Dispatching for the Simple
Request for Comments 1573. Network Information Center, Network Management Protocol (SNMP)", RFC 2272, SNMP
SRI International, Menlo Park, California, (Jan, 1994). Research, Inc., Cabletron Systems, Inc., BMC Software,
Inc., IBM T. J. Watson Research, January 1998.
[7] Information processing systems -- Open Systems [12] Blumenthal, U., and B. Wijnen, "User-based Security Model
Interconnection -- Specification of Abstract Syntax (USM) for version 3 of the Simple Network Management
Notation One (ASN.1), International Organization for Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research,
Standardization. International Standard 8824, (December, January 1998.
1987).
[8] Information processing systems -- Open Systems [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
Interconnection -- Specification of Basic Encoding Rules "Protocol Operations for Version 2 of the Simple Network
for Abstract Notation One (ASN.1), International Management Protocol (SNMPv2)", RFC 1905, SNMP Research,
Organization for Standardization. International Standard Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
8825, (December, 1987). International Network Services, January 1996.
[9] M.T. Rose, K. McCloghrie, Editors, Concise MIB [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Definitions, Internet Working Group Request for Comments Applications", RFC 2273, SNMP Research, Inc., Secure
1212. Network Information Center, SRI International, Computing Corporation, Cisco Systems, January 1998
Menlo Park, California, (March, 1991).
[10] M.T. Rose, Editor, A Convention for Defining Traps for [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
use with the SNMP, Internet Working Group Request for Access Control Model (VACM) for the Simple Network
Comments 1215. Network Information Center, SRI Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson
International, Menlo Park, California, (March, 1991). Research, BMC Software, Inc., Cisco Systems, Inc.,
January 1998
Table of Contents Table of Contents
1 Status of this Memo ................................... 1 1 Status of this Memo ................................... 1
2 Abstract .............................................. 2 2 Abstract .............................................. 2
3 Overview .............................................. 3 3 Overview .............................................. 3
4 The Network Management Framework ...................... 4 4 Relationship to the SNMP Management Framework ......... 4
5 Distributed Management Framework ...................... 5 4.1 The SNMP Management Framework ....................... 4
5 Distributed Management Framework ...................... 6
5.1 Known Systems ....................................... 6 5.1 Known Systems ....................................... 6
5.2 Management Domains .................................. 7 5.2 Management Domains .................................. 7
5.3 Management Operations Targets ....................... 7 5.3 Management Operations Targets ....................... 7
5.4 Credential Delegation ............................... 7 5.4 Credential Delegation ............................... 8
5.4.1 Definitions ....................................... 8 5.4.1 Definitions ....................................... 9
5.5 Delegation Control .................................. 10 5.5 Delegation Control .................................. 10
5.6 Scheduling .......................................... 10 5.6 Scheduling .......................................... 11
5.7 Reliable Notification ............................... 10 5.7 Reliable Notification ............................... 11
5.8 Notification Destinations ........................... 11 5.8 Notification Destinations ........................... 11
6 Acknowledgments ....................................... 24 6 Acknowledgments ....................................... 11
7 References ............................................ 24 7 References ............................................ 12
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/