< draft-ietf-disman-framework-01.txt		draft-ietf-disman-framework-02.txt >
	Internet Draft Distributed Management Framework Dec 1997		Internet Draft Distributed Management Framework Aug, 1998
	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 37 ¶		skipping to change at page 1, line 37 ¶
	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 Internet-		check the "1id-abstracts.txt" listing contained in the
	Drafts Shadow Directories on ds.internic.net, nic.nordu.net,		Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
	venera.isi.edu, or munnari.oz.au.		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		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
	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 An overall architecture, described in RFC 2271 [1].
	monitor and control managed elements or other (distributed)
	management stations. A distributed management station is a
	type of management station that is controlled by another
	management station. Managed elements are devices such as
	hosts, routers, terminal servers, etc., which are monitored
	and controlled via access to their management information.
	Management information is viewed as a collection of managed		o Mechanisms for describing and naming objects and
	objects, residing in a virtual information store, termed the		events for the purpose of management. The first
	Management Information Base (MIB). Collections of related		version of this Structure of Management Information
	objects are defined in MIB modules. These modules are written		(SMI) is called SMIv1 and described in RFC 1155 [2],
	using a subset of OSI's Abstract Syntax Notation One (ASN.1)		RFC 1212 [3] and RFC 1215 [4]. The second version,
	[1], termed the Structure of Management Information (SMI) [2].		called SMIv2, is described in RFC 1902 [5], RFC 1903
			[6] and RFC 1904 [7].
	The management protocol, SNMPv2 [3], provides for the exchange		o Message protocols for transferring management
	of messages which convey management information between the		information. The first version of the SNMP message
	agents and the management stations. It is the purpose of this		protocol is called SNMPv1 and described in RFC 1157
	document to define managed objects which describe the behavior		[8]. A second version of the SNMP message protocol,
	of a SNMPv2 entity.		which is not an Internet standards track protocol, is
			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].
			o Protocol operations for accessing management
			information. The first set of protocol operations and
			associated PDU formats is described in RFC 1157 [8]. A
			second set of 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 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 22 ¶		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.
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 18 ¶
	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
	configure the distribute 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		1. Disman User - The user whose credentials are used to
	messages between the distributed manager and management		configure the distributed manager for an operation and to
	targets.		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").
	3. Credential - The set of secrets that are transferred		2. Target User Identity - The user identity used in SNMP
	to the distributed manager giving it the authority to act		messages between the distributed manager and management
	as an identity.		targets.
	4. Owner - The disman user who sets up a distributed		3. Credential - The set of secrets that are transferred
	management function, including the credentials for the		to the distributed manager giving it the authority to act
	function.		as an identity.
	5. Invoker - The user who invokes a previously setup		4. Owner - The disman user who sets up a distributed
	distributed management function. The owner may choose to		management function, including the credentials for the
	allow others to invoke a function, potentially allowing		function.
	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		5. Invoker - The user who invokes a previously setup
	a function is operating with. These may be of the owner,		distributed management function. The owner may choose to
	of the invoker, or possibly the union of both		allow others to invoke a function, potentially allowing
	credentials.		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		Because multiple Disman Users will have access to a
	Distributed Manager, the Credential Delegation Service will be		Distributed Manager, the Credential Delegation Service will be
	responsible for ensuring that credentials are only used by		responsible for ensuring that credentials are only used by
	authorized users. The Credential Delegation Service will		authorized users. The Credential Delegation Service will
	include:		include:
	1. Credential Store - a MIB in which to transfer and		1. Credential Store - a MIB in which to transfer and
	store credentials		store credentials
	2. MIB prototype - a prototype MIB fragment that will be		2. MIB prototype - a prototype MIB fragment that will be
	added to disman functions that wish to use the Credential		added to disman functions that wish to use the Credential
	Store		Store
	3. Access Control Policy - a policy for configuration of		3. Access Control Policy - a policy for configuration of
	the VACM MIB for use with the Credential Delegation		the VACM MIB for use with the Credential Delegation
	Service. This will limit access to the credential store.		Service. This will limit access to the credential store.
	5.5. Delegation Control		5.5. Delegation Control
	The Delegation Control Service provides functions that limit		The Delegation Control Service provides functions that limit
	the resource usage of a distributed management application		the resource usage of a distributed management application
	that has had control delegated to it.		that has had control delegated to it.
	Network management applications are often responsible for		Network management applications are often responsible for
	adding stress on the network and causing problems. Examples		adding stress on the network and causing problems. Examples
	are excessive polling load on slow-speed networks or on router		are excessive polling load on slow-speed networks or on router
	skipping to change at page 11, line 26 ¶		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. 45 change blocks.
	633 lines changed or deleted		179 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/