idnits 2.17.1 draft-ietf-disman-framework-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 629 has weird spacing: '...- Index doma...' == Line 633 has weird spacing: '...tsIndex sys...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Dec 1997) is 9628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1035, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1063, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1052 (ref. '1') ** Downref: Normative reference to an Unknown state RFC: RFC 1109 (ref. '2') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '5') ** Obsolete normative reference: RFC 1573 (ref. '6') (Obsoleted by RFC 2233) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '10') Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Distributed Management Framework Dec 1997 4 Distributed Management Framework 5 7 December 15, 1996 9 Authors: 11 Andy Bierman 12 Cisco Systems 13 abierman@cisco.com 15 Maria Greene 16 Ascom Nexion 17 greene@nexen.com 19 Bob Stewart 20 Cisco Systems 21 bstewart@cisco.com 23 Steve Waldbusser 24 International Network Services (INS) 25 waldbusser@ins.com 27 1. Status of this Memo 29 This document is an Internet-Draft. Internet-Drafts are 30 working documents of the Internet Engineering Task Force 31 (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months. Internet-Drafts may be updated, replaced, or 37 obsoleted by other documents at any time. It is not 38 appropriate to use Internet-Drafts as reference material or to 39 cite them other than as a ``working draft'' or ``work in 40 progress.'' 42 To learn the current status of any Internet-Draft, please 43 check the 1id-abstracts.txt listing contained in the Internet- 44 Drafts Shadow Directories on ds.internic.net, nic.nordu.net, 45 venera.isi.edu, or munnari.oz.au. 47 2. Abstract 49 This memo defines a distributed management architecture for 50 use with the SNMP network management architecture. 52 This memo does not specify a standard for the Internet 53 community. 55 3. Overview 57 Distributed Management is the delegation of control from one 58 management station to another. While the SNMP Network 59 Management Framework does not specifically address distributed 60 management, this function is desired and has been implemented 61 and deployed in the internet using proprietary architectures. 62 It is desired that there be a standard upon which to promote 63 interoperability, as well as a common framework upon which 64 various systems can be built. 66 The goals of distributed management are: 68 o Scalability through Distribution 69 In order to build network management systems that have the 70 power to manage very large networks, it is important to 71 reduce bottlenecks in the management system. Therefore, a 72 distributed systems approach is often helpful when 73 building large management systems. A distributed approach 74 is often very effective at reducing load on the central 75 management station, and may be effective at reducing the 76 load that the central management station places on 77 backbone networks. However, a distributed approach usually 78 has no benefit in reducing load on remote networks and has 79 no benefit in reducing load on management agents. Further, 80 in a distributed data collection architecture, if all data 81 collected is eventually forwarded to the central 82 management station (without aggregation or compression), 83 then no benefit in backbone load or central management 84 station load should be expected (except perhaps to time- 85 shift this load to a time of excess capacity, at the 86 expense of a lack of timeliness of data. 88 o Disconnected or Low-Bandwidth Operation 89 There are sometimes conditions when a management station 90 will not be in constant contact with all portions of the 91 managed network. This is sometimes by design in an attempt 92 to lower communications costs (especially when 93 communicating over a WAN or dialup link), or by accident 94 as network failures affect the communications between the 95 management station and portions of the managed network. 97 For this reason, a distributed management station will be 98 configured to perform network management functions, even 99 when communication with the management station may not be 100 possible or efficient. The distributed management station 101 may then attempt to notify the management station when an 102 exceptional condition occurs. Thus, even in circumstances 103 where communication with the distributed management 104 station is not continuous, network management operations 105 may run continuously, communicating with the management 106 station conveniently and efficiently, on an as-needed 107 basis. 109 o Mirroring organization boundaries and processes 110 Business organizations are typically set up in a 111 hierarchical fashion. Multiple people in the hierarchy 112 have different roles, responsibilites, and authority. The 113 network management system often has to be configured to 114 match this organization. Distributed network managers can 115 be set up in a hierarchy that matches the roles of various 116 people in the organization. 118 o Promotes a modular system architecture 119 A modular system architecture allows flexibility and re- 120 usability of network management components. This also 121 enables a multi-vendor approach to building management 122 systems. A distributed network management system with 123 well-defined interfaces creates this modular scheme. 125 This document defines an architectural framework for 126 standards-based distributed management 128 4. The Network Management Framework 130 A distributed network management station is a management 131 station that receives requests from another manager and 132 executes those requests by performing management operations on 133 agents or other managers. Note that these requests may take a 134 long time to execute, and may be registered indefinitely. 136 With the addition of the distributed network management 137 station, the SNMP Network Management Framework consists of the 138 following entities: 140 A management system contains: several (potentially many) 141 nodes, each with a processing entity, termed an agent, which 142 has access to management instrumentation; at least one 143 management station; and, a management protocol, used to convey 144 management information between the agents and management 145 stations. Operations of the protocol are carried out under an 146 administrative framework which defines authentication, 147 authorization, access control, and privacy policies. 149 Management stations execute management applications which 150 monitor and control managed elements or other (distributed) 151 management stations. A distributed management station is a 152 type of management station that is controlled by another 153 management station. Managed elements are devices such as 154 hosts, routers, terminal servers, etc., which are monitored 155 and controlled via access to their management information. 157 Management information is viewed as a collection of managed 158 objects, residing in a virtual information store, termed the 159 Management Information Base (MIB). Collections of related 160 objects are defined in MIB modules. These modules are written 161 using a subset of OSI's Abstract Syntax Notation One (ASN.1) 162 [1], termed the Structure of Management Information (SMI) [2]. 164 The management protocol, SNMPv2 [3], provides for the exchange 165 of messages which convey management information between the 166 agents and the management stations. It is the purpose of this 167 document to define managed objects which describe the behavior 168 of a SNMPv2 entity. 170 5. Distributed Management Framework 172 The distributed management framework consists of applications 173 and services. 175 A distributed management application performs some management 176 function, often by monitoring and controlling managed 177 elements. These applications perform functions such as 178 threshold polling, historical data polling, or discovery. The 179 specifications and communications protocols of some of these 180 applications will be defined by standards, while others will 181 be enterprise specific. 183 Distributed management services are a collection of services 184 that make up the run-time environment for the distributed 185 management application. These services are crucial to ensuring 186 the usability, scalability, and efficiency of the distributed 187 management applications that depend on them. Some of these 188 services are mandatory, while others are optional. Further, 189 even the mandatory services allow varying depths of support, 190 as described further, below. 192 Each of these services is made available through a MIB 193 interface. 195 The purpose of these services is to provide true enterprise 196 management that allows distributed management functions to be 197 used on an enterprise-wide basis without undue amounts of 198 administrative difficulty. These services also make a set of 199 applications more efficient because the service can perform 200 functions or store information once for all applications on 201 the local system. Further, less work is required to be put 202 into writing the application because some of the core 203 functions are performed elsewhere. 205 5.1. Known Systems 207 The Known Systems service provides a list of all systems which 208 the distributed management system knows about and is prepared 209 to perform management operations upon. This list may be 210 populated by a continuously-running auto-discovery process, it 211 may be populated with SNMP SET requests, or it may be a static 212 list dictated by the system. 214 This service also stores type and attribute information for 215 each of the known systems. 217 The purpose of this service is to allow a management 218 application to be executed on a list of systems so that true 219 enterprise management is possible rather than more ad-hoc 220 management functions. Further, the targets of management 221 applications can be configured separately from the 222 applications to reduce administrative burden as the list of 223 known systems changes. 225 An example of a known systems list is a list of all systems at 226 a site discovered by the autodiscovery module, along with 227 various addressing, type, and attribute information for each. 229 5.2. Management Domains 231 The Management Domains service provides a list of known 232 systems which is a subset of the entire list of known systems. 233 The subset is defined by a rule, or filter, which selects only 234 the known systems that match or those that don't match certain 235 criteria. 237 These domains are multiple, potentially overlapping, sets of 238 devices based on (human) organizational boundaries that define 239 the extents over which management operations should be 240 performed. 242 The purpose of this service is to allow a management 243 application to be executed on a list of known systems within a 244 particular domain. Further, as the domains change over time, 245 the application will automatically be kept up to date and will 246 only monitor the correct systems. 248 An example of a management domain is the subset of all known 249 systems that is on the engineering LAN. 251 5.3. Management Operations Targets 253 The Management Operations Targets service provides a list of 254 known systems in a set of domains that match certain criteria 255 that indicate that it makes sense to perform a particular 256 management function on them. 258 The purpose of this service is to direct management operations 259 to be performance only on those systems where that operation 260 would make sense. Because this is described as a filter, there 261 are no static configuration requirements that would be 262 unacceptable in a dynamically changing network environment. 264 An example of a management operation target list is the subset 265 of all known routers on the engineering LAN. 267 5.4. Credential Delegation 269 The Credential Delegation Service allows credentials of a 270 network management user to be delegated to a distributed 271 management application so that it can perform secure 272 operations on behalf of that user. 274 Fundamental to this distributed management architecture is the 275 notion that distributed management operations must not run 276 with the credentials of the distributed manager. To do so 277 would require that the authorization of these credentials (or 278 subsets of this authorization) would need to be apportioned to 279 users of that distributed manager in a pre-defined and secure 280 way. This would require the creation of a access control 281 architecture mirroring the SNMP View-Based Access Control 282 architecture that would control what subsets of authority are 283 available to what users. The existing View-Based Access 284 Control mechanism was not designed for this task and is not 285 appropriate. Further, it would require that the distributed 286 manager be configured in a way that was consistent with the 287 access control policy embodied in the managed systems. This 288 would be extremely problematic because: 290 1. This would require a massive amount of configuration 291 to be replicated on the distribute manager 293 2. If any part of this configuration on the distribute 294 manager is inconsistent with that on the managed systems, 295 a security hole could be exposed. 297 Because it is assumed that the distributed manager adds no 298 credentials to management operations, when a manager wishes to 299 configure a distributed manager to perform secure transactions 300 on its behalf, it must download to the distributed manager the 301 appropriate credentials to be placed in secure SNMP messages, 302 identifying them as the manager. A credential contains at 303 least the securityModel, securityName, securityLevel, 304 authentication and privacy keys, and an indication of which 305 management targets the credential should be used for. 307 5.4.1. Definitions 309 ----------- --------------- -------------- 310 | | | | | | 311 | Manager |---------->| Distributed |------------->| Management | 312 | | Disman | Manager | Target | Target | 313 | | User | | User | | 314 | | | | Identity | | 315 | | | | | | 316 ----------- --------------- -------------- 317 1. Disman User - The user whose credentials are used to 318 configure the distribute manager for an operation and to 319 download credentials for that operation. There is no 320 relationship implied between the disman user and the 321 user(s) who's credentials are installed (in other words, 322 "joe" can install credentials for "ops-center-east" as 323 well as "joe"). 325 2. Target User Identity - The user identity used in SNMP 326 messages between the distributed manager and management 327 targets. 329 3. Credential - The set of secrets that are transferred 330 to the distributed manager giving it the authority to act 331 as an identity. 333 4. Owner - The disman user who sets up a distributed 334 management function, including the credentials for the 335 function. 337 5. Invoker - The user who invokes a previously setup 338 distributed management function. The owner may choose to 339 allow others to invoke a function, potentially allowing 340 that function to operate with the owner's credentials (of 341 course the owner would want to tightly constrain what the 342 function was configured to perform). 344 6. Invokation Identity - The identity of the credentials 345 a function is operating with. These may be of the owner, 346 of the invoker, or possibly the union of both 347 credentials. 349 Because multiple Disman Users will have access to a 350 Distributed Manager, the Credential Delegation Service will be 351 responsible for ensuring that credentials are only used by 352 authorized users. The Credential Delegation Service will 353 include: 355 1. Credential Store - a MIB in which to transfer and 356 store credentials 358 2. MIB prototype - a prototype MIB fragment that will be 359 added to disman functions that wish to use the Credential 360 Store 362 3. Access Control Policy - a policy for configuration of 363 the VACM MIB for use with the Credential Delegation 364 Service. This will limit access to the credential store. 366 5.5. Delegation Control 368 The Delegation Control Service provides functions that limit 369 the resource usage of a distributed management application 370 that has had control delegated to it. 372 Network management applications are often responsible for 373 adding stress on the network and causing problems. Examples 374 are excessive polling load on slow-speed networks or on router 375 CPUs. This problem will become even more dangerous when 376 network management functions are delegated to distributed 377 management stations. 379 Policies need to be configured that limit average and burst 380 polling, notification, and broadcast rates. These rates may 381 be defined for the sending system as a whole, per end node, or 382 per management application on the sending system. 384 It is also important to have a "Deadman's switch" so that 385 delegated applications will not continue indefinitely if their 386 "sponsor" has forgotten about them. 388 5.6. Scheduling 390 The Scheduling Service allows the execution of distributed 391 management applications to be controlled so that they run at a 392 particular time, periodically, or based on the occurance of 393 another event. 395 5.7. Reliable Notification 397 The Reliable Notification Service provides services that 398 ensure that notifications are received correctly. 400 For example, all the information that describes an event may 401 not fit within a single PDU, so an eventID varbind is defined 402 that associates multiple PDU's as describing the same event. 403 It is also necessary to know if the entire notification has 404 been received or if more PDU's are still outstanding. 406 Further, a receiving management station must be given more 407 information so that it can distinguish duplicated inform PDU's 408 because events are not idempotent. No rule makes it mandatory 409 for the requestID to be unique for all PDUs sent from a 410 system. 412 In addition, a logging mechanism provides for retrieval of 413 notifications after a communications failure. 415 5.8. Notification Destinations 417 The Notification Destination Service provides services for 418 configuring destinations for notifications. 420 When management functions are delegated and MLMs are given the 421 autonomy to generate notifications, they need to be configured 422 as to where the notifications should be sent. Additionally, 423 retry counts and numbers need to be configured. Average and 424 burst notification rates need to be defined. 426 -- Remove hacks for Unsigned32 and BITS datatypes. I need these because 427 -- my version of SMIC is RFC1442 compliant, not RFC1902. 429 DISMAN-SERVICES-MIB DEFINITIONS ::= BEGIN 431 IMPORTS 432 MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, zeroDotZero, 433 NOTIFICATION-TYPE, Counter32, Gauge32, Counter64 -- , Unsigned32, BITS 434 FROM SNMPv2-SMI 435 TEXTUAL-CONVENTION, AutonomousType, DisplayString, DateAndTime, 436 RowStatus, TDomain, TimeStamp, TestAndIncr 437 FROM SNMPv2-TC 438 snmpUDPDomain 439 FROM SNMPv2-TM 440 MODULE-COMPLIANCE, OBJECT-GROUP 441 FROM SNMPv2-CONF 442 OwnerString 443 FROM RMON-MIB 444 ; 446 dismanMIB MODULE-IDENTITY 447 LAST-UPDATED "9612221200Z" 448 ORGANIZATION "IETF Distributed Management Working Group" 449 CONTACT-INFO 450 "Working group mailing list: disman@nexen.com" 451 DESCRIPTION 452 "The MIB module containing SNMP variables for controlling 453 distributed managers." 454 -- Get real experimental number from IANA. 455 -- ::= { experimental XX } 456 ::= { experimental 1 } 458 -- Hack to deal with a RFC1442 version of MIB compiler instead of 459 -- RFC1902. 460 Unsigned32 ::= Counter32 462 --**************************************************************** 463 -- Textual Conventions 464 --**************************************************************** 466 ElementName ::= TEXTUAL-CONVENTION 467 STATUS current 468 DESCRIPTION 469 "A string that uniquely identifies a management element which 470 may be a system or a collection of systems." 471 SYNTAX DisplayString (SIZE (1..64)) 473 IANAAddrFamily ::= TEXTUAL-CONVENTION 474 STATUS current 475 DESCRIPTION 476 "An address family. Values are defined in Assigned Numbers, 477 RFC1700. Note that not all these values make sense in all 478 contexts where this type is used in this MIB, but they are 479 included for completeness." 480 REFERENCE 481 "Assigned Numbers, RFC1700, ADDRESS FAMILY NUMBERS" 482 SYNTAX INTEGER { 483 other(0), 484 ipV4(1), 485 ipV6(2), 486 nsap(3), 487 hdlc(4), 488 bbn1822(5), 489 ieee802(6), 490 e163(7), 491 e164(8), 492 f69(9), 493 x121(10), 494 ipx(11), 495 appleTalk(12), 496 decnetIV(13), 497 banyanVines(14), 498 e164WithNsap(15) 499 } 501 GenAddr ::= TEXTUAL-CONVENTION 502 STATUS current 503 DESCRIPTION 504 "The value of an address." 505 SYNTAX OCTET STRING (SIZE (0..60)) 507 --**************************************************************** 508 -- Managed Object definitions 509 --**************************************************************** 511 mgmtObjects OBJECT IDENTIFIER ::= { dismanMIB 1 } 512 mgmtGeneralObjects OBJECT IDENTIFIER ::= { mgmtObjects 1 } 514 mgmtLock OBJECT-TYPE 515 SYNTAX TestAndIncr 516 MAX-ACCESS read-write 517 STATUS current 518 DESCRIPTION 519 "An advisory lock for all writable objects in the entire 520 Distributed Management Services MIB." 521 ::= { mgmtGeneralObjects 1 } 523 mgmtOwner OBJECT-TYPE 524 SYNTAX OwnerString 525 MAX-ACCESS read-write 526 STATUS current 527 DESCRIPTION 528 "The manager entity that 'owns' this distributed manager's 529 configuration." 530 ::= { mgmtGeneralObjects 2 } 532 mgmtAdminStatus OBJECT-TYPE 533 SYNTAX INTEGER { 534 enabled(1), 535 disabled(2), 536 disabledReset(3) 538 } 539 MAX-ACCESS read-write 540 STATUS current 541 DESCRIPTION 542 "The desired status of this distributed manager. The value 543 'enabled(1)' indicates the distributed manager should be 544 active. The value 'disabled(2)' indicates that the desired 545 operational status is also 'disabled(2)'. A top-level manager 546 may disable a distributed manager in order to change its 547 configuration and have the changes take effect all at once or 548 it may keep the distributed manager disabled as a redundant or 549 back-up manager. The value 'disabledReset(3)' is used to 550 disable a distributed manager and simultaneously remove all 551 entries from its DISMAN MIB tables that support row 552 creation. This allows the top-level manager to put the 553 distributed manager into a known state before downloading a 554 new configuration." 555 ::= { mgmtGeneralObjects 3 } 557 mgmtOperStatus OBJECT-TYPE 558 SYNTAX INTEGER { 559 enabled(1), 560 disabled(2) 561 } 562 MAX-ACCESS read-only 563 STATUS current 564 DESCRIPTION 565 "The actual status of this distributed manager." 566 ::= { mgmtGeneralObjects 4 } 568 mgmtStatusLastChange OBJECT-TYPE 569 SYNTAX TimeStamp 570 MAX-ACCESS read-only 571 STATUS current 572 DESCRIPTION 573 "The value of sysUpTime the last time mgmtOperStatus changed 574 value." 575 ::= { mgmtGeneralObjects 5 } 577 -- 578 -- Managed Element Services 579 -- 580 -- In order for a distributed management application to use these 581 -- managemed element services, it must specify both a domain rule index 582 -- and a target rule index. For example, the trivial application below 583 -- would simply return the values of the systems identified by a 584 -- particular domain rule index and target rule index. 585 -- 586 -- testAppEntry ::= SEQUENCE { 587 -- testAppIndex Integer32, # INDEX 588 -- testAppDomainIndex Integer32, 589 -- testAppTargetIndex Integer32, 590 -- testAppRowStatus RowStatus 591 -- } 592 -- 593 -- testAppResultsEntry ::= SEQUENCE { 594 -- # Indexed by { testAppIndex, testAppResultsIndex } 595 -- testAppResultsIndex Integer32, 596 -- testAppResultsSystemName ElementName 597 -- } 598 -- 599 -- 600 -- An example distributed management system might contain: 601 -- 602 -- mgmtKnownSystemTable 603 -- Name DateTime Algorithm ManualDomain SystemID 604 -- router1 ... ... ... acme5000 605 -- router2 ... ... ... acme3000 606 -- router3 ... ... ... acme5000 607 -- 608 -- mgmtSysAccessTable 609 -- Name Index AddrType Addr SNMPPort AuthString RowStatus 610 -- router1 1 IP 1.1.1.1 161 ... active 611 -- router1 2 IP 1.1.2.1 161 ... active 612 -- router2 3 IP 1.1.1.5 161 ... active 613 -- router3 4 IP 1.1.1.4 161 ... active 614 -- router3 5 IP 1.1.4.9 161 ... active 615 -- 616 -- mgmtRuleTable 617 -- Index Name RowStatus 618 -- 1 "Finance" active 619 -- 2 "Acme 5000" active 620 -- 621 -- mgmtRuleFilterTable 622 -- Index FilterIndex Type Filter RowStatus 623 -- 1 1 matchAddress "^1.1.2" active 624 -- 1 2 matchAddress "^1.1.4" active 625 -- # Rule 1 matches all hosts on subnet 2 and subnet 4 626 -- 2 3 matchSystemID "acme5000" active 627 -- 628 -- testAppTable 629 -- Index domainIndex targetIndex RowStatus 630 -- 1 1 2 active 631 -- 632 -- testAppResultsTable 633 -- Index ResultsIndex systemName 634 -- 1 1 "router1" 635 -- 1 2 "router3" 636 -- 637 -- If this was a script application, the script would execute on 638 -- router1 and router3. 640 mgmtElementObjects OBJECT IDENTIFIER ::= { mgmtObjects 3 } 642 -- 643 -- The Known System Table 644 -- 646 mgmtKnownSystemTable OBJECT-TYPE 647 SYNTAX SEQUENCE OF MgmtKnownSystemEntry 648 MAX-ACCESS not-accessible 649 STATUS current 650 DESCRIPTION 651 "A table of all known systems that are potential management 652 targets." 653 ::= { mgmtElementObjects 1 } 655 mgmtKnownSystemEntry OBJECT-TYPE 656 SYNTAX MgmtKnownSystemEntry 657 MAX-ACCESS not-accessible 658 STATUS current 659 DESCRIPTION 660 "Information about a single management system. While most 661 known systems will usually be populated by the agent, new 662 systems can be created using the mgmtKnownSystemRowStatus 663 variable." 664 INDEX { IMPLIED mgmtKnownSystemName } 665 ::= { mgmtKnownSystemTable 1 } 667 MgmtKnownSystemEntry ::= SEQUENCE { 668 mgmtKnownSystemName ElementName, 669 mgmtKnownSystemDateTimeCreated DateAndTime, 670 mgmtKnownSystemAlgorithm AutonomousType, 671 mgmtKnownSystemManualDomain OCTET STRING, 672 mgmtKnownSystemID AutonomousType, 673 mgmtKnownSystemRowStatus RowStatus 674 } 676 mgmtKnownSystemName OBJECT-TYPE 677 SYNTAX ElementName 678 MAX-ACCESS not-accessible 679 STATUS current 680 DESCRIPTION 681 "The name of the element. If this record is created automatically 682 (e.g., as part of a discovery process), this name can be 683 algorithmically assigned using any algorithm that guarantees 684 uniqueness. It is recommended that this value be human readable, 685 and for that reason an ascii representation of the address is 686 often suitable in cases where more detail is not known." 687 ::= { mgmtKnownSystemEntry 1 } 689 mgmtKnownSystemDateTimeCreated OBJECT-TYPE 690 SYNTAX DateAndTime 691 MAX-ACCESS read-only 692 STATUS current 693 DESCRIPTION 694 "The date and time when this object was added to the distributed 695 managers database." 696 ::= { mgmtKnownSystemEntry 2 } 698 mgmtKnownSystemAlgorithm OBJECT-TYPE 699 SYNTAX AutonomousType 700 MAX-ACCESS read-only 701 STATUS current 702 DESCRIPTION 703 "The method used to create this entry. The value { 0 0 } (a 704 NULL object identifier) indicates that the entry was added 705 'manually' via the table's RowStatus column. Other values may 706 indicate various discovery algorithms." 707 DEFVAL { zeroDotZero } 708 ::= { mgmtKnownSystemEntry 3 } 710 mgmtKnownSystemManualDomain OBJECT-TYPE 711 SYNTAX OCTET STRING 712 MAX-ACCESS read-create 713 STATUS current 714 DESCRIPTION 715 "A bit mask of domains the system is a member of. Every 1 bit 716 in this string indicates that this system is a part of the 717 domain who's rule index is equal to the bit position of the 718 bit. The first bit in the string is equal to the rule index 719 of 1. If this object indicates that a system is part of a 720 domain, it is understood to be part of that domain no matter 721 what the rule set is for the domain (i.e. domain membership is 722 an OR function of this object and the domain rules). 724 This object only has an effect on rules that are used as 725 domains. In particular this means that if a bit is set for a 726 rule and that rule is used as a target, the bit will have no 727 effect." 728 ::= { mgmtKnownSystemEntry 4 } 730 mgmtKnownSystemID OBJECT-TYPE 731 SYNTAX AutonomousType 732 MAX-ACCESS read-create 733 STATUS current 734 DESCRIPTION 735 "The type of the system. This will typically be 736 the same value as the sysObjectID for the system. 737 The value zeroDotZero indicates an unknown type." 738 DEFVAL { zeroDotZero } 739 ::= { mgmtKnownSystemEntry 5 } 741 mgmtKnownSystemRowStatus OBJECT-TYPE 742 SYNTAX RowStatus 743 MAX-ACCESS read-create 744 STATUS current 745 DESCRIPTION 746 "The control that allows creation/deletion of system entries." 747 ::= { mgmtKnownSystemEntry 6 } 749 -- 750 -- The System Management Access Table 751 -- 753 mgmtSysAccessTable OBJECT-TYPE 754 SYNTAX SEQUENCE OF MgmtSysAccessEntry 755 MAX-ACCESS not-accessible 756 STATUS current 757 DESCRIPTION 758 "A table of access information for the management entities 759 (either SNMP managers or SNMP agents) running on systems." 760 ::= { mgmtElementObjects 2 } 762 mgmtSysAccessEntry OBJECT-TYPE 763 SYNTAX MgmtSysAccessEntry 764 MAX-ACCESS not-accessible 765 STATUS current 766 DESCRIPTION 767 "Information about a single management entity." 768 INDEX { mgmtKnownSystemName, mgmtSysAccessIndex } 769 ::= { mgmtSysAccessTable 1 } 771 MgmtSysAccessEntry ::= SEQUENCE { 772 mgmtSysAccessIndex Integer32, 773 mgmtSysAccessAddrType IANAAddrFamily, 774 mgmtSysAccessAddr GenAddr, 775 mgmtSysAccessSNMPPort Integer32, 776 mgmtSysAccessAuthString OCTET STRING, 777 mgmtSysAccessRowStatus RowStatus 778 } 780 mgmtSysAccessIndex OBJECT-TYPE 781 SYNTAX Integer32 782 MAX-ACCESS not-accessible 783 STATUS current 784 DESCRIPTION 785 "An index number for the access information so that the agent 786 can keep track of multiple managers and multiple agents 787 running on the same system (presumably at different transport 788 addresses.)" 789 ::= { mgmtSysAccessEntry 1 } 791 mgmtSysAccessAddrType OBJECT-TYPE 792 SYNTAX IANAAddrFamily 793 MAX-ACCESS read-create 794 STATUS current 795 DESCRIPTION 796 "The type of the address identified by mgmtSysAccessAddr." 797 DEFVAL { ipV4 } 798 ::= { mgmtSysAccessEntry 2 } 800 mgmtSysAccessAddr OBJECT-TYPE 801 SYNTAX GenAddr 802 MAX-ACCESS read-create 803 STATUS current 804 DESCRIPTION 805 "The management address for the manager or agent. A 806 zero-length string indicates an unknown address." 807 DEFVAL { ''H } 808 ::= { mgmtSysAccessEntry 3 } 810 mgmtSysAccessSNMPPort OBJECT-TYPE 811 SYNTAX Integer32 812 MAX-ACCESS read-create 813 STATUS current 814 DESCRIPTION 815 "The port for an SNMP agent on this system." 816 DEFVAL { 161 } 817 ::= { mgmtSysAccessEntry 4 } 819 mgmtSysAccessAuthString OBJECT-TYPE 820 SYNTAX OCTET STRING 821 MAX-ACCESS read-create 822 STATUS current 823 DESCRIPTION 824 "Authentication information for accessing this system at this port." 825 ::= { mgmtSysAccessEntry 5 } 827 mgmtSysAccessRowStatus OBJECT-TYPE 828 SYNTAX RowStatus 829 MAX-ACCESS read-create 830 STATUS current 831 DESCRIPTION 832 "A control that allows creation/deletion of system management 833 entity entries." 834 ::= { mgmtSysAccessEntry 6 } 835 -- 836 -- Rules 837 -- 839 mgmtRuleTable OBJECT-TYPE 840 SYNTAX SEQUENCE OF MgmtRuleEntry 841 MAX-ACCESS not-accessible 842 STATUS current 843 DESCRIPTION 844 "A table of rules. 846 A rule is a set of filters by which a list of systems can be 847 selected from a larger list, based on a match of one or more 848 filters. 850 Rules are used in 2 contexts, to select a domain, or to 851 select managed operations targets. A domain defines those 852 systems within a particular organizational boundary within 853 which certain operations should be performed. A set of 854 management operations targets is a subset of a domain that 855 restricts an operation to only those systems upon which the 856 operation `makes sense'. Domain rules are distinguishable from 857 target rules only by the context in which they are 858 used. However, in general, it is not useful to use a filter 859 designed to select a target in the context of a domain, or 860 vice versa. 862 A system matches a rule if it was part of the appropriate 863 input set (ALL, or member of a domain), and one or more 864 ruleFilters evaluates to true for the system." 865 ::= { mgmtElementObjects 3 } 867 mgmtRuleEntry OBJECT-TYPE 868 SYNTAX MgmtRuleEntry 869 MAX-ACCESS not-accessible 870 STATUS current 871 DESCRIPTION 872 "Information about a single rule. New rules 873 can be created using the mgmtRuleRowStatus variable." 874 INDEX { mgmtRuleIndex } 875 ::= { mgmtRuleTable 1 } 877 MgmtRuleEntry ::= SEQUENCE { 878 mgmtRuleIndex Integer32, 879 mgmtRuleName DisplayString, 880 mgmtRuleRowStatus RowStatus 881 } 883 mgmtRuleIndex OBJECT-TYPE 884 SYNTAX Integer32 (1..2147483647) 885 MAX-ACCESS not-accessible 886 STATUS current 887 DESCRIPTION 888 "A unique index for this rule." 889 ::= { mgmtRuleEntry 1 } 891 mgmtRuleName OBJECT-TYPE 892 SYNTAX DisplayString 893 MAX-ACCESS read-create 894 STATUS current 895 DESCRIPTION 896 "A human readable name for this rule. This name 897 should describe the purpose/scope of the rule, for 898 example `Headquarters' or `Acme Routers'." 899 ::= { mgmtRuleEntry 2 } 901 mgmtRuleRowStatus OBJECT-TYPE 902 SYNTAX RowStatus 903 MAX-ACCESS read-create 904 STATUS current 905 DESCRIPTION 906 "The control that allows creation/deletion of rule entries." 907 ::= { mgmtRuleEntry 3 } 909 mgmtRuleFilterTable OBJECT-TYPE 910 SYNTAX SEQUENCE OF MgmtRuleFilterEntry 911 MAX-ACCESS not-accessible 912 STATUS current 913 DESCRIPTION 914 "A table of filters for a rule. 916 If this filter is executed in the context of a domain, it 917 selects a subset of all of the systems in the 918 mgmtKnownSystemTable. If this filter is executed in the 919 context of a target, it selects a subset of all systems 920 matched by the associated domain rule. 922 If a rule has multiple filters, the rule selects the union of 923 all systems selected by the filters." 924 ::= { mgmtElementObjects 4 } 926 mgmtRuleFilterEntry OBJECT-TYPE 927 SYNTAX MgmtRuleFilterEntry 928 MAX-ACCESS not-accessible 929 STATUS current 930 DESCRIPTION 931 "Information about a single filter. New filters 932 can be created using the mgmtRuleFilterRowStatus variable. 933 A row can only be created if it contains a value of 934 mgmtRuleIndex that already exists. Further, if a 935 mgmtRuleIndex is deleted from the mgmtRuleTable, all 936 associated entries shall be deleted from the 937 mgmtRuleFilterTable." 938 INDEX { mgmtRuleIndex, mgmtRuleFilterIndex } 939 ::= { mgmtRuleFilterTable 1 } 941 MgmtRuleFilterEntry ::= SEQUENCE { 942 mgmtRuleFilterIndex Integer32, 943 mgmtRuleFilterType INTEGER, 944 mgmtRuleFilter DisplayString, 945 mgmtRuleFilterRowStatus RowStatus 946 } 948 mgmtRuleFilterIndex OBJECT-TYPE 949 SYNTAX Integer32 950 MAX-ACCESS not-accessible 951 STATUS current 952 DESCRIPTION 953 "A unique index for this rule." 954 ::= { mgmtRuleFilterEntry 1 } 956 mgmtRuleFilterType OBJECT-TYPE 957 SYNTAX INTEGER { 958 matchAddress(1), 959 matchDomainName(2), 960 matchSystemID(3) 961 } 962 MAX-ACCESS read-create 963 STATUS current 964 DESCRIPTION 965 "If this object has the value `matchAddress(1)', the ascii 966 representation (TBD) of each address in the mgmtSysAccessTable 967 will be evaluated against the regular expression in the 968 associated mgmtRuleFilter object. If the match succeeds, the 969 system associated with the mgmtSysAccessEntry matches this 970 filter. 972 If this object has the value `matchDomainName(2)', the domain 973 name of each address in the mgmtSysAccessTable 974 will be evaluated against the regular expression in the 975 associated mgmtRuleFilter object. If the match succeeds, the 976 system associated with the mgmtSysAccessEntry matches this 977 filter. 979 If this object has the value `matchSystemID(1)', the ascii 980 representation (TBD) of each mgmtKnownSystemID 981 will be evaluated against the regular expression in the 982 associated mgmtRuleFilter object. If the match succeeds, the 983 system associated with the mgmtKnownSystemID matches this 984 filter." 985 ::= { mgmtRuleFilterEntry 2 } 987 mgmtRuleFilter OBJECT-TYPE 988 SYNTAX DisplayString 989 MAX-ACCESS read-create 990 STATUS current 991 DESCRIPTION 992 "The value matched against systems for this filter." 993 ::= { mgmtRuleFilterEntry 3 } 995 mgmtRuleFilterRowStatus OBJECT-TYPE 996 SYNTAX RowStatus 997 MAX-ACCESS read-create 998 STATUS current 999 DESCRIPTION 1000 "The control that allows creation/deletion of RuleFilter 1001 entries." 1002 ::= { mgmtRuleFilterEntry 4 } 1003 END 1005 6. Acknowledgments 1007 This document was produced by the IETF Distributed Network 1008 Management Working Group. 1010 7. References 1012 [1] V. Cerf, IAB Recommendations for the Development of 1013 Internet Network Management Standards. Internet Working 1014 Group Request for Comments 1052. Network Information 1015 Center, SRI International, Menlo Park, California, 1016 (April, 1988). 1018 [2] V. Cerf, Report of the Second Ad Hoc Network Management 1019 Review Group, Internet Working Group Request for Comments 1020 1109. Network Information Center, SRI International, 1021 Menlo Park, California, (August, 1989). 1023 [3] M.T. Rose and K. McCloghrie, Structure and Identification 1024 of Management Information for TCP/IP-based internets, 1025 Internet Working Group Request for Comments 1155. 1026 Network Information Center, SRI International, Menlo 1027 Park, California, (May, 1990). 1029 [4] K. McCloghrie and M.T. Rose, Management Information Base 1030 for Network Management of TCP/IP-based internets: MIB-II, 1031 Internet Working Group Request for Comments 1213 Network 1032 Information Center, SRI International, Menlo Park, 1033 California, (March, 1991). 1035 [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, 1036 Simple Network Management Protocol, Internet Working 1037 Group Request for Comments 1157. Network Information 1038 Center, SRI International, Menlo Park, California, (May, 1039 1990). 1041 [6] K. McCloghrie and F. Kastenholz, Evolution of the 1042 Interfaces Group of MIB-II, Internet Working Group 1043 Request for Comments 1573. Network Information Center, 1044 SRI International, Menlo Park, California, (Jan, 1994). 1046 [7] Information processing systems -- Open Systems 1047 Interconnection -- Specification of Abstract Syntax 1048 Notation One (ASN.1), International Organization for 1049 Standardization. International Standard 8824, (December, 1050 1987). 1052 [8] Information processing systems -- Open Systems 1053 Interconnection -- Specification of Basic Encoding Rules 1054 for Abstract Notation One (ASN.1), International 1055 Organization for Standardization. International Standard 1056 8825, (December, 1987). 1058 [9] M.T. Rose, K. McCloghrie, Editors, Concise MIB 1059 Definitions, Internet Working Group Request for Comments 1060 1212. Network Information Center, SRI International, 1061 Menlo Park, California, (March, 1991). 1063 [10] M.T. Rose, Editor, A Convention for Defining Traps for 1064 use with the SNMP, Internet Working Group Request for 1065 Comments 1215. Network Information Center, SRI 1066 International, Menlo Park, California, (March, 1991). 1068 Table of Contents 1070 1 Status of this Memo ................................... 1 1071 2 Abstract .............................................. 2 1072 3 Overview .............................................. 3 1073 4 The Network Management Framework ...................... 4 1074 5 Distributed Management Framework ...................... 5 1075 5.1 Known Systems ....................................... 6 1076 5.2 Management Domains .................................. 7 1077 5.3 Management Operations Targets ....................... 7 1078 5.4 Credential Delegation ............................... 7 1079 5.4.1 Definitions ....................................... 8 1080 5.5 Delegation Control .................................. 10 1081 5.6 Scheduling .......................................... 10 1082 5.7 Reliable Notification ............................... 10 1083 5.8 Notification Destinations ........................... 11 1084 6 Acknowledgments ....................................... 24 1085 7 References ............................................ 24