idnits 2.17.1 draft-ietf-disman-framework-00.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 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 513 has weird spacing: '...- Index doma...' == Line 517 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 (December 27, 1996) is 9981 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 912, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 918, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 924, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 929, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 935, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 941, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 946, 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: 17 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Distributed Management Framework 2 4 December 27, 1996 6 Authors: 8 Andy Bierman 9 Cisco Systems 10 abierman@cisco.com 12 Maria Greene 13 Ascom Nexion 14 greene@nexen.com 16 Bob Stewart 17 Cisco Systems 18 bstewart@cisco.com 20 Steve Waldbusser 21 International Network Services (INS) 22 waldbusser@ins.com 24 1. Status of this Memo 26 This document is an Internet-Draft. Internet-Drafts are 27 working documents of the Internet Engineering Task Force 28 (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months. Internet-Drafts may be updated, replaced, or 34 obsoleted by other documents at any time. It is not 35 appropriate to use Internet-Drafts as reference material or to 36 cite them other than as a ``working draft'' or ``work in 37 progress.'' 39 To learn the current status of any Internet-Draft, please 40 check the 1id-abstracts.txt listing contained in the Internet- 41 Drafts Shadow Directories on ds.internic.net, nic.nordu.net, 42 venera.isi.edu, or munnari.oz.au. 44 2. Abstract 46 This memo defines a distributed management architecture for 47 use with the SNMP network management architecture. 49 This memo does not specify a standard for the Internet 50 community. 52 3. Overview 54 Distributed Management is the delegation of control from one 55 management station to another. While the SNMP Network 56 Management Framework does not specifically address distributed 57 management, this function is desired and has been implemented 58 and deployed in the internet using proprietary architectures. 59 It is desired that there be a standard upon which to promote 60 interoperability, as well as a common framework upon which 61 various systems can be built. 63 The goals of distributed management are: 65 o Scalability through Distribution 66 In order to build network management systems that have the 67 power to manage very large networks, it is important that 68 a system not have a single bottleneck point. Therefore, 69 large network management systems must be built as 70 distributed systems. 72 o Disconnected or Low-Bandwidth Operation 73 There are sometimes conditions when a management station 74 will not be in constant contact with all portions of the 75 managed network. This is sometimes by design in an attempt 76 to lower communications costs (especially when 77 communicating over a WAN or dialup link), or by accident 78 as network failures affect the communications between the 79 management station and portions of the managed network. 81 For this reason, a distributed management station will be 82 configured to perform network management functions, even 83 when communication with the management station may not be 84 possible or efficient. The distributed management station 85 may then attempt to notify the management station when an 86 exceptional condition occurs. Thus, even in circumstances 87 where communication with the distributed management 88 station is not continuous, network management operations 89 may run continuously, communicating with the management 90 station conveniently and efficiently, on an as-needed 91 basis. 93 o Mirroring organization boundaries and processes 94 Business organizations are typically set up in a 95 hierarchical fashion. Multiple people in the hierarchy 96 have different roles, responsibilites, and authority. The 97 network management system often has to be configured to 98 match this organization. Distributed network managers can 99 be set up in a hierarchy that matches the roles of various 100 people in the organization. 102 o Promotes a modular system architecture 103 A modular system architecture allows flexibility and re- 104 usability of network management components. A distributed 105 network management system with well-defined interfaces 106 creates this modular scheme. 108 This document defines an architectural framework for 109 standards-based distributed management 111 4. The Network Management Framework 113 A distributed network management station is a management 114 station that receives requests from another manager and 115 executes those requests by performing management operations on 116 agents or other managers. Note that these requests may take a 117 long time to execute, and may be registered indefinitely. 119 With the addition of the distributed network management 120 station, the SNMP Network Management Framework consists of the 121 following entities: 123 A management system contains: several (potentially many) 124 nodes, each with a processing entity, termed an agent, which 125 has access to management instrumentation; at least one 126 management station; and, a management protocol, used to convey 127 management information between the agents and management 128 stations. Operations of the protocol are carried out under an 129 administrative framework which defines authentication, 130 authorization, access control, and privacy policies. 132 Management stations execute management applications which 133 monitor and control managed elements or other (distributed) 134 management stations. A distributed management station is a 135 type of management station that is controlled by another 136 management station. Managed elements are devices such as 137 hosts, routers, terminal servers, etc., which are monitored 138 and controlled via access to their management information. 140 Management information is viewed as a collection of managed 141 objects, residing in a virtual information store, termed the 142 Management Information Base (MIB). Collections of related 143 objects are defined in MIB modules. These modules are written 144 using a subset of OSI's Abstract Syntax Notation One (ASN.1) 145 [1], termed the Structure of Management Information (SMI) [2]. 147 The management protocol, SNMPv2 [3], provides for the exchange 148 of messages which convey management information between the 149 agents and the management stations. It is the purpose of this 150 document to define managed objects which describe the behavior 151 of a SNMPv2 entity. 153 5. Distributed Management Framework 155 The distributed management framework consists of applications 156 and services. 158 A distributed management application performs some management 159 function, often by monitoring and controlling managed 160 elements. These applications perform functions such as 161 threshold polling, historical data polling, or discovery. The 162 specifications and communications protocols of some of these 163 applications will be defined by standards, while others will 164 be enterprise specific. 166 Distributed management services are a collection of services 167 that make up the run-time environment for the distributed 168 management application. These services are crucial to ensuring 169 the usability, scalability, and efficiency of the distributed 170 management applications that depend on them. Some of these 171 services are mandatory, while others are optional. Further, 172 even the mandatory services allow varying depths of support, 173 as described further, below. 175 Each of these services is made available through a MIB 176 interface. 178 The purpose of these services is to provide true enterprise 179 management that allows distributed management functions to be 180 used on an enterprise-wide basis without undue amounts of 181 administrative difficulty. These services also make a set of 182 applications more efficient because the service can perform 183 functions or store information once for all applications on 184 the local system. Further, less work is required to be put 185 into writing the application because some of the core 186 functions are performed elsewhere. 188 5.1. Known Systems 190 The Known Systems service provides a list of all systems which 191 the distributed management system knows about and is prepared 192 to perform management operations upon. This list may be 193 populated by a continuously-running auto-discovery process, it 194 may be populated with SNMP SET requests, or it may be a static 195 list dictated by the system. 197 This service also stores type and attribute information for 198 each of the known systems. 200 The purpose of this service is to allow a management 201 application to be executed on a list of systems so that true 202 enterprise management is possible rather than more ad-hoc 203 management functions. Further, the targets of management 204 applications can be configured separately from the 205 applications to reduce administrative burden as the list of 206 known systems changes. 208 An example of a known systems list is a list of all systems at 209 a site discovered by the autodiscovery module, along with 210 various addressing, type, and attribute information for each. 212 5.2. Management Domains 214 The Management Domains service provides a list of known 215 systems which is a subset of the entire list of known systems. 216 The subset is defined by a rule, or filter, which selects only 217 the known systems that match or those that don't match certain 218 criteria. 220 These domains are multiple, potentially overlapping, sets of 221 devices based on (human) organizational boundaries that define 222 the extents over which management operations should be 223 performed. 225 The purpose of this service is to allow a management 226 application to be executed on a list of known systems within a 227 particular domain. Further, as the domains change over time, 228 the application will automatically be kept up to date and will 229 only monitor the correct systems. 231 An example of a management domain is the subset of all known 232 systems that is on the engineering LAN. 234 5.3. Management Operations Targets 236 The Management Operations Targets service provides a list of 237 known systems in a set of domains that match certain criteria 238 that indicate that it makes sense to perform a particular 239 management function on them. 241 The purpose of this service is to direct management operations 242 to be performance only on those systems where that operation 243 would make sense. Because this is described as a filter, there 244 are no static configuration requirements that would be 245 unacceptable in a dynamically changing network environment. 247 An example of a management operation target list is the subset 248 of all known routers on the engineering LAN. 250 5.4. Delegation Control 252 The Delegation Control Service provides functions that limit 253 the resource usage of a distributed management application 254 that has had control delegated to it. 256 Network management applications are often responsible for 257 adding stress on the network and causing problems. Examples 258 are excessive polling load on slow-speed networks or on router 259 CPUs. This problem will become even more dangerous when 260 network management functions are delegated to distributed 261 management stations. 263 Policies need to be configured that limit average and burst 264 polling, notification, and broadcast rates. These rates may 265 be defined for the sending system as a whole, per end node, or 266 per management application on the sending system. 268 It is also important to have a "Deadman's switch" so that 269 delegated applications will not continue indefinitely if their 270 "sponsor" has forgotten about them. 272 5.5. Scheduling 274 The Scheduling Service allows the execution of distributed 275 management applications to be controlled so that they run at a 276 particular time, periodically, or based on the occurance of 277 another event. 279 5.6. Reliable Notification 281 The Reliable Notification Service provides services that 282 ensure that notifications are received correctly. 284 For example, all the information that describes an event may 285 not fit within a single PDU, so an eventID varbind is defined 286 that associates multiple PDU's as describing the same event. 287 It is also necessary to know if the entire notification has 288 been received or if more PDU's are still outstanding. 290 Further, a receiving management station must be given more 291 information so that it can distinguish duplicated inform PDU's 292 because events are not idempotent. No rule makes it mandatory 293 for the requestID to be unique for all PDUs sent from a 294 system. 296 In addition, a logging mechanism provides for retrieval of 297 notifications after a communications failure. 299 5.7. Notification Destinations 301 The Notification Destination Service provides services for 302 configuring destinations for notifications. 304 When management functions are delegated and MLMs are given the 305 autonomy to generate notifications, they need to be configured 306 as to where the notifications should be sent. Additionally, 307 retry counts and numbers need to be configured. Average and 308 burst notification rates need to be defined. 310 -- Remove hacks for Unsigned32 and BITS datatypes. I need these because 311 -- my version of SMIC is RFC1442 compliant, not RFC1902. 313 DISMAN-SERVICES-MIB DEFINITIONS ::= BEGIN 315 IMPORTS 316 MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, zeroDotZero, 317 NOTIFICATION-TYPE, Counter32, Gauge32, Counter64 -- , Unsigned32, BITS 318 FROM SNMPv2-SMI 319 TEXTUAL-CONVENTION, AutonomousType, DisplayString, DateAndTime, 320 RowStatus, TDomain, TimeStamp, TestAndIncr 321 FROM SNMPv2-TC 322 snmpUDPDomain 323 FROM SNMPv2-TM 324 MODULE-COMPLIANCE, OBJECT-GROUP 325 FROM SNMPv2-CONF 326 OwnerString 327 FROM RMON-MIB 328 ; 330 dismanMIB MODULE-IDENTITY 331 LAST-UPDATED "9612221200Z" 332 ORGANIZATION "IETF Distributed Management Working Group" 333 CONTACT-INFO 334 "Working group mailing list: disman@nexen.com" 335 DESCRIPTION 336 "The MIB module containing SNMP variables for controlling 337 distributed managers." 338 -- Get real experimental number from IANA. 339 -- ::= { experimental XX } 340 ::= { experimental 1 } 342 -- Hack to deal with a RFC1442 version of MIB compiler instead of 343 -- RFC1902. 344 Unsigned32 ::= Counter32 346 --**************************************************************** 347 -- Textual Conventions 348 --**************************************************************** 350 ElementName ::= TEXTUAL-CONVENTION 351 STATUS current 352 DESCRIPTION 353 "A string that uniquely identifies a management element which 354 may be a system or a collection of systems." 355 SYNTAX DisplayString (SIZE (1..64)) 357 IANAAddrFamily ::= TEXTUAL-CONVENTION 358 STATUS current 359 DESCRIPTION 360 "An address family. Values are defined in Assigned Numbers, 361 RFC1700. Note that not all these values make sense in all 362 contexts where this type is used in this MIB, but they are 363 included for completeness." 364 REFERENCE 365 "Assigned Numbers, RFC1700, ADDRESS FAMILY NUMBERS" 366 SYNTAX INTEGER { 367 other(0), 368 ipV4(1), 369 ipV6(2), 370 nsap(3), 371 hdlc(4), 372 bbn1822(5), 373 ieee802(6), 374 e163(7), 375 e164(8), 376 f69(9), 377 x121(10), 378 ipx(11), 379 appleTalk(12), 380 decnetIV(13), 381 banyanVines(14), 382 e164WithNsap(15) 383 } 385 GenAddr ::= TEXTUAL-CONVENTION 386 STATUS current 387 DESCRIPTION 388 "The value of an address." 389 SYNTAX OCTET STRING (SIZE (0..60)) 391 --**************************************************************** 392 -- Managed Object definitions 393 --**************************************************************** 395 mgmtObjects OBJECT IDENTIFIER ::= { dismanMIB 1 } 396 mgmtGeneralObjects OBJECT IDENTIFIER ::= { mgmtObjects 1 } 398 mgmtLock OBJECT-TYPE 399 SYNTAX TestAndIncr 400 MAX-ACCESS read-write 401 STATUS current 402 DESCRIPTION 403 "An advisory lock for all writable objects in the entire 404 Distributed Management Services MIB." 406 ::= { mgmtGeneralObjects 1 } 408 mgmtOwner OBJECT-TYPE 409 SYNTAX OwnerString 410 MAX-ACCESS read-write 411 STATUS current 412 DESCRIPTION 413 "The manager entity that 'owns' this distributed manager's 414 configuration." 415 ::= { mgmtGeneralObjects 2 } 417 mgmtAdminStatus OBJECT-TYPE 418 SYNTAX INTEGER { 419 enabled(1), 420 disabled(2), 421 disabledReset(3) 422 } 423 MAX-ACCESS read-write 424 STATUS current 425 DESCRIPTION 426 "The desired status of this distributed manager. The value 427 'enabled(1)' indicates the distributed manager should be 428 active. The value 'disabled(2)' indicates that the desired 429 operational status is also 'disabled(2)'. A top-level manager 430 may disable a distributed manager in order to change its 431 configuration and have the changes take effect all at once or 432 it may keep the distributed manager disabled as a redundant or 433 back-up manager. The value 'disabledReset(3)' is used to 434 disable a distributed manager and simultaneously remove all 435 entries from its DISMAN MIB tables that support row 436 creation. This allows the top-level manager to put the 437 distributed manager into a known state before downloading a 438 new configuration." 439 ::= { mgmtGeneralObjects 3 } 441 mgmtOperStatus OBJECT-TYPE 442 SYNTAX INTEGER { 443 enabled(1), 444 disabled(2) 445 } 446 MAX-ACCESS read-only 447 STATUS current 448 DESCRIPTION 449 "The actual status of this distributed manager." 450 ::= { mgmtGeneralObjects 4 } 452 mgmtStatusLastChange OBJECT-TYPE 453 SYNTAX TimeStamp 454 MAX-ACCESS read-only 455 STATUS current 456 DESCRIPTION 457 "The value of sysUpTime the last time mgmtOperStatus changed 458 value." 459 ::= { mgmtGeneralObjects 5 } 461 -- 462 -- Managed Element Services 463 -- 464 -- In order for a distributed management application to use these 465 -- managemed element services, it must specify both a domain rule index 466 -- and a target rule index. For example, the trivial application below 467 -- would simply return the values of the systems identified by a 468 -- particular domain rule index and target rule index. 469 -- 470 -- testAppEntry ::= SEQUENCE { 471 -- testAppIndex Integer32, # INDEX 472 -- testAppDomainIndex Integer32, 473 -- testAppTargetIndex Integer32, 474 -- testAppRowStatus RowStatus 475 -- } 476 -- 477 -- testAppResultsEntry ::= SEQUENCE { 478 -- # Indexed by { testAppIndex, testAppResultsIndex } 479 -- testAppResultsIndex Integer32, 480 -- testAppResultsSystemName ElementName 481 -- } 482 -- 483 -- 484 -- An example distributed management system might contain: 485 -- 486 -- mgmtKnownSystemTable 487 -- Name DateTime Algorithm ManualDomain SystemID 488 -- router1 ... ... ... acme5000 489 -- router2 ... ... ... acme3000 490 -- router3 ... ... ... acme5000 491 -- 492 -- mgmtSysAccessTable 493 -- Name Index AddrType Addr SNMPPort AuthString RowStatus 494 -- router1 1 IP 1.1.1.1 161 ... active 495 -- router1 2 IP 1.1.2.1 161 ... active 496 -- router2 3 IP 1.1.1.5 161 ... active 497 -- router3 4 IP 1.1.1.4 161 ... active 498 -- router3 5 IP 1.1.4.9 161 ... active 499 -- 500 -- mgmtRuleTable 501 -- Index Name RowStatus 502 -- 1 "Finance" active 503 -- 2 "Acme 5000" active 504 -- 505 -- mgmtRuleFilterTable 506 -- Index FilterIndex Type Filter RowStatus 507 -- 1 1 matchAddress "^1.1.2" active 508 -- 1 2 matchAddress "^1.1.4" active 509 -- # Rule 1 matches all hosts on subnet 2 and subnet 4 510 -- 2 3 matchSystemID "acme5000" active 511 -- 512 -- testAppTable 513 -- Index domainIndex targetIndex RowStatus 514 -- 1 1 2 active 515 -- 516 -- testAppResultsTable 517 -- Index ResultsIndex systemName 518 -- 1 1 "router1" 519 -- 1 2 "router3" 520 -- 521 -- If this was a script application, the script would execute on 522 -- router1 and router3. 524 mgmtElementObjects OBJECT IDENTIFIER ::= { mgmtObjects 3 } 526 -- 527 -- The Known System Table 528 -- 530 mgmtKnownSystemTable OBJECT-TYPE 531 SYNTAX SEQUENCE OF MgmtKnownSystemEntry 532 MAX-ACCESS not-accessible 533 STATUS current 534 DESCRIPTION 535 "A table of all known systems that are potential management 536 targets." 537 ::= { mgmtElementObjects 1 } 539 mgmtKnownSystemEntry OBJECT-TYPE 540 SYNTAX MgmtKnownSystemEntry 541 MAX-ACCESS not-accessible 542 STATUS current 543 DESCRIPTION 544 "Information about a single management system. While most 545 known systems will usually be populated by the agent, new 546 systems can be created using the mgmtKnownSystemRowStatus 547 variable." 548 INDEX { IMPLIED mgmtKnownSystemName } 549 ::= { mgmtKnownSystemTable 1 } 551 MgmtKnownSystemEntry ::= SEQUENCE { 552 mgmtKnownSystemName ElementName, 553 mgmtKnownSystemDateTimeCreated DateAndTime, 554 mgmtKnownSystemAlgorithm AutonomousType, 555 mgmtKnownSystemManualDomain OCTET STRING, 556 mgmtKnownSystemID AutonomousType, 557 mgmtKnownSystemRowStatus RowStatus 558 } 560 mgmtKnownSystemName OBJECT-TYPE 561 SYNTAX ElementName 562 MAX-ACCESS not-accessible 563 STATUS current 564 DESCRIPTION 565 "The name of the element. If this record is created automatically 566 (e.g., as part of a discovery process), this name can be 567 algorithmically assigned using any algorithm that guarantees 568 uniqueness. It is recommended that this value be human readable, 569 and for that reason an ascii representation of the address is 570 often suitable in cases where more detail is not known." 571 ::= { mgmtKnownSystemEntry 1 } 573 mgmtKnownSystemDateTimeCreated OBJECT-TYPE 574 SYNTAX DateAndTime 575 MAX-ACCESS read-only 576 STATUS current 577 DESCRIPTION 578 "The date and time when this object was added to the distributed 579 managers database." 580 ::= { mgmtKnownSystemEntry 2 } 582 mgmtKnownSystemAlgorithm OBJECT-TYPE 583 SYNTAX AutonomousType 584 MAX-ACCESS read-only 585 STATUS current 586 DESCRIPTION 587 "The method used to create this entry. The value { 0 0 } (a 588 NULL object identifier) indicates that the entry was added 589 'manually' via the table's RowStatus column. Other values may 590 indicate various discovery algorithms." 591 DEFVAL { zeroDotZero } 592 ::= { mgmtKnownSystemEntry 3 } 594 mgmtKnownSystemManualDomain OBJECT-TYPE 595 SYNTAX OCTET STRING 596 MAX-ACCESS read-create 597 STATUS current 598 DESCRIPTION 599 "A bit mask of domains the system is a member of. Every 1 bit 600 in this string indicates that this system is a part of the 601 domain who's rule index is equal to the bit position of the 602 bit. The first bit in the string is equal to the rule index 603 of 1. If this object indicates that a system is part of a 604 domain, it is understood to be part of that domain no matter 605 what the rule set is for the domain (i.e. domain membership is 606 an OR function of this object and the domain rules). 608 This object only has an effect on rules that are used as 609 domains. In particular this means that if a bit is set for a 610 rule and that rule is used as a target, the bit will have no 611 effect." 612 ::= { mgmtKnownSystemEntry 4 } 614 mgmtKnownSystemID OBJECT-TYPE 615 SYNTAX AutonomousType 616 MAX-ACCESS read-create 617 STATUS current 618 DESCRIPTION 619 "The type of the system. This will typically be 620 the same value as the sysObjectID for the system. 621 The value zeroDotZero indicates an unknown type." 622 DEFVAL { zeroDotZero } 623 ::= { mgmtKnownSystemEntry 5 } 625 mgmtKnownSystemRowStatus OBJECT-TYPE 626 SYNTAX RowStatus 627 MAX-ACCESS read-create 628 STATUS current 629 DESCRIPTION 630 "The control that allows creation/deletion of system entries." 631 ::= { mgmtKnownSystemEntry 6 } 633 -- 634 -- The System Management Access Table 635 -- 637 mgmtSysAccessTable OBJECT-TYPE 638 SYNTAX SEQUENCE OF MgmtSysAccessEntry 639 MAX-ACCESS not-accessible 640 STATUS current 641 DESCRIPTION 642 "A table of access information for the management entities 643 (either SNMP managers or SNMP agents) running on systems." 644 ::= { mgmtElementObjects 2 } 646 mgmtSysAccessEntry OBJECT-TYPE 647 SYNTAX MgmtSysAccessEntry 648 MAX-ACCESS not-accessible 649 STATUS current 650 DESCRIPTION 651 "Information about a single management entity." 652 INDEX { mgmtKnownSystemName, mgmtSysAccessIndex } 653 ::= { mgmtSysAccessTable 1 } 655 MgmtSysAccessEntry ::= SEQUENCE { 656 mgmtSysAccessIndex Integer32, 657 mgmtSysAccessAddrType IANAAddrFamily, 658 mgmtSysAccessAddr GenAddr, 659 mgmtSysAccessSNMPPort Integer32, 660 mgmtSysAccessAuthString OCTET STRING, 661 mgmtSysAccessRowStatus RowStatus 662 } 664 mgmtSysAccessIndex OBJECT-TYPE 665 SYNTAX Integer32 666 MAX-ACCESS not-accessible 667 STATUS current 668 DESCRIPTION 669 "An index number for the access information so that the agent 670 can keep track of multiple managers and multiple agents 671 running on the same system (presumably at different transport 672 addresses.)" 673 ::= { mgmtSysAccessEntry 1 } 675 mgmtSysAccessAddrType OBJECT-TYPE 676 SYNTAX IANAAddrFamily 677 MAX-ACCESS read-create 678 STATUS current 679 DESCRIPTION 680 "The type of the address identified by mgmtSysAccessAddr." 681 DEFVAL { ipV4 } 682 ::= { mgmtSysAccessEntry 2 } 684 mgmtSysAccessAddr OBJECT-TYPE 685 SYNTAX GenAddr 686 MAX-ACCESS read-create 687 STATUS current 688 DESCRIPTION 689 "The management address for the manager or agent. A 690 zero-length string indicates an unknown address." 691 DEFVAL { ''H } 692 ::= { mgmtSysAccessEntry 3 } 694 mgmtSysAccessSNMPPort OBJECT-TYPE 695 SYNTAX Integer32 696 MAX-ACCESS read-create 697 STATUS current 698 DESCRIPTION 699 "The port for an SNMP agent on this system." 700 DEFVAL { 161 } 701 ::= { mgmtSysAccessEntry 4 } 703 mgmtSysAccessAuthString OBJECT-TYPE 704 SYNTAX OCTET STRING 705 MAX-ACCESS read-create 706 STATUS current 707 DESCRIPTION 708 "Authentication information for accessing this system at this port." 709 ::= { mgmtSysAccessEntry 5 } 711 mgmtSysAccessRowStatus OBJECT-TYPE 712 SYNTAX RowStatus 713 MAX-ACCESS read-create 714 STATUS current 715 DESCRIPTION 716 "A control that allows creation/deletion of system management 717 entity entries." 718 ::= { mgmtSysAccessEntry 6 } 719 -- 720 -- Rules 721 -- 722 mgmtRuleTable OBJECT-TYPE 723 SYNTAX SEQUENCE OF MgmtRuleEntry 724 MAX-ACCESS not-accessible 725 STATUS current 726 DESCRIPTION 727 "A table of rules. 729 A rule is a set of filters by which a list of systems can be 730 selected from a larger list, based on a match of one or more 731 filters. 733 Rules are used in 2 contexts, to select a domain, or to 734 select managed operations targets. A domain defines those 735 systems within a particular organizational boundary within 736 which certain operations should be performed. A set of 737 management operations targets is a subset of a domain that 738 restricts an operation to only those systems upon which the 739 operation `makes sense'. Domain rules are distinguishable from 740 target rules only by the context in which they are 741 used. However, in general, it is not useful to use a filter 742 designed to select a target in the context of a domain, or 743 vice versa. 745 A system matches a rule if it was part of the appropriate 746 input set (ALL, or member of a domain), and one or more 747 ruleFilters evaluates to true for the system." 748 ::= { mgmtElementObjects 3 } 750 mgmtRuleEntry OBJECT-TYPE 751 SYNTAX MgmtRuleEntry 752 MAX-ACCESS not-accessible 753 STATUS current 754 DESCRIPTION 755 "Information about a single rule. New rules 756 can be created using the mgmtRuleRowStatus variable." 757 INDEX { mgmtRuleIndex } 758 ::= { mgmtRuleTable 1 } 760 MgmtRuleEntry ::= SEQUENCE { 761 mgmtRuleIndex Integer32, 762 mgmtRuleName DisplayString, 763 mgmtRuleRowStatus RowStatus 764 } 766 mgmtRuleIndex OBJECT-TYPE 767 SYNTAX Integer32 (1..2147483647) 768 MAX-ACCESS not-accessible 769 STATUS current 770 DESCRIPTION 771 "A unique index for this rule." 772 ::= { mgmtRuleEntry 1 } 774 mgmtRuleName OBJECT-TYPE 775 SYNTAX DisplayString 776 MAX-ACCESS read-create 777 STATUS current 778 DESCRIPTION 779 "A human readable name for this rule. This name 780 should describe the purpose/scope of the rule, for 781 example `Headquarters' or `Acme Routers'." 782 ::= { mgmtRuleEntry 2 } 784 mgmtRuleRowStatus OBJECT-TYPE 785 SYNTAX RowStatus 786 MAX-ACCESS read-create 787 STATUS current 788 DESCRIPTION 789 "The control that allows creation/deletion of rule entries." 790 ::= { mgmtRuleEntry 3 } 792 mgmtRuleFilterTable OBJECT-TYPE 793 SYNTAX SEQUENCE OF MgmtRuleFilterEntry 794 MAX-ACCESS not-accessible 795 STATUS current 796 DESCRIPTION 797 "A table of filters for a rule. 799 If this filter is executed in the context of a domain, it 800 selects a subset of all of the systems in the 801 mgmtKnownSystemTable. If this filter is executed in the 802 context of a target, it selects a subset of all systems 803 matched by the associated domain rule. 805 If a rule has multiple filters, the rule selects the union of 806 all systems selected by the filters." 807 ::= { mgmtElementObjects 4 } 809 mgmtRuleFilterEntry OBJECT-TYPE 810 SYNTAX MgmtRuleFilterEntry 811 MAX-ACCESS not-accessible 812 STATUS current 813 DESCRIPTION 814 "Information about a single filter. New filters 815 can be created using the mgmtRuleFilterRowStatus variable. 816 A row can only be created if it contains a value of 817 mgmtRuleIndex that already exists. Further, if a 818 mgmtRuleIndex is deleted from the mgmtRuleTable, all 819 associated entries shall be deleted from the 820 mgmtRuleFilterTable." 821 INDEX { mgmtRuleIndex, mgmtRuleFilterIndex } 822 ::= { mgmtRuleFilterTable 1 } 824 MgmtRuleFilterEntry ::= SEQUENCE { 825 mgmtRuleFilterIndex Integer32, 826 mgmtRuleFilterType INTEGER, 827 mgmtRuleFilter DisplayString, 828 mgmtRuleFilterRowStatus RowStatus 829 } 831 mgmtRuleFilterIndex OBJECT-TYPE 832 SYNTAX Integer32 833 MAX-ACCESS not-accessible 834 STATUS current 835 DESCRIPTION 836 "A unique index for this rule." 837 ::= { mgmtRuleFilterEntry 1 } 839 mgmtRuleFilterType OBJECT-TYPE 840 SYNTAX INTEGER { 841 matchAddress(1), 842 matchDomainName(2), 843 matchSystemID(3) 844 } 845 MAX-ACCESS read-create 846 STATUS current 847 DESCRIPTION 848 "If this object has the value `matchAddress(1)', the ascii 849 representation (TBD) of each address in the mgmtSysAccessTable 850 will be evaluated against the regular expression in the 851 associated mgmtRuleFilter object. If the match succeeds, the 852 system associated with the mgmtSysAccessEntry matches this 853 filter. 855 If this object has the value `matchDomainName(2)', the domain 856 name of each address in the mgmtSysAccessTable 857 will be evaluated against the regular expression in the 858 associated mgmtRuleFilter object. If the match succeeds, the 859 system associated with the mgmtSysAccessEntry matches this 860 filter. 862 If this object has the value `matchSystemID(1)', the ascii 863 representation (TBD) of each mgmtKnownSystemID 864 will be evaluated against the regular expression in the 865 associated mgmtRuleFilter object. If the match succeeds, the 866 system associated with the mgmtKnownSystemID matches this 867 filter." 868 ::= { mgmtRuleFilterEntry 2 } 870 mgmtRuleFilter OBJECT-TYPE 871 SYNTAX DisplayString 872 MAX-ACCESS read-create 873 STATUS current 874 DESCRIPTION 875 "The value matched against systems for this filter." 876 ::= { mgmtRuleFilterEntry 3 } 878 mgmtRuleFilterRowStatus OBJECT-TYPE 879 SYNTAX RowStatus 880 MAX-ACCESS read-create 881 STATUS current 882 DESCRIPTION 883 "The control that allows creation/deletion of RuleFilter 884 entries." 885 ::= { mgmtRuleFilterEntry 4 } 886 END 888 6. Acknowledgments 890 This document was produced by the IETF Distributed Network 891 Management Working Group. 893 7. References 895 [1] V. Cerf, IAB Recommendations for the Development of 896 Internet Network Management Standards. Internet Working 897 Group Request for Comments 1052. Network Information 898 Center, SRI International, Menlo Park, California, 899 (April, 1988). 901 [2] V. Cerf, Report of the Second Ad Hoc Network Management 902 Review Group, Internet Working Group Request for Comments 903 1109. Network Information Center, SRI International, 904 Menlo Park, California, (August, 1989). 906 [3] M.T. Rose and K. McCloghrie, Structure and Identification 907 of Management Information for TCP/IP-based internets, 908 Internet Working Group Request for Comments 1155. 909 Network Information Center, SRI International, Menlo 910 Park, California, (May, 1990). 912 [4] K. McCloghrie and M.T. Rose, Management Information Base 913 for Network Management of TCP/IP-based internets: MIB-II, 914 Internet Working Group Request for Comments 1213 Network 915 Information Center, SRI International, Menlo Park, 916 California, (March, 1991). 918 [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, 919 Simple Network Management Protocol, Internet Working 920 Group Request for Comments 1157. Network Information 921 Center, SRI International, Menlo Park, California, (May, 922 1990). 924 [6] K. McCloghrie and F. Kastenholz, Evolution of the 925 Interfaces Group of MIB-II, Internet Working Group 926 Request for Comments 1573. Network Information Center, 927 SRI International, Menlo Park, California, (Jan, 1994). 929 [7] Information processing systems -- Open Systems 930 Interconnection -- Specification of Abstract Syntax 931 Notation One (ASN.1), International Organization for 932 Standardization. International Standard 8824, (December, 933 1987). 935 [8] Information processing systems -- Open Systems 936 Interconnection -- Specification of Basic Encoding Rules 937 for Abstract Notation One (ASN.1), International 938 Organization for Standardization. International Standard 939 8825, (December, 1987). 941 [9] M.T. Rose, K. McCloghrie, Editors, Concise MIB 942 Definitions, Internet Working Group Request for Comments 943 1212. Network Information Center, SRI International, 944 Menlo Park, California, (March, 1991). 946 [10] M.T. Rose, Editor, A Convention for Defining Traps for 947 use with the SNMP, Internet Working Group Request for 948 Comments 1215. Network Information Center, SRI 949 International, Menlo Park, California, (March, 1991). 951 Table of Contents 953 1 Status of this Memo ................................... 1 954 2 Abstract .............................................. 2 955 3 Overview .............................................. 3 956 4 The Network Management Framework ...................... 4 957 5 Distributed Management Framework ...................... 5 958 5.1 Known Systems ....................................... 6 959 5.2 Management Domains .................................. 6 960 5.3 Management Operations Targets ....................... 7 961 5.4 Delegation Control .................................. 7 962 5.5 Scheduling .......................................... 8 963 5.6 Reliable Notification ............................... 8 964 5.7 Notification Destinations ........................... 8 965 6 Acknowledgments ....................................... 21 966 7 References ............................................ 21