Snmpconf Working Group M. MacFaden Category: Best Current Practice Riverstone Networks, Inc J. Saperia JDS Consulting, Inc W. Tackabury Gold Wire Technology, Inc Configuring Networks and Devices With SNMP draft-ietf-snmpconf-bcp-03.txt November 21, 2000 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document is for a variety of readers interested in the Internet Standard Management Framework for the Simple Network MacFaden et al Expires May 2001 [Page 1] Internet Draft SNMP Configuration November 2000 Management Protocol[SNMP]. In particular, it offers guidance in the SNMP usage for effective configuration management. This information is relevant to vendors that build network elements, third party application developers, and those that acquire and deploy this technology in their networks. This document is still very much a work in progress. Community input is solicited. 1. INTRODUCTION Data networks have grown greatly in size and complexity over the past decade. Configuration of network elements is an essential prerequisite to the deployment of services on those networks. Such configuration requirements have grown more complex over time as a result of serveral dynamics: Scale - Data networks have scaled in many dimenstions: they have more network elements, the network elements are larger and they have many more interrelationships. Functionality - network devices perform more functions. More protocols and network layers are required for the successful deployment of a wide array of network services. The Internet Standard Management Framework is used successfully to develop configuration management systems for a broad range of devices. This document describes Best Current Practices [BCP] that should be used when designing an effective SNMP-based management system that includes configuration operations. In addition to individual element management, the SNMP can be used to configure groups of devices based on a set of rules or desired states, what has come be know as policy management. A great deal of attention has been placed on policy based configuration management over the past few months as a result of the factors described above. This document also includes recommendations for policy based configuration. Policy Based Configuration Management can be defined as a configuration operations distributed to potentially many network elements with the goal of achieving consistent network behavior throughout a given autonomous system AS[21]. MacFaden et al Expires May 2001 [Page 2] Internet Draft SNMP Configuration November 2000 This document draws on experience provisioning public and private data networks over the deployment history of SNMP. Over that same time-period, significant experience has been gained in the development and deployment of SNMP based management software, some of which also performs configuration functions. 1.1. Document Organization The next section describes a typical procedural model for how experienced operations staff generally practice configuration of TCP/IP networks. Section 3 describes a reference model for how management data is modeled and presented particularly for the benefit of the application or manager performing the configuration. Section 4 describes required background issues in using SNMP for configuration, particularly with respect to transactional control. Section 5 discusses known practices in using SNMP for configuration, where these practices show up in MIB module design and interpretation (5.1) and in management application design (5.2). Section 6 describes the current state of the art in policy-based management, and how that concept affects SNMP-based configuration. Section 7 provides the complete specification of an example MIB module used throughout section 5. 2. CONFIGURATION REFERENCE MODEL A goal of management data modeling is to represent configuration and management information at the appropriate level of abstraction to make it easier for operators to configure elements without necessarily knowing the details of each device. Lower (more detailed) level detail can facilitate fault resolution and performance management. Part of the function of the management station software as well as software that executes inside the network elements is to transform these different levels of abstraction into a form the equipment can use. The following terms define the dimensions of abstraction in a configuration model. This model, MacFaden et al Expires May 2001 [Page 3] Internet Draft SNMP Configuration November 2000 and its related abstraction level, will be referenced throughout the remainder of this document. Domain-Specific A domain is a general area of technology such as service quality or security. Services, or service level agreements, may span several domains, each of them potentially including many policies. As a general rule, people will not discuss these domains in the abstract. They will most often be discussed with technology or application-specific examples. Examples of technical domains include, IPSec and Differentiated Services. When expressed in terms specific to a particular domain, a policy is said to be at the Domain Specific level of detail. Mechanism-Specific Mechanisms are technologies used within a particular domain. For example, in the differentiated services domain, RED (Random Early Detection) or WRED (Weighted Random Early Detection) might be used as one of the mechanisms that devices employ to realize a traffic conditioner called a Dropper in differentiated services DS[28] and the applications on which they rely. Policy descriptions that include the details associated with a particular mechanism, are said to be mechanism-specific. Implementation-Specific Implementation-specific details are those parameters that a particular vendor might use in an implementation that augment a standard set of mechanism-specific parameters. Vendors often add special capabilities to basic mechanisms as a way of meeting special customer requirements or differentiating themselves from their competitors. These special capabilities are often a result of the implementation approach that a vendor has used for the product, thus the term "implementation-specific". For example, if a router vendor implemented a particular routing protocol, they would have the mechanism-specific parameters that control the behavior of that software. The vendor might have chosen to run several instances of that routing protocol, perhaps on different processors, for performance reasons. The parameters that are used to control the distribution of work on the different processors for that protocol would be implementation- MacFaden et al Expires May 2001 [Page 4] Internet Draft SNMP Configuration November 2000 specific. Instance-Specific Network operators are most familiar and comfortable with information of this instance-specific type. Instance-specific information refers to parameter values that have been associated with a specific instance in a managed element. For example, The Border Gateway Protocol is a exterior routing protocol that has a number of parameters that describe information about a particular routers view of other routers that it is sharing information with, peer routers. One such parameter defined in the BGP MIB module BGPMIB[29] is the desired connection retry interval for a peer, bgpPeerConnectRetryInterval. An example value would be 120 (seconds). When expressed with this level of specificity, one would say that this is mechanism-specific data. If we were to see a value of bgpPeerConnectRetryInterval.192.0.2.1 = 120 we would be looking at the retry interval of the peer router found at IP address 192.0.2.1. The value for this instance is 120 seconds, instance-specific data. 3. CONSIDERATIONS FOR SNMP USAGE 3.1. Transactions and SNMP Over the years there has been considerable discussion about SNMP and its historical lack of an explicit transaction control mechanism beyond the PDU and variable binding processing rules of the protocol. While the SNMP SMIv2 added the row status textual convention, many implementations have not made good use of it. Material is presented in this document that provides guidance on how to best make use of the row status textual convention that can be effectively used to provide a wide variety of transaction level controls. That said, a debate about transaction level control at the protocol level often misses the important distinction between information integrity and transaction control. The property of informational integrity [REF] is important and well handled by the SNMP. Informational integrity ensures that the data that is received by an entity is what was sent. Transactional integrity is a crucial component to any aspect MacFaden et al Expires May 2001 [Page 5] Internet Draft SNMP Configuration November 2000 of the control of the configuration of network elements. This is the property of ensuring that a range of configuration commands are treated as an integral unit and that all or none are carried out. To this point, most systems have used the configuration file as the unit of transaction integrity since that was the easiest to control and understand, however; this approach suffers from a number of deficiencies. These include: Poor control for changes that are finer grained than the file level and lack of ability to coordinate changes among several machines as would be desired in a policy-based system. 3.1.1. Practical Requirements for Transactional Control A properly designed and deployed configuration management system should have the following features with regard to transactions and transactional integrity. First, provide for flexible transaction control at many different levels of granularity, within a mechanisim specific (system) and domain specific (group of systems or network). This means whole system updates or any portion thereof. Whole configuration files can be used to achieve some of this but are inefficient, both in terms of the amount of data transmitted as well as in terms of processing overhead on the managed elements. Even where partial configuration files are used, they often cause extra material to be added to the configuration file and thus suffer from some of the same difficulties of whole configuration file updates. The transaction control component should work at any of the levels of abstraction. There is an inherent difficulty in translating the individual changes in files to a form that is usefully represented in a database that would allow for easy incremental rollback or roll-forward operations on a single machine or among many. Allow flexibility in the definition of a successful transaction. This can not be done at the protocol level alone, but must be provided for throughout the application, and the information that is being managed. In the case of SNMP, the information would be in properly defined MIB modules. Expose time-indexed transaction control - For effective rollback control, the configuration transactions and their successful or unsuccessful completion status must be reported by the MacFaden et al Expires May 2001 [Page 6] Internet Draft SNMP Configuration November 2000 managed elements and stored in a repository that supports such time indexing and can record the user that made the change, even if the change was not made on the system recording the change. The managed system must support transactional security. This means that depending on where and who is making the configuration request, it may be accepted or denied based on security policy that is represented in the managed element. It is possible for an SNMP-based management system to effectively address all of these issues. Transactional control is an essential property of a configuration management system consistent with what is presented in this document. Areas in this document that describe how to successfully design, implement and deploy such a system are: Requirement Section ----------- ------- Flexible Transaction Control Transaction Control MIB objects Flexible Transaction Control Configuration Transactions (5.3) Time-indexed Transaction Control Management Station Time 4. OPERATIONAL FUNDAMENTALS 4.1. A Process for Deploying Configuration Data network devices are configured using many mechanisms, however two methods remain the most common: SNMP and Command Line Interface (CLI). Effective use of these mechanisms involves an operational methodology for deploying changes to networks in a cautious and incremental manner with well documented procedures. The collective intent of these procedures is the guarantee that a configuration change to the network has the intended effect on the affected network elements. Here is one such procedural model in detail: Network Scope Input Procedural Step Output ------------------ ----- --------------- ------ Lab isolated from (1) Stage configuration Verify reliability main network change with test of config change device set and MacFaden et al Expires May 2001 [Page 7] Internet Draft SNMP Configuration November 2000 interoperability with prior system versions and backwards compatibility with prior configuration (2) Plan noncritical/ Fall back strategy off hour window in case of change failure Segmented edge of (1),(2) (3) Apply change to CLI Verified device main network of network segment accept of network elements configuration change (3) (4) Observation of Verified device devices/networks over and network time after change stability, proper effect of changes (4) (5) Save changes to Verify integrity persistent storage of changes after of devices device restart Expanded network (2),(5) (6) Deploy changes, Verification of segments, iterative using CLI and SNMP. safety from any to complete network Keep prior unanticipated configuration on some SNMP defaulting devices to allow behavior in mixed fallback in case environment of failure (6) (7) Continue to Checkpointed observe devices and verification network for of anticipated behavioral/service behavior anomalies MacFaden et al Expires May 2001 [Page 8] Internet Draft SNMP Configuration November 2000 (7) (8) Expand deployment Checkpointed and iteration to (6) verification as called for of anticipated behavior Network revision (8) Update archived Change deployment control system configurations, complete. change log. Procedures such as those above bring about a form of operational transactionality, which works along side (and employs) the SNMP transactionality as outlined in [SNMPTRANS]. The key goals throughout are o Transactionality of configuration change deployment o Persistence of configuration change which can be verified for resulting stability, convergence, and realization of intended effect of change. Considerations for bringing about this verification are discussed in the following section. 4.2. Configuration Change Coherency and Verification There are implicit assumptions made about the environement in which configuration changes are made. One common assumption is that a "mere mortal" on the operations staff trained in a given technology should be able to understand a device's state or some logical view of that state. Now surrounding any given subsystem is the configuration mechanism. Training with this component can also impact configuration. Also, both components interact. A classic example, is the operator that becomes concerned at the cpu utilization on a network element as that system is pounded for queries as to the state of cpu utilization is increasingly common. If the configuration mechanism is more complex MacFaden et al Expires May 2001 [Page 9] Internet Draft SNMP Configuration November 2000 than what is generally being configured, it can often obscure what the operator wanted to change. To assist in the verification requirements called for above, a diagnostic mode is often present to deal with specific implementation issues above and beyond the standard set of instrumentation capabilities on affected devices. To verify a configuration change, an operator should have an integrated view of configuration, device status, and diagnostic information. That information would be available both before and after configuration change, regardless of latency involved. Ideally there are a series of tests the operator runs before and after a change is made to an operational network to ensure service remains intact. For example, when configuring a DNS system, the tool nslookup is often used with a script to verify key database entries are present and return the expected values. Configuration change may not be made if pre-configration test results show the change can not be verified. Another example: A change is made to the network and initial review shows that change appears to be successfully implemented, but at some later time, problems begine to occur. Verification of the cause change with SNMP is integrated in that MIB objects not directly used in configuration can be checked to verify configuration. It is extremely important to note that achieving convergence (network stability) in an autonomous system is not guaranteed when configuration changes are made. For example, if changes are made to ospfIfHelloInterval and ospfIfRtrDeadInterval [22] timers in the OSPF routing protocol such that both are set to the same value, two routers may form an adjacency but then begin to cycle: lose adjacency, form adjacency and so on never reach a converged (stable) state. Managed systems under configuration control should be able to cope with unexpected loss communications with a centralized management system. Network elements in conjunction with the configuration mechanism must take appropriate measures to leave the configuration in a consistent/recognizable state by either rolling back to a previously valid state or changing to a well defined or default state. Here then are requirements for a modern configuration protocol. MacFaden et al Expires May 2001 [Page 10] Internet Draft SNMP Configuration November 2000 4.3. Configuration Change Diagnostics Debugging is an integral part of the configuration process. Subsystems should provide self-tests that verify internal state as well as tests to verify external states. When possible the results of a diagnostic test should be exposed through one or more MIB objects. Availability of debug/diagnostic tests that are exposed through MIB modules should be identified and exploited to identify configuration errors. For example, the test/set/test sequence is commonly employed for configuration changes in a production environment. The SNMP is ideal for obtaining status from a change event, including objects not part of the configuation action. Ideally, impact of configuration change on convergence of an existing network whould be specified in the configuration MIB module in a description clause. For example, when changing the cost of of a port via OSPF or STP, does such a change cause the network to destabilize while the change is implemented and protocol updates are sent to other devices. For MIB modules that do not define such attributes, the agent-capabilities MIB could be used to add additional implementation notations. Reporting on the impact of a change via configuration is consistent with "Requirements for IP Version 4 Routers" [20], section 1.3.4: A vendor needs to provide adequate documentation on all configuration parameters, their limits and effects. 5. CONFIGURATION PRACTICE AND SNMP 5.1. Agent Software Development This section describes a number of best current practices by drawing upon a fictional MIB module called ACME-HOUSECTRL-MIB. This MIB can control familiar facilities found in a modern home and is defined in Section 8.0 along with a sample agent capabilities definition. Our discussion need also account for the role of key capabilities in the SNMP such as protocol transactions, security, and error handling in the context of configuration. MacFaden et al Expires May 2001 [Page 11] Internet Draft SNMP Configuration November 2000 What emerges from analysis of the usage of existing and possible MIB modules for which the ACME-HOUSECTRL-MIB can be used as an abstraction are a number of discrete objectives and considerations for MIB module designers. This discussion organizes them around greater containment criteria. 5.1.1. Consistency in Modeling One of the first tasks in defining a MIB module is the creation of a model which reflects the domain-specific or mechanism-specific scope of the management information involved. MIB modules may expose configuration capabilities to a significant degree. There are a variety of considerations in the specification of management objects and specification of how they are accessed, which have proved important in operational experience. 5.1.1.1. Designing Configuration Objects The goal for all MIB modules should be to serve operational purposes. MIB modules can be thought of a models upon some aspect of a subsystem. Chosing those aspects of a subsystem to that are operationally useful. What is operationally useful? Objects that directly control behavior. A given the housecontrol mib, something that performs an operation intended by the user of the system, such as turning on and off a light. What is the right level of granularity? An example of an object that is not or marginally operationally useful might be manipulating voltage and current to the light. If a MIB module used for configuration contains "too many" objects to provision a given facility, then it is likely an abstraction problem. If there are overlapping objects with similar capabilities, then the abstraction may be to blame as well. For example, consider the house control MIB module configuration request to turn on all lights in a house. There may be tens of light circuits in a given single family MacFaden et al Expires May 2001 [Page 12] Internet Draft SNMP Configuration November 2000 home. The MIB module designer might be tempted to create a table with an instance for each lighting group controlled by one more switches and have an object to turn that light group on/off. Yet in considering the request, this would force the application developer to issue sets with an inordinately large number of objects. The MIB module designer might solve this in at least two ways. The first would be to specify an enumeration with specific operations: acmeGlobalHouseOperations OBJECT-TYPE SYNTAX INTEGER { turnOffAllLights (1), turnOnAllLights(2) dimAllLights(3) } ACCESS read-write STATUS mandatory DESCRIPTION "Actions to apply to all Lights in a house." ::= { acmeLightGlobals 2 } However, the ease of adding such an object has the drawback that the relations to other read-create tables for which individual lights suddenly become more complicated. What should happen to read-write objects when all lights are turned using the above object is not clearly spelled out. Exception cases are then created and an application would have to poll all objects correctly to obtain the current state of lights. The second approach is to make the general command more powerful. acmeLightGlobalHouseAction OBJECT-TYPE SYNTAX INTEGER { turnOn(1), turnOff(2), dim(3) } ACCESS read-write STATUS mandatory DESCRIPTION "Actions to apply to the lights enumerated in acmeLightGlobalHouseArgument." ::= { acmeLightEntry 2 } MacFaden et al Expires May 2001 [Page 13] Internet Draft SNMP Configuration November 2000 acmeLightGlobalHouseArgument OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "A bitwise encoding of indices into the light Table for which a given Action will be applied to." ::= { acmeLightEntry 3 } This solution makes interpreting what the original request was much easier, but not what the current state of all the light-groups currently are. If a history is needed of what commands were sent, this table can record this aspect as well. As a practical matter for most deployed MIB modules, retrieving a consistent configuration remains problematic from most SNMP agents that implement those MIBs. The protocol framework provides no way to retrieve a configuration with out knowing in advance which objects to get. A solution that records every object using the get-next operator reaches a point of diminishing returns scaling to large numbers of objects and instances in an agent. 5.1.1.2. Summary Objects and State Tracking It is generally important to track changes to a device and to synchronize the changes with some specific configuration repository. Availability of summary status objects (or "dummy lights") provides simple and quick means to determine overall configuration-state of a subsystem. For example, checksums or configuration version ids could be computed over a configuration so that an application can reasonably identify an entire configuration instead of having to poll many "LastChange" objects or have to use TimeFilter style indexing to achieve highly efficient polling of large tables as found in RFC 2674 and RFC 2021. The ACME-HOUSECTL-MIB contains the following definitions: AcmeCfgVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION MacFaden et al Expires May 2001 [Page 14] Internet Draft SNMP Configuration November 2000 "A value that starts at 0 and increases monotonically until the max value is reached at which point the value returns to 0." SYNTAX Gauge32 acmeSysActiveConfigId OBJECT-TYPE SYNTAX AcmeCfgVersion MAX-ACCESS read-write STATUS current DESCRIPTION "Current value of configuration information. This value remains persistent across reboots and increases when configuration changes are made to any object in this MIB." ::= { acmeHouseGlobals 3 } If defined managed objects have state which changes on the order of seconds the abstraction for configuration is not ideal. Notifications to communicate the state of a rapid changing object also would not be ideal. 5.1.1.3. Object Semantic Overlap Avoidance MIB module designers should generally avoid specifying read-write objects that overlap or activate potentially a similar instance in another MIB module. Such interdependencies can lead to potential ambiguity. Yet defining managed objects that overlap may appear as a convenience, such as enabling different indexing schemes, the side effects may from the usage of the two overlapping object may not be easily discernible. For example, in the ACME-HOUSECTL-MIB, a designer might have designed the following two objects at different times: acmeWaterHeaterPilot OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The current state of the pilot light." ::= { acmeWaterHeaderEntry 4 } MacFaden et al Expires May 2001 [Page 15] Internet Draft SNMP Configuration November 2000 Assume the above object appeared in one table indexed by instances of water heaters in a house. Further suppose the appearance of the following, and its "third" state, in another section of another MIB module: acmeGasPilotsStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), primed(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Gas Pilots have three states, initial state is disabled, then primed which properly heats thermocouple and activates safety valves, then enabled." ::= { acmeGasPilotsEntry 7 } If a port is set to primed(3) via the acmeGasPilotsStatus, what should be reported in reported in acmeWaterHeaterPilot for the same conceptual instance? If one is required to overlap configuration objects, then identify and reference the duplicated object in the DESCRIPTION clause of the added object. Future updates to either object must be considered in sequnce so that certain states available in one configuration object can also be represented in another object. Another example can be found between the IF-MIB and the BRIDGE-MIB [22]. The BRIDGE-MIB defines the following managed object: dot1dStpPortEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The enabled/disabled status of the port." REFERENCE "IEEE 802.1D-1990: Section 4.5.5.2" ::= { dot1dStpPortEntry 4 } MacFaden et al Expires May 2001 [Page 16] Internet Draft SNMP Configuration November 2000 and the IF-MIB defines a very similar managed object: ifAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state)." ::= { ifEntry 7 } dot1dStpPortEnable can not properly display the state of a port that is set to testing(3) via the ifAdminStatus. In additon, these objects can be directly related by using the managed object: dot1dBasePortIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of the instance of the ifIndex object, defined in MIB-II, for the interface corresponding to this port." ::= { dot1dBasePortEntry 2 } Fate sharing of SNMP tables should be explicitly defined where possible using SMI constructs such as AUGMENTS. If the relationship between tables can not be defined using SMIv2 macros, then the DESCRIPTION clause should define what should happen. Since the dot1dBasePortTable is indexed by dot1dBasePort and each row in the dot1dBasePortTable references a row in the ifTable via the above managed object, it is not well defined how fate sharing of two related rows should be handled. MacFaden et al Expires May 2001 [Page 17] Internet Draft SNMP Configuration November 2000 5.1.1.4. Configuration Data Persistence Ambiguity Many SNMP agents implement simple persistence models. SNMP set requests against MIB objects with MAX-ACCESS read-write are typically written automatically to a peristent store. There now exist new methods to support explicit storage of configuration data. textual The first method uses the Textual Convention known as StorageType [6] which explicitly defines a given row's persistence requirement. Examples include the RFC 2591 [23] definion for the schedTable row object schedStorageType of syntax StorageType, as well as similar row objects for virtually all of the tables of the SNMPv2 View-based Access Control Model MIB [15]. A second method for persistence simply uses the DESCRIPTION macros to define how instance data should persist. RFC 2674 [24] defines explicitly Dot1qVlanStaticEntry data persistence as follows: dot1qVlanStaticTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qVlanStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing static configuration information for each VLAN configured into the device by (local or network) management. All entries are permanent and will be restored after the device is reset." ::= { dot1qVlan 3 } Best current practice in internet deployed network elements is a dual persistence model where: 1) a volatile memory configuration can be retrieved/updated and 2) persistent boot configuration. Single persistence systems suffer the ability to rollback changes that cause lost connectivity and hence are not often found in backbone wide area networks operated over remote connections. MacFaden et al Expires May 2001 [Page 18] Internet Draft SNMP Configuration November 2000 5.1.1.5. Data Architecture Independence Do not use OCTET STRINGS to transport data whose interpretation will differ by management station memory architecture. If an OCTET STRING encoding is useful within the context of the MIB module, a well- specified generic model should be used such as the RFC 2674 VLAN Bridge [24] PortList TEXTUAL-CONVENTION. 5.1.2. Administrative Consistency A MIB module which has MIB objects that are ambiguous with regard to a devices behavior when configuration is made should be avoided. 5.1.2.1. Configuration Sets and Activation An essential notion for configuration of network elements is awareness of the difference between the set of one or more configuration objects from the activation of those configuration changes in the actual subsystem. Any complex configuration should have a master on/off switch as well as strategically placed on/off switches to control the employment of configuration data. These controls play a pivotal role during the configuration process as well as during subsequent diagnostics. Generally a series of set operations should not cause an agent to act on each object causing convergence/stability to be possibly lost on each and every set. Ideally a series of Set PDUs would install the configuration and a final set series of PDUs would activate the changes. During diagnostic situations, certain on/off switches can be set to localize the perceived error instead of having to remove the configuration. An example of such an object from the OSPF Version 2 MIB [27] is the global ospfAdminStat: ospfAdminStat OBJECT-TYPE SYNTAX Status MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative status of OSPF in the MacFaden et al Expires May 2001 [Page 19] Internet Draft SNMP Configuration November 2000 router. The value 'enabled' denotes that the OSPF Process is active on at least one inter- face; 'disabled' disables it on all inter- faces." ::= { ospfGeneralGroup 2 } Elsewhere in the OSPF MIB, the semantics of the set of the ospfAdminStat to enabled(2) are clearly spelled out. The Scheduling MIB [23] exposes such an object on each entry in the scheduled actions table, along with the corresponding read status object on the entry status: schedAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the schedule." DEFVAL { disabled } ::= { schedEntry 14 } schedOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), finished(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this schedule. The state enabled(1) indicates this entry is active and that the scheduler will invoke actions at appropriate times. The disabled(2) state indicates that this entry is currently inactive and ignored by the scheduler. The finished(3) state indicates that the schedule has ended. Schedules in the finished(3) state are ignored by the scheduler. A one-shot schedule enters the finished(3) state when it MacFaden et al Expires May 2001 [Page 20] Internet Draft SNMP Configuration November 2000 deactivates itself." ::= { schedEntry 15 } The above example of a writeState/readStatus object pair does bring up one operational complication in their usage as a pair. Consider the relationship between ifAdminStatus and ifOperStatus. It is clear that, assuming no errors get in the way, a management application can set an interface whose ifOperStatus is down(2) to the point of having its ifOperStatus report up(1) by setting the ifAdminStatus on the interface to up(1), and polling ifOperStatus until it reaches the desired state. An application cannot detect, however, whether an interface whose ifOperStatus reports down(2) will reach the state of reporting up(1) independent of that application's own operation on the interface (i.e., through another management application or system initialization complete). In the case where an object is known to be in the process of being made enabled or up and the writable administrative object is set to 'enable' or 'bringUp', it is hoped that the agent will be able to silently discard the "redundant" request. Finally, a MIB module designer should not overload RowStatus objects to control activation/deactivation of a configuration. While RowStatus looks ideally suited for such a purpose since a management application can set a row to active(1), then set it to notInService(2) to disable it then make it active(1) again, there is no guarantee that the agent won't discard the row while it is in the notInService(2) state. The DISMAN-SCHEDULE-MIB's managed object schedAdminStatus demonstrates how to separate row control from row activation. Setting the schedAdminStatus to disabled(2) does not cause the row to be aged out/removed from the table. 5.1.2.2. Activation Latency in MIB modules It is important for MIB module desinters to design in features to accomodate considerations for activation latency in the structure of their read-write objects as well. Many MIB module designs make the mistake of assuming an agent can activate a set operation as quickly as the agent can reply to the manager for a given set PDU result. The RF MIB [26] is a useful example. The docsIfDownstreamChannelTable contains the following managed object: MacFaden et al Expires May 2001 [Page 21] Internet Draft SNMP Configuration November 2000 docsIfDownChannelFrequency OBJECT-TYPE SYNTAX Integer32 (0..1000000000) UNITS "hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The center of the downstream frequency associated with this channel. This object will return the current tuner frequency. If a CMTS provides IF output, this object will return 0, unless this CMTS is in control of the final downstream RF frequency. See the associated compliance object for a description of valid frequencies that may be written to this object." REFERENCE "DOCSIS Radio Frequency Interface Specification, Section 4.3.3." ::= { docsIfDownstreamChannelEntry 2 } When there is anticipated latency in activating the results of a set operation, it would be best if a MIB module designer either o define a form of state machine to support the intermediate states and necessary objects to model it o Separate out read state of the management data (in a separate object) from its read-write state object. For example, if the ACME-HOUSECTL-MIB had implemented the garage door with a single object as follows: acmePortGarageDoor OBJECT-TYPE SYNTAX INTEGER { unknown(0), closed(1), open(2)} MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the garage door. Most garage doors open completely within 12 seconds." ::= { acmePortGarageEntry 2 } MacFaden et al Expires May 2001 [Page 22] Internet Draft SNMP Configuration November 2000 T(0) Manager--------> <--------------Agent | GetPDU(acmePortGarageDoor.1.1) | ResponsePDU(error-index 0, | error-code 0) | acmePortGarageDoor.1.1 == open(2) | SetPDU(acmePortGarageDoor.1.1 = closed(1)) | ResponsePDU(error-index 0, | error-code 0) | acmePortGarageDoor.1.1 == closed(1) | GetPDU(acmePortGarageDoor.1.1) | ResponsePDU(error-index 0, error-code 0) | V acmePortGarageDoor.1.1 == open(2) . . . (some seconds later...) | GetPDU(acmePortGarageDoor.1.1) | ResponsePDU(error-index 0, error-code 0) | acmePortGarageDoor.1.1 = closed(1) V But the Manager expected the value of closed(1) since it had just set that value! Repeated polling of the object will eventually return the state value of closed(1) assuming nothing prevented the door from returning to the open state. Another consideration related to latency concerns the granularity of updates. Many management application environments may be able to poll agents much more quickly than the the agents are reporting values of can be updated in the agent. This is the reason it is useful for the agent in the agent capability MIB for the device what the minimum polling interval is. MacFaden et al Expires May 2001 [Page 23] Internet Draft SNMP Configuration November 2000 5.1.2.3. Application Error Reporting Applications should not rely on the SNMP protocol error mechanisms themselves to report application layer errors for SET operations. It is far better in configuration-capable MIB module design to use objects to track application level state. Management applications to date do not handle errors gracefully from the SNMP. Even if the management station SNMP will catch a "badValue" error, the application should report additional application level error-state that an application or manager can obtain from an agent and decode. Failure to provide detailed diagnostic information leads to management applications that end up reporting insufficient and misleading error information. acmeSysDeviceLastErr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the last error that occurred in this MIB due to configuration errors or status error presentable to user interface." ::= { acmeHouseGlobals 7 } In addtion, a notification might be used to signal configuration failures. 5.1.2.4. Notification Hysteresis Avoidance When designing notifications, keep in minde an upper limit on the number of notifications (or traps) that can be sent in response to a given event. RMON I[30] defines a generic trap capability in alarmTable and experience shows that such design is indeed needed. The greater the frequency of an event which causes a notification to be sent, the greater the need for either internal aggregation and redesign of the notification and/or throttling in the agent. Also, there can be cases where it is not useful to send notifications for a given notification. It is useful to include in the DESCRIPTION clause when the notification should not be sent. A good example is the frDLCIStatusChange defined in RFC 2115[19]. MacFaden et al Expires May 2001 [Page 24] Internet Draft SNMP Configuration November 2000 In the case when interfaces are taken down administratively, no frDLCIStatusChange is sent. Otherwise, notifications are sent at no greater a rate than frTrapMaxRate seconds, with the option of delay or discard of more frequently generated trap conditions at the agent's discretion. Alternatively, one can define trap aggregation objects. Here is another example of defining two different traps over the same event which allows the implementor to gracefully indicate to a manager an event that may have occured many times. acmeHouseCtlDeviceLost NOTIFICATION-TYPE OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey, acmeHouseInvenAdminStatus, acmeHouseInvenOperStatus} STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send the acmeHouseCtrlManyDevicesLost notification." ::= { acmeHouseCtlGlobalErrs 1 } acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors } STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send acmeHouseCtrlManyDevicesLost notification." ::= { acmeHouseCtlGlobalErrs 2 } 5.1.2.5. Transaction Control MIB Objects Consistent with the considerations in [SNMPTRANS], when a standard MIB module is defined that include configuration operations, thought should be given to providing transaction control objects in places MacFaden et al Expires May 2001 [Page 25] Internet Draft SNMP Configuration November 2000 where they may have value. Here are some examples: o Control objects that are the 'write' or 'commit' objects. Such objects will cause the all pending transactions (change MIB object values as a result of SET operations) to be committed to a permanent repository or operational memory as defined by the semantics of the MIB objects. o Control objects at different levels of configuration granularity. One of the decisions for a MIB module designer is what are the meaningful levels of granularity that make sense. For example, in the routing area, would changes be allowed on a per protocol basis only or by protocol area such as BGP? If allowed at the BGP level, are sub-levels permitted such as per autonomous system? Obviously these control will be impacted by the underlying software design. Row-status also has important relevance as a general transaction control object. See discussions on row-status elsewhere in this document for additional details. 5.1.3. Consistency with SNMPv3 Standards The current version of SNMP and its management framework call for a number of objects to be present in table rows. For the benefit of SNMP-based configuration, the proper usage of those objects (as called for in [7] and [14] and as further refined in SNMPv3 usage) is necessary for operational consistency. 5.1.3.1. Enumerating Capabilities Distinguishing which capabilities an agent can and must support can be done in an Agent Capability MIB or by simply designing placing an object into the MIB module to indicate required basic capabilities, using a bitmask or other form of multi-selection data element. For example, the use of capability bits in RFC 2674 [24] dot1dDeviceCapabilities can define some preset levels of agent capability: MacFaden et al Expires May 2001 [Page 26] Internet Draft SNMP Configuration November 2000 dot1dDeviceCapabilities OBJECT-TYPE SYNTAX BITS { dot1dExtendedFilteringServices(0), -- can perform filtering of -- individual multicast addresses -- controlled by GMRP. dot1dTrafficClasses(1), -- can map user priority to -- multiple traffic classes. dot1qStaticEntryIndividualPort(2), -- dot1qStaticUnicastReceivePort & -- dot1qStaticMulticastReceivePort -- can represent non-zero entries. dot1qIVLCapable(3), -- Independent VLAN Learning. dot1qSVLCapable(4), -- Shared VLAN Learning. dot1qHybridCapable(5), -- both IVL & SVL simultaneously. dot1qConfigurablePvidTagging(6), -- whether the implementation -- supports the ability to -- override the default PVID -- setting and its egress status -- (VLAN-Tagged or Untagged) on -- each port. dot1dLocalVlanCapable(7) -- can support multiple local -- bridges, outside of the scope -- of 802.1Q defined VLANs. } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the optional parts of IEEE 802.1D and 802.1Q that are implemented by this device and are manageable through this MIB. Capabilities that are allowed on a per-port basis are indicated in dot1dPortCapabilities." REFERENCE "ISO/IEC 15802-3 Section 5.2, IEEE 802.1Q/D11 Section 5.2, 12.10.1.1.3/b/2" ::= { dot1dExtBase 1 } For configuration ability specifically, one can extend this notion to exposing a different set of ad-hoc set capabilities. MacFaden et al Expires May 2001 [Page 27] Internet Draft SNMP Configuration November 2000 5.1.3.2. Usage of Row notReady Status It is useful when configuring new rows to use the notReady status to indicate row activation can not proceed. When designing read-create objects in a table containing a RowStatus object, a MIB module designer should first consider the default state of each object in the table when a row is created via one simple createAndWait(5) PDU. If no default state is applicable but the object must be set to some value, the DESCRIPTION clause should specify this object as mandatory. In addtion, an snmp get of such an object then should return a noSuchName error if the object has not yet been set. A read of the RowStatus columnar object should return notReady(3) until all such mandatory and non-defaultable objects have been set with acceptable values. Should a given implementation require more objects to be set than what is specified in a MIB module, an Agent capabilities MIB module can be used to define the additional objects using the CREATION-REQUIRES clause. Not implementing the above may result in a management application being misled that a transition to active(1) state will succeed without further action by only polling the rowStatus object and receiving the notInService(2) value from an agent. 5.1.3.3. Exposure of Row Object Modifiability Once a rowStatus value is active(1) for a given row, the management application should be able to determine the semantics are for making addtional changes to a row. RMON I MIB control table objects spell out explicitly what managed objects in a row can and can not be changed once a given rowStatus goes active. Some operations and states may require an extended period of time to run with given set of parameters. Where change of those parameters under given conditions would necessitate the restarting of the whole greater operation, that constraint should be specified in the DESCRIPTION clause of the modifiable row object. 5.1.3.4. Octet String Aggregations Octet strings should not be used to aggregate management data which logically reside in multiple objects. Instead, separate objects MacFaden et al Expires May 2001 [Page 28] Internet Draft SNMP Configuration November 2000 should be specified in separate MIB objects or instances. Additionally, an octet string is by definition limited to 65535 bytes per SMIv2[5]. If the object being modeled is larger than this size, one should abstract the information or reorganize the data to fit within this size boundary which helps keep configuration working in the face of abnormally behaving networks not to mention fragmenting packets and the ensuing bad performance. 5.1.4. MIB Object and Practice Reuse Independent of other considerations for pure consistency with the current required standards in deployment and application usage of SNMP as described in [SNMP3CONS], the evolution of SNMP usage has provided a number of highly useful objects, conventions, and practices. While these objects and practices may not be MIB requirements, experience has shown a number to have specific value for SNMP MIB modules exposing configurability. 5.1.4.1. Textual Convention Usage Textual conventions should be used whenever possible to create a consistent semantic for an oft recurring practice. Textual conventions that have even the slightest chance of being reused in other MIB modules ideally should also be defined in a separate MIB module to facilitate sharing of such objects. For example, the state of an object can often be described using a TruthValue textual convention [6] instead of inventing yet another Boolean condition enumeration with potentially conflicting semantics and values from many other enumerations just like it. Hence, acmePatioLights OBJECT-TYPE SYNTAX INTEGER { on(1), off(2), } MAX-ACCESS read-write STATUS current DESCRIPTION "Current status of outdoor lighting." MacFaden et al Expires May 2001 [Page 29] Internet Draft SNMP Configuration November 2000 ::= { acmeOutDoorElectricalEntry 3 } Would better expressed as follows: AcmePatioLightsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Current status of outdoor lighting." ::= { acmeOutDoorElectricalEntry 3 } 5.1.4.2. Usage of Extension Capability of Standard Notification Objects Vendor extensions to existing standard notifications are not explicitly disallowed or allowed in SMIv2[5]. Exploiting this resulting capability provides powerful opportunities for notification reuse. For example, linkUp and linkDown traps are defined as follows in [17]: linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } An implementation could add additional varbind objects to standard notifications to, for example, provide vendor-specific objects pertinent to administrative disabling of a link. If an implementation is to do this, however, it is best if it not enable these extensions by default and require explicit enabling of them. An implementation which does this should append to the varbind list any extensions after those specified for the standard notification. Note, however, that this approach has problems when a standards body MacFaden et al Expires May 2001 [Page 30] Internet Draft SNMP Configuration November 2000 working group updates a trap in the future. One problem arises when the standards update includes the same object but not in the same sequence. Applications which rely on position of varbinds can fail unexpectedly in these circumstances. Hence, the conservative approach is to use private notifications if possible. 5.1.4.3. OwnerString Usage Experience has shown that usage of OwnerString to represent row ownership can be a useful diagnostic tool. Specifically, the use of the string "monitor" to identify configuration set by an agent/local management has been useful in application. 5.1.4.4. TimeStamp Diagnostics Adding a TimeStamp object to read-create tables to show when it was activated is a useful diagnostic tool in the detection of configuration errors. Examples include the following objects from the IP Forwarding MIB [25] ipCidrRouteTable and RF MIB [26] docsIfCmtsCmStatusTable respectively: ipCidrRouteAge OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned." DEFVAL { 0 } ::= { ipCidrRouteEntry 8 } docsIfCmtsServiceCreateTime OBJECT-TYPE SYNTAX TimeTicks SYNTAX TimeStamp MacFaden et al Expires May 2001 [Page 31] Internet Draft SNMP Configuration November 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was created." ::= { docsIfCmtsServiceEntry 5 } Note that one example above is relative to the time of last update, and the other is relative to sysUpTime. 5.1.4.5. Expressing Agent Capacity Managed systems often would prefer to know how many rows might be created in a given table. Failiure to activate a row due to capacity should be able explicitly discernable. All implementations have limits on how many rows of a given resource can be created. Solutions used include runtime objects that provide current resource left, limiting the number of rows in notReady or notInService state, as a description in the Agent Capabilities. 5.1.5. Secure Agent Considerations 5.1.5.1. SNMPv1 Community String Defaulting Vendors should not ship a device with a community string 'public' or 'private.', and agents should not define default community strings except where to bootstrap devices that do not have secondary management interfaces. Defaults lead to security issues, which have been recognized and exploited. When using SNMPv1, supporting read only community strings is a common practice. 5.1.5.2. Authentication Traps The default state of RFC 1215 [4] Authentication traps should be off. In the "Notification Hysteresis Avoidance" section of this document, issues and recommendations on throttling traps were raised. Where notifications are sent in SNMPv1 trap PDUs, unsolicited MacFaden et al Expires May 2001 [Page 32] Internet Draft SNMP Configuration November 2000 packets to a device can causes one ore more trap PDUs to be created and sent to management stations. If these traps flow on shared access media and links, the community string from the trap may be gleaned and exploited to gain access to the device. 5.1.5.3. Specification of Sensitive Information Handling Some MIB modules contain objects that may contain data for keys, passwords and other such sensitive information and hence must be protected from unauthorized access. The DESCRIPTION clause for the and their defining MIB RFC Security Considerations section should make it clear how and why these specific objects are sensitive and that a user should only make them accessible for encrypted SNMP access. If an implementation does not support DES, then the customer should not allow access to these objects, which is easy to specify in VACM [15]. When writing standards track MIB modules, one must operate on the basis of the "must implement" properties are of the various standards-track specifications. Confidentiality is not a must-implement portion of the SNMPv3 management framework [11]. 5.1.5.4. Consider large volumes The issue of transferring large amounts of configuration data via SNMP remains difficult. A common practice used to move large amounts of data involved using SNMP in combination with other protocols defined for transporting bulk data. 5.2. Management Software Development This section focuses on general issues related to the development of SNMP based applications that configure one or more network elements. Special considerations for what has come to be known as policy-based management with SNMP are discussed in a following section. Effective software for the configuration of one or many network elements requires some up MacFaden et al Expires May 2001 [Page 33] Internet Draft SNMP Configuration November 2000 front design work before starting implementation. This is true regardless of the technology used to represent and transfer the configuration information. 5.2.1. Protocol Operations There are three basic areas to evaluate relevant to SNMP protocol operations and configuration: o Set and configuration activation operations o Notifications from the device o Data retrieval and collection The design of the system should not assume that the objects in a device that represent configuration data will remain unchanged over time. As standard MIB modules evolve and vendors add private extensions, the specific configuration parameters for a given operation are likely to change over time. Even in the case of a configuration application that is designed for a single vendor, the designer should allow for variability in the MIB objects that will be used to configure the device for a particular purpose. The best method to accomplish this is by separating as much as possible the operational semantics of a configuration operation from the actual data. One way that some applications achieve this is by having the specific configuration objects that are associated with a particular device be table driven rather than hard coded. Ideally, management software should verify the support in the devices it is intended to manage and report any unexpected deviations to the operator. This approach is particularly valuable when developing applications that are intended to support equipment or software from multiple vendors. 5.2.2. SET Operations Management software should adapt its SET operations to the type of device and specific MIB objects included in the SET PDU. The specific intent here is to attempt to move the configuration information as efficiently to the managed device as possible. There are many ways to achieve efficiency and some are specific to given devices. One general case example that all management software should employ is to reduce to the smallest reasonable number, the number of SET PDU exchanges between the MacFaden et al Expires May 2001 [Page 34] Internet Draft SNMP Configuration November 2000 managed device and the management software. One approach to this is to verify the largest number of variable bindings that can fit into a SET PDU for a managed device. In some cases, the number of variable bindings to be sent in a particular PDU will be influenced by the device, the specific MIB objects and other factors. Maximizing SET variable bindings within a PDU has beneficial implications in the area of management application transaction initiation, as well, as we will discuss in the following section. 5.2.3. Configuration Transactions There are several types of configuration transactions that can be supported by SNMP-based configuration applications. They include transactions on a single table, transactions across several tables in a managed device and transactions across many devices. The managers ability to support these different transactions is partly dependent on the design of the MIB objects within the scope of the configuration operation. To effectively make use of any kind of transaction semantics, SNMP management software must be aware of the information in the MIB modules that it is to configure so that it can effectively utilize row status objects for the control of transactions on one or more tables. Such software must also be aware of control tables that the device supports that are used to control the status of one or more other tables. To the greatest extent possible, the management application SHOULD provide the facility to support transactions across multiple devices. This means that if a configuration operation is desired across multiple devices, the manager can coordinate these configuration operations such that they become active as close to simultaneously as possible. Several practical means are present in the SNMP model to effect this management application transactional support. One was mentioned in the preceding section. A transactional effect is optimized when the maximum number of SET variable bindings are conveyed in a single processed PDU on the agent. There is an important refinement to this, however, for set of table row data objects. The set of read-create row data objects for the table should be set in a single PDU or set of PDUs, and the verification of MacFaden et al Expires May 2001 [Page 35] Internet Draft SNMP Configuration November 2000 their successful set (through the response to the Set PDU or the subsequent polling of the row data objects to verify their setting in the desired state) should be done. Only at the point of that verification should the set on the applicable RowStatus object(s), to set the rows to active, be done. This is the only effective means of affording an opportunity for per-row rollback, particularly when the configuration change is across table row instances on multiple managed devices. 5.2.4. Notifications As described throughout the section on Agent Software Development, agents SHOULD provide the capability for notifications to be sent to their configured management systems whenever a configuration operation is attempted or completed. The management application MUST be prepared to accept these notifications so that it knows the current configured state of the devices it has been deployed to control. Some configuration management applications may consume data from the managed devices that reflects configuration, operational and utilization state information. The GetBulkRequest-PDU is useful here whenever supported by the managed device. For the purposes of backward compatibility, the management station should also support and make use of the GetNextRequest-PDU in these cases. Management systems should also provide configuration options with defaults for users that tend to retrieve the smallest amount of data to achieve the particular goal of the application. 5.2.5. Scale of the Management Software Efficient data retrieval described above is only part of the dimension of scale that application developers should consider when developing configuration applications. Management applications should provide for distributed processing of the configuration operations. This also extends to other management functions not the focus of this document. This capability can also be used to provide resiliency in the case of network failures as well. MacFaden et al Expires May 2001 [Page 36] Internet Draft SNMP Configuration November 2000 5.3. Handling Multiple Managers Devices are often modified by multiple management entities. These management entities may be in the same organization or may be in different organizations interior or exterior to a given autonomous system. There are many aspects to view this model from. First, the changes between two or more management applications issuing SET protocol operations need be coordinated. Race conditions should be easily detectable when two entities provision exactly the same object or within a transaction a group of objects. Second, A device should be able to report configuration as set by different entities as well as distinguish configuration defined locally such as a default or locally specified configuration made through an alternate management interfaces like command line interface. The SMIv2 defines the Textual convention TestAndIncr often called a SpinLock to solve race conditions. As with much of the SNMP framework detail, much flexibility is left to the implementors to "do the right thing." Unless a MIB module explicitly defines the use mandatory use of synchronization primitives, an agent cannot enforce their use. Where used, an object of syntax TestAndIncr should be well defined as to what it is being covered. However the use of a general all encompassing lock can be used, such as the RFC 1907 snmpSetSerialNo object [16]. An application should use this object if there is no specific TestAndIncr object. 5.4. Management Station Time SNMP-based management systems have had to deal with time-based data since they were first deployed. The best example of this is the performance data collection area where total work performed is calculated on an interface over some period of time. This information is then stored and used later in the production of reports. Similarly, configuration information must also be saved in a time-coherent fashion. This means that all configuration transactions should be logged to MacFaden et al Expires May 2001 [Page 37] Internet Draft SNMP Configuration November 2000 permanent storage so that they too can be reported. Of equal importance is the ability to restore the managed elements in an network to a 'known' state in the past. Often this will mean the (re)configuration of devices in different countries and time zones. Management software must also be able to deal with this. There are many commercial database systems that have this property. There are also a number of proprietary approached that have been created to provide this function. See the Schedule and Time issues in the Policy section of this document for discussion of related issues. 6. POLICY BASED MANAGEMENT Since policy based management with SNMP is a relatively new concept, this section does not document established practice with regard to policy-enabled SNMP management systems. It gives some background and defines terms that are relevant to this field and describes recommended deployment approaches. Issues that one should consider when deploying an SNMP-enabled policy management system are also discussed. 6.1. Information Related to Policy Configuration In order for effective policy management to take place, a range of information about the network elements is needed to avoid making poor policy decisions. An effective policy management system will include the following information about each network element before sending policies for execution: o The operational state of network elements that are to be configured. In particular, care should be taken to determine if the sub components to be configured are available for use. In some cases the elements may not be available. The policy configuration software should determine if this is a prerequisite to policy download or if the condition is acceptable. In those cases where policy is distributed when the sub component such as an interface or disk is not available, the managed system should send a notification to the designated management station when the policy is to become active if the MacFaden et al Expires May 2001 [Page 38] Internet Draft SNMP Configuration November 2000 resource is still not available. o The capabilities of the devices in the network. A capability can be almost any unit of work a network element can perform. These include, routing protocols supported, Web Server and OS versions, queuing mechanisms supported on each interface that can be used to support different qualities of service, and many others. this information can be obtained from the capabilities table of the Policy MIB module. o The capacity of the devices to perform the desired work. Capability is an ability to perform the desired work while a capacity is a measure of how much of that capability the system has. The policy configuration application should wherever possible, evaluate the capacity of the network element to perform the work identified by the policy. In some systems it will not be possible to directly obtain the capacity of the managed elements to perform the desired work, even though it may be possible to monitor the amount of work the element performs. In these cases, the management application may benefit from pre-configured information about the capacity of different network elements so that evaluations of the resources available can be made before distributing new policies. Utilization refers to how much capacity for a particular capability has been consumed. For devices that have been under policy configuration control for any period of time, a certain percentage of the available capacity of the managed elements will be used. Policies should not be distributed to systems that do not have the resources to carry out the policy for a reasonable period of time. 6.2. Policy, Mechanism/Implementation and Instance Specific Modules A conformant system could implement the policy module without any mechanism or implementation-specific modules though it is thought that will not be a likely scenario. For complicated configuration areas such as Differentiated Services, Web servers, routing protocols, etc., mechanism and frequently implementation-specific MIB modules will be required. If a vendor implements a standard set of instance-specific MacFaden et al Expires May 2001 [Page 39] Internet Draft SNMP Configuration November 2000 MIB objects and an RFC has not yet been defined for a mechanism-specific set of objects to control the policy based configuration of these instance-specific objects, the vendor should create such a module allowing for the fact that an RFC might be issued later for the mechanism-specific module. To the extent a vendor creates instance- specific extensions to standard instance-specific MIB modules, they should also create implementation-specific MIB modules if they intent the box to be configured with policy-based management. Many vendors create proprietary functions and the instrumentation to manage them. To enable these features to be integrated into an SNMP- based policy management system, both instance and implementation- specific MIB objects should be created. 6.3. Schedule and Time Issues In large networks it may be necessary to coordinate the application of policies across time zones. Wherever possible, the network elements should support time information that includes local time zone information. Some deployed systems do not store complex notions of local time and thus may not be able to properly process policy directives that contain time zone relevant data. For this reason, policy management applications should have the ability to ascertain the time keeping abilities of the managed system and make adjustments to the policy for those systems that are time-zone challenged. 6.4. Conflict Detection, Resolution and Error Reporting Sophisticated conflict detection and resolution is not realistically achievable in the short-term. Using a hierarchical approach to this problem can achieve significant benefits. Each 'layer' policy management system should be able to check for some errors and report them. The responsibilities for each layer are: Instance-specific: Conflict detection has been performed in a limited way for some time in software that realizes instance- specific MIB objects. This detection is independent of policy however. They types of 'conflicts' that are usually processed related are to resource availability and validity of the set operations. In a policy enabled system, there are not additional requirements for this software assuming that good error detection and reporting appropriate to this level had MacFaden et al Expires May 2001 [Page 40] Internet Draft SNMP Configuration November 2000 already been implemented. Mechanism and implementation-specific: For software that realizes mechanism and/or implementation-specific objects, failures should be reported such that the specific policy that has been impacted can be related with the specific element that failed. Beyond this basic reporting which is does not perform any policy conflict detection, there are not requirements. Mechanism and implementation-independent: The software that implements the mechanism and implementation-independent function will most often be a realization of the policy module. This software does assume some limited role in conflict detection. Specifically this software should verify that no two policies with the same precedence are allowed on the system. The policy system should also report events where one policy overrides another or when an element under policy control has been modified outside the policy system as would be the case of CLI modifications to elements under policy control. 6.5. Policy Precedence and Grouping TBD 6.6. Changes to configuration outside of the policy system A goal of SNMP-based policy management is to coexist with other forms what have historically been instance based management. The best example is command line interface. Here are some guidelines for handling these changes. A notification should be sent whenever an out of policy control change is made to an element that is under the control of policy. This notification should include the policy that was changed, the instance of the element that was changed and the object and value that it was changed to. More on contexts TBD. An element under the control of policy that has been changed remains a member of the policy group until the attributes in the Role table that caused it to match the policy in the first place are modified. An element that has been modified by a an MacFaden et al Expires May 2001 [Page 41] Internet Draft SNMP Configuration November 2000 out of policy mechanism, while remaining a member of the policy does not get overridden by a policy until its value is made the same as the extant policy with the highest precedence for this element, and by implication then returned to policy control. A notification should be sent when this action is taken. 6.6.1. Use of Contexts TBD 6.6.2. Policy distribution applications TBD 6.6.3. Notifications in a Policy System TBD 7. EXAMPLE MIB MODULES ACME-HOUSECTL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, Counter32, Gauge32, OBJECT-TYPE, TimeTicks, Integer32, NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF TruthValue, TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB; acmeHouseCtlMIB MODULE-IDENTITY LAST-UPDATED "200007090000Z" ORGANIZATION "Acme, Inc" CONTACT-INFO "Acme, Inc 1 Main Street Anytown, Anywhere" DESCRIPTION MacFaden et al Expires May 2001 [Page 42] Internet Draft SNMP Configuration November 2000 "This mib module defines a sample mib module that contains status/inventory, configuration and diagnostic management objects for items in a single family home." REVISION "200007090000Z" DESCRIPTION "Initial version of ACME-HOUSECTRL-MIB." ::= { XXX 55 } -- -- Textual Conventions -- AcmeCfgVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that starts at 0 and increases monotonically until the Max value is reached at which point the value returns to 0." SYNTAX Gauge32 AcmeDeviceAdminStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The operational state of a device. Setting a device to testing invokes diagnostic routines which may or may not bring a device out of service." SYNTAX INTEGER { up(1), down(2), testing(3) } AcmeDeviceOperStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The current general state of the device. A failed state indicates the device is not responding to management control" SYNTAX INTEGER { up(1), down(2), testing(3), failed(4) } MacFaden et al Expires May 2001 [Page 43] Internet Draft SNMP Configuration November 2000 -- -- Top level delegations -- acmeHouseInventory OBJECT-IDENTITY STATUS current DESCRIPTION "Inventory of the controls in the home over which operations can be made." ::= { acmeHouseCtlMIB 1 } acmeHouseGlobals OBJECT-IDENTITY STATUS current DESCRIPTION "Objects of global scope over a given home." ::= { acmeHouseCtlMIB 2 } acmeHouseConfig OBJECT-IDENTITY STATUS current DESCRIPTION "Configuration of devices managed by this MIB or subsidiary MIB modules." ::= { acmeHouseCtlMIB 3 } acmeHouseCtlExceptions OBJECT-IDENTITY STATUS current DESCRIPTION "Exceptions of global scope to this mib defined here." ::= { acmeHouseCtlMIB 9 } acmeHouseCtlConformance OBJECT-IDENTITY STATUS current DESCRIPTION "Conformance details kept here for this MIB." ::= { acmeHouseCtlMIB 10 } -- -- Inventory Group -- acmeHouseInvenLastUpdated OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Timestamp when inventory report was last updated. A value of zero indicates never." MacFaden et al Expires May 2001 [Page 44] Internet Draft SNMP Configuration November 2000 ::= { acmeHouseInventory 1 } acmeHouseInvenNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of rows in acmeHouseInvenTable." ::= { acmeHouseInventory 2 } acmeHouseInvenTable OBJECT-TYPE SYNTAX SEQUENCE OF AcmeHouseInvenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table presents a list of devices found in a given home. Rows are added and deleted by the agent as discovered." ::= { acmeHouseInventory 3 } acmeHouseInvenEntry OBJECT-TYPE SYNTAX AcmeHouseInvenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row represents a particular device managed by this agent." INDEX { acmeHouseInvenId } ::= { acmeHouseInvenTable 1 } AcmeHouseInvenEntry ::= SEQUENCE { acmeHouseInvenId SnmpAdminString, acmeHouseInvenDevice OBJECT IDENTIFIER, acmeHouseInvenKey Integer32, acmeHouseInvenAdminStatus AcmeDeviceAdminStatus, acmeHouseInvenOperStatus AcmeDeviceOperStatus, acmeHouseInvenLastContact TimeStamp } acmeHouseInvenId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION MacFaden et al Expires May 2001 [Page 45] Internet Draft SNMP Configuration November 2000 "A persistent identifier that identifies a device uniquely within a single domain." ::= { acmeHouseInvenEntry 1 } acmeHouseInvenDevice OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The object identifier that uniquely identifies the type of device. A registration mib maintains the mappings to text. A vaue of 0.0 represents an unknown or unmanageable device." ::= { acmeHouseInvenEntry 2 } acmeHouseInvenKey OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value within a given set of device with the same acmeHouseInvenDevice object identifier. Can be used for a short-hand indexing to other tables and notifications." ::= { acmeHouseInvenEntry 3 } acmeHouseInvenAdminStatus OBJECT-TYPE SYNTAX AcmeDeviceAdminStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The desired administrative status of this device. Setting the value to down(2) has the effect of changing acmeHouseInvenOperStatus to down(2) as well." ::= { acmeHouseInvenEntry 4 } acmeHouseInvenOperStatus OBJECT-TYPE SYNTAX AcmeDeviceOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The curent operational state of the device." ::= { acmeHouseInvenEntry 5 } MacFaden et al Expires May 2001 [Page 46] Internet Draft SNMP Configuration November 2000 acmeHouseInvenLastContact OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the device last responded to any management request or last poll." ::= { acmeHouseInvenEntry 6 } -- -- Configuration Globals Group -- acmeHouseGlobalSysActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "State of house control system. A value of true(1) represents the system is actively monitoring state and will accept valid configuration requests. A value of false(2) indicates this the master system is not maintaining state of systems found in the inventory component." ::= { acmeHouseGlobals 1 } acmeSysActiveLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "sysUpTime when acmeHouseGlobalSysActive last changed state." ::= { acmeHouseGlobals 2 } acmeSysActiveConfigId OBJECT-TYPE SYNTAX AcmeCfgVersion MAX-ACCESS read-only STATUS current DESCRIPTION "Current value of configuration information. This value remains persistent across reboots and increases when configuration changes are made to any object in this MIB." ::= { acmeHouseGlobals 3 } acmeSysDevicesActive OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only MacFaden et al Expires May 2001 [Page 47] Internet Draft SNMP Configuration November 2000 STATUS current DESCRIPTION "Number of active devices in the system according to last poll." ::= { acmeHouseGlobals 4 } acmeSysDevicesLastFailed OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "sysUpTime when last device failed poll or admin request." ::= { acmeHouseGlobals 5 } acmeSysDeviceErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of devices that this manager lost contact, timed out with." ::= { acmeHouseGlobals 6 } acmeSysDeviceLastErr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the last error that occured in this mib due to configuration errors or status error presentable to user interface." ::= { acmeHouseGlobals 7 } -- -- Notification Section -- acmeHouseCtlGlobalErrs OBJECT IDENTIFIER ::= { acmeHouseCtlExceptions 0 } acmeHouseCtlDeviceLost NOTIFICATION-TYPE OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey, acmeHouseInvenAdminStatus, acmeHouseInvenOperStatus} STATUS current DESCRIPTION MacFaden et al Expires May 2001 [Page 48] Internet Draft SNMP Configuration November 2000 "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send the acmeHouseCtrlManyDevicesLost notification." ::= { acmeHouseCtlGlobalErrs 1 } acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors } STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send the acmeHouseCtrlManyDevicesLost notification." ::= { acmeHouseCtlGlobalErrs 2 } -- -- Compliance Section -- acmeHouseCtlGroups OBJECT IDENTIFIER ::= { acmeHouseCtlConformance 1 } acmeHouseCtlCompliances OBJECT IDENTIFIER ::= { acmeHouseCtlConformance 2 } acmeHouseInventoryGroup OBJECT-GROUP OBJECTS { acmeHouseInvenLastUpdated, acmeHouseInvenNumber, acmeHouseInvenDevice, acmeHouseInvenKey, acmeHouseInvenAdminStatus, acmeHouseInvenOperStatus, acmeHouseInvenLastContact } STATUS current DESCRIPTION "A collection of objects providing inventory and general status of all home objects controlled by this MIB module." MacFaden et al Expires May 2001 [Page 49] Internet Draft SNMP Configuration November 2000 ::= { acmeHouseCtlGroups 1 } acmeHouseGlobalsGroup OBJECT-GROUP OBJECTS { acmeHouseGlobalSysActive, acmeSysActiveLastChanged, acmeSysActiveConfigId, acmeSysDevicesActive, acmeSysDevicesLastFailed, acmeSysDeviceErrors, acmeSysDeviceLastErr } STATUS current DESCRIPTION "A collection of objects providing overall feature configuration state status." ::= { acmeHouseCtlGroups 2 } acmeHouseCtlNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { acmeHouseCtlDeviceLost, acmeHouseCtlManyDevicesLost } STATUS current DESCRIPTION "The notifications used by this MIB module to denote exceptional conditions." ::= { acmeHouseCtlGroups 3 } acmeHouseCtrlMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The set of groups that make up the mandatory and optional groups required for MIB module implementation." MODULE MANDATORY-GROUPS { acmeHouseInventoryGroup, acmeHouseGlobalsGroup } ::= { acmeHouseCtlCompliances 1 } END ACME-AGENTCAP-MIB DEFINITIONS ::= BEGIN MacFaden et al Expires May 2001 [Page 50] Internet Draft SNMP Configuration November 2000 IMPORTS MODULE-IDENTITY FROM SNMPv2-SMI AGENT-CAPABILITIES FROM SNMPv2-CONF acmeHouseCtlMIB FROM ACME-HOUSECTL-MIB; acmeAgentCapabilityMIB MODULE-IDENTITY LAST-UPDATED "200011010000Z" -- November 1, 2000 ORGANIZATION "Acme, Inc." CONTACT-INFO "Acme, Inc 1 Main Street Anytown, Anywhere" DESCRIPTION "This MIB Module contains a fictional agent capabilities for the ACME-HOUSECTRL-MIB." REVISION "200011010000Z" DESCRIPTION "A fictional deployment of a system implementing the ACME- HOUSECTRL-MIB." ::= { XXX 56 } system10 AGENT-CAPABILITIES PRODUCT-RELEASE "1.0" STATUS current DESCRIPTION "This fictional system was deployed with these conditions." REFERENCE "Possibly a URL" SUPPORTS ACME-HOUSECTL-MIB INCLUDES { acmeHouseInventoryGroup, acmeHouseGlobalsGroup } VARIATION acmeHouseInvenAdminStatus ACCESS read-only DESCRIPTION "First implementation does not allow updates to status." ::= { XXX 57 } END MacFaden et al Expires May 2001 [Page 51] Internet Draft SNMP Configuration November 2000 MacFaden et al Expires May 2001 [Page 52] Internet Draft SNMP Configuration November 2000 8. GLOSSARY +++wayne this needs significant expansion+++ Transaction A finite group of changes that taken as a whole can be applied or rolled back in one operation. For example, a single SNMP SET PDU represents a transaction for which the state before the set is returned should any individual element in the variable-bindings list fail to be applied thus returning the device to exactly the same state before the SET was executed. Device-Local Configuration Device-local configuration data is specific to a particular network device. This is the finest level of granularity for configuring network devices. Network-Wide Configuration Network-wide configuration data is not specific to any particular network device and from which multiple device-local configurations can be derived. Network-wide configuration provides a level of abstraction above device-local configurations. Configuration Data Translator A function that transforms Configuration Management Data (high-level policies) or Network-wide configuration data (middle-level policies) into device local configurations (low-level policies) based on the generic capabilities of network devices. This function can be performed either by devices themselves or by some intermediate entity. Denial of Service (DOS) Any situation where access to resources by authorized consumers is diminished by overt or inadvertent abuse of network layer mechanisms 9. REFERENCES [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. MacFaden et al Expires May 2001 [Page 53] Internet Draft SNMP Configuration November 2000 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. MacFaden et al Expires May 2001 [Page 54] Internet Draft SNMP Configuration November 2000 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, q(Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) q, RFC 1907, January 1996. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. [18] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [19] Brown, C., and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [20] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [21] Hawkinson, J., and T. Bates, "Guidelines for Creation, Selection, and Registration of an Autonomous System (AS)", RFC 1930, March 1996. [22] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [23] Levi, D., and J. Schoenwaelder "Definitions of Managed Objects for Scheduling Management Operations", RFC 2591, May 1999. [24] Bell, E., Smith, A., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions, RFC 2674, August 1999. [25] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. [26] St. Johns, M., "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [27] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995. [28] Blake, S. Black, D., Carlson M., Davies E. Wang Z., Weiss W., "An Architecture for Differentiated Services ", RFC 2475, December 1998. MacFaden et al Expires May 2001 [Page 55] Internet Draft SNMP Configuration November 2000 [29] Willis, S. and J. Chu., "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. [30] Waldbusser, S."DRemote Network Monitoring Management Information Base", RFC 2819, May 2000. 10. OUTSTANDING ISSUES 1. Section Introduction do we really mean "Autonomous System" that rigidly? The reference is specifically to RFC1930/BCP6, which gives guidance on selecting and registering a BGP AS-ID. 2. Glossary still under development 11. INTELLECTUAL PROPERTY The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. MacFaden et al Expires May 2001 [Page 56] Internet Draft SNMP Configuration November 2000 12. EDITORS' ADDRESSES Michael R. MacFaden Riverstone Networks, Inc 5200 Great America Parkway Santa Clara, CA 95054 email - mrm@riverstonenet.com Jon Saperia JDS Consulting 174 Chapman Street Watertown, MA 02472 email - saperia@mediaone.net Wayne Tackabury Gold Wire Technology 411 Waverley Oaks Rd. Waltham, MA 02452 email - wayne@goldwiretech.com 13. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet MacFaden et al Expires May 2001 [Page 57] Internet Draft SNMP Configuration November 2000 Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MacFaden et al Expires May 2001 [Page 58]