4.  Implementing SNMP Configuration Agents

4.1.  Operational Consistency

   Successful deployment of SNMP configuration systems depends on
   understanding the roles of MIB module design and agent design.

   Both module and agent design need to be undertaken with an
   understanding of how UDP/IP-based SNMP behaves.  A current practice
   in MIB design is to consider the idempotency of settable objects.
   Idempotency basically means being able to invoke the same set
   operation repeatedly but resulting in only a single activation.

   Here is an example of the idempotency in action:

Manager                              Agent
--------                             ------
Set1 (Object A, Value B) --->        receives set OK and responds
                          X<-------- Response PDU(OK) is dropped by
                                     network
Manager times out
and sends again
Set2 (Object A, Value B) --->       receives set OK (does nothing),
                                    responds
                          <-------- with a Response PDU(OK)
Manager receives OK

   Had object A been defined in a stateful way, the set operation might
   have caused the Set2 operation to fail as a result of interaction
   with Set1.  If the agent implementation is not aware of such a
   possible situation on the second request, the agent may behave poorly
   by performing the set request again rather than doing nothing.

   The example above shows that all of the software that runs on a
   managed element and in managed applications should be designed in
   concert when possible.  Particular emphasis should be placed at the
   logical boundaries of the management system components in order to
   ensure correct operation.

   1. The first interface is between SNMP agents in managed devices and
      the management applications themselves.  The MIB document is a
      contract between these two entities that defines expected behavior
      - it is a type of API.

   2. The second interface is between the agent and the instrumented
      subsystem.  In some cases, the instrumented subsystem will require
      modification to allow for the dynamic nature of SNMP-based
      configuration, control and monitoring operations.  Agent
      implementors must also be sensitive to the operational code and
      device in order to minimize the impact of management on the
      primary subsystems.

   Additionally, while the SNMP protocol-level and MIB module-level
   modeling of configuration operations may be idempotent and stateless
   from one set operation to another, it may not be that way in the

   underlying subsystem.  It is possible that an agent may need to
   manage this state in these subsystem architectures explicitly when it
   has placed the underlying subsystem into an "intermediate" state at a
   point in processing a series of SET PDUs.  Alternatively, depending
   on the underlying subsystem in question, the agent may be able to
   buffer all of the configuration set operations prior to activating
   them in the subsystem all at once (to accommodate the nature of the
   subsystem).

   As an example, it would be reasonable to define a MIB module to
   control Virtual Private Network (VPN) forwarding, in which a
   management station could set a set of ingress/egress IP addresses for
   the VPN gateway.  Perhaps the MIB module presumes that the level of
   transactionality is the establishment of a single row in a table
   defining the address of the ingress/egress gateway, along with some
   prefix information to assist in routing at the VPN layer to that
   gateway.  However, it would be conceivable that in an underlying
   Layer 2 VPN subsystem instrumentation, the requirement is that all
   existing gateways for a VPN be deleted before a new one can be
   defined--that, in other words, in order to add a new gateway, g(n),
   to a VPN, gateways g(1)..g(n-1) need to be removed, and then all n
   gateways reestablished with the VPN forwarding service.  In this
   case, one could imagine an agent which has some sort of timer to
   establish a bounded window for receipt of SETs for new VPN gateways,
   and to activate them in this removal-then-reestablishment of existing
   and new gateways at the end of this window.

4.2.  Handling Multiple Managers

   Devices are often modified by multiple management entities and with
   different management techniques.  It is sometimes the case that an
   element is managed by different organizations such as when a device
   sits between administrative domains.

   There are a variety of approaches that management software can use to
   ensure synchronization of information between the manager(s) and the
   managed elements.

   An agent should report configuration changes performed by different
   entities.  It should also distinguish configuration defined locally
   such as a default or locally specified configuration made through an
   alternate management interface such as a command line interface.
   When a change has been made to the system via SNMP, CLI, or other
   method, a managed element should send an notification to the
   manager(s) configured as recipients of these applicable
   notifications.  These management applications should update their

   local configuration repositories and then take whatever additional
   action is appropriate.  This approach can also be an early warning of
   undesired configuration changes.

   Managers should also develop mechanisms to ensure that they are
   synchronized with each other.

4.3.  Specifying Row Modifiability

   Once a RowStatus value is active(1) for a given row, the management
   application should be able to determine what the semantics are for
   making additional changes to a row.  The RMON MIB control table
   objects spell out explicitly what managed objects in a row can and
   cannot be changed once a given RowStatus goes active.

   As described earlier, some operations take some time to complete.
   Some systems also require that they remain in a particular state for
   some period before moving to another.  In some cases, a change to one
   value may require re-initialization of the system.  In all of these
   cases, the DESCRIPTION clause should contain information about
   requirements of the managed system and special restrictions that
   managers should observe.

4.4.  Implementing Write-only Access Objects

   The second version of the SNMP SMI dropped direct support for a
   write-only object. It is therefore necessary to return something when
   reading an object that you may have wished to have write-only
   semantics.  Such objects should have a DESCRIPTION clause that
   details what the return values should be.  However, regardless of the
   approach, the value returned when reading the object instance should
   be meaningful in the context of the object's semantics.

5.  Designing Configuration Management Software

   In this section, we describe practices that should be used when
   creating and deploying management software that configures one or
   more systems using SNMP.  Functions all configuration management
   software should provide, regardless of the method used to convey
   configuration information to the managed systems are backup, fail-
   over, and restoration.  A management system should have the following
   features:

   1. A method for restoring a previous configuration to one or more
      devices.  Ideally this restoration should be time indexed so that
      a network can be restored to a configured state as of a specific
      time and date.

   2. A method for saving back up versions of the configuration data in
      case of hardware or software failure.

   3. A method of providing fail-over to a secondary (management) system
      in case of a primary failure.  This capability should be deployed
      in such a way that it does not cause duplicate polling of
      configuration.

   These three capabilities are of course important for other types of
   management that are not the focus of this BCP.

5.1.  Configuration Application Interactions with Managed Systems

   From the point of view of the design of the management application,
   there are three basic requirements 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

   Depending on the requirements of the specific services being
   configured, many other requirements may, and probably will, also be
   present.

   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 management
   application 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 expected 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.1.1.  SET Operations

   Management software should be mindful of the environment in which SET
   operations are being deployed.  The intent here is to move
   configuration information as efficiently as possible to the managed
   device.  There are many ways to achieve efficiency and some are
   specific to given devices.  One general case that all management
   software should employ is to reduce the number of SET PDU exchanges
   between the managed device and the management software to the
   smallest reasonable number.  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 the number of variable bindings in a SET PDU also has
   benefits in the area of management application transaction
   initiation, as we will discuss in the following section.

   There are, though, agents that may have implementation limitations on
   the number and order of varbinds they can handle in a single SET PDU.
   In this case, sending fewer varbinds will be necessary.

   As stated at the outset of this section, the management application
   software designer must be sensitive to the design of the SNMP
   software in the managed device.  For example, the software in the
   managed device may require that all that all related configuration
   information for an operation be conveyed in a single PDU because it
   has no concept of a transaction beyond a single SNMP PDU.  Another
   example has to do with the RowStatus textual convention.  Some SNMP
   agents implement a subset of the features available and as such the
   management application must avoid using features that may not be
   supported in a specific table implementation (such as createAndWait).

5.1.2.  Configuration Transactions

   There are several types of configuration transactions that can be
   supported by SNMP-based configuration applications.  They include
   transactions on a scalar object, transactions in a single table
   (within and across row instances), transactions across several tables
   in a managed device and transactions across many devices.  The
   manager's ability to support these different transactions is partly
   dependent on the design of the MIB objects used in the configuration
   operation.

   To make use of any kind of transaction semantics effectively, SNMP
   management software must be aware of the information in the MIB
   modules that it is to configure so that it can effectively utilize

   RowStatus 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 that support
   management application level transactions.  One was mentioned in the
   preceding section, that transactions can be optimized by including
   the maximum number of SET variable bindings possible in a single PDU
   sent to the agent.

   There is an important refinement to this.  The set of read-create row
   data objects for tables should be sent in a single PDU, and only
   placed across multiple PDUs if absolutely necessary.  The success of
   these set operations should be verified through the response(s) to
   the Set PDU or subsequent polling of the row data objects.  The
   applicable RowStatus object(s), may be set to active only after this
   verification.  This is the only tractable means of affording an
   opportunity for per-row rollback, particularly when the configuration
   change is across table row instances on multiple managed devices.

   Finally, where a MIB module exposes the kind of helpful transaction
   management object types that were discussed in Section 3.3.5, it is
   clearly beneficial to the integrity of the management application's
   capacity to handle transactions to make use of them.

5.1.3.  Tracking Configuration Changes

   As previously described in Section 3.3.5 (Summary Objects and State
   Tracking), agents should provide the capability for notifications to
   be sent to their configured management systems whenever a
   configuration operation is completed or is detected to have failed.
   The management application must be prepared to accept these
   notifications so that it knows the current configured state of the
   devices under its control.  Upon receipt of the notification, the
   management application should use getBulk or getNext to retrieve the
   configuration from the agent and store the relevant contents in the
   management application database.  The GetBulkRequest-PDU is useful
   for this whenever supported by the managed device, since it is more
   efficient than the GetNextRequest-PDU when retrieving large amounts

   of data.  For the purposes of backward compatibility, the management
   station should also support and make use of the GetNextRequest-PDU
   when the agent does not support the GetBulkRequest-PDU.

   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, to avoid
   unnecessary load on managed devices for the most common retrieval
   operations.

5.1.4.  Scalability of Data Retrieval

   The techniques for efficient data retrieval described in the
   preceding sections comprise only one aspect of what application
   developers should consider in this regard when developing
   configuration applications.  Management applications should provide
   for distributed processing of the configuration operations.  This
   also extends to management functions that are not the focus of this
   document.  Techniques of distributed processing can also be used to
   provide resilience in the case of network failures.  An SNMP-based
   configuration management system might be deployed in a distributed
   fashion where three systems in different locations keep each other
   synchronized.  This synchronization can be accomplished without
   additional polling of network devices through a variety of
   techniques.  In the case of a failure, a 'backup' system can take
   over the configuration responsibilities from the failed manager
   without having to re-synchronize with the managed elements since it
   will already be up to date.

6.  Deployment and Security Issues

   Now that we have considered the design of SNMP MIB data for
   configuration, agent implementation of its access, and management
   application issues in configuration using SNMP, we turn to a variety
   of operational considerations which transcend all three areas.

6.1.  Basic assumptions about Configuration

   The following basic assumptions are made about real world
   configuration models.

   1) Operations must understand and must be trained in the operation of
      a given technology.  No configuration system can prevent an
      untrained operator from causing outages due to misconfiguration.

   2) Systems undergoing configuration changes must be able to cope with
      unexpected loss of communication at any time.

      During configuration operations, network elements 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.

   3) Configuration exists on a scale from relatively unchanging to a
      high volume, high rate of change.  The former is often referred to
      as "set and forget" to indicate that the configuration changes
      quite infrequently.  The latter, "near real-time change control"
      implies a high frequency of configuration change.  Design of
      configuration management must take into account the rate and
      volume of change expected in a given configuration subsystem.

6.2.  Secure Agent Considerations

   Vendors should not ship a device with a community string 'public' or
   'private', and agents should not define default community strings
   except when needed to bootstrap devices that do not have secondary
   management interfaces.  Defaults lead to security issues that have
   been recognized and exploited.  When using SNMPv1, supporting read-
   only community strings is a common practice.

   Version 3 of the SNMP represents the current standard for the
   Internet Management Framework and is recommended for all network
   management applications.  In particular, SNMPv3 provides
   authorization, authentication, and confidentiality protection and is
   essential to meeting the security considerations for all management
   of devices that support SNMP-based configuration.

6.3.  Authentication Notifications

   The default state of RFC 1215 [17] Authentication notifications
   should be off.  One does not want to risk accidentally sending out
   authentication failure information, which by itself could constitute
   a security liability.  Enabling authentication Notifications should
   be done in the context of a management security scheme which
   considers the proper recipients of this information.

   There are other liabilities where authentication notifications are
   generated without proper security infrastructure.  When notifications
   are sent in SNMPv1 trap PDUs, unsolicited packets to a device can
   causes one or 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.  At the very least, this risk should be
   mitigated by having the authentication trap PDU be conveyed with a

   community string which is only used for authentication traps from the
   agent, and would be useless for access inbound to the agent to get at
   other management data.

   A further liability of authentication traps can be seen when they are
   being generated in the face of a Denial Of Service (DOS) attack, in
   the form of a flood of PDUs with invalid community strings, on the
   agent system.  If it is bad enough that the system is having to
   respond to and recover from the invalid agent data accesses, but the
   problem will be compounded if a separate Authentication notification
   PDU is sent to each recipient on the management network.

6.4.  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.  MIB documents that are created
   in the IETF must have a 'Security Considerations' section, which
   details how sensitive information should be protected.  Similarly,
   MIB module designers who create MIB documents for private MIB objects
   should include similar information so that users of the products
   containing these objects can take appropriate precautions.

   Even if a device does support DES, it should be noted that
   configuration of keys for other protocols via SNMP Sets protected by
   DES should not be allowed if the other keys are longer than the 56
   bit DES keys protecting the SNMP transmission.

   The DESCRIPTION clause for these object types and their Security
   Considerations sections in the documents which define them 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.  Vendors should also document sensitive objects in a similar
   fashion.

   Confidentiality is not a mandatory portion of the SNMPv3 management
   framework [6].

   Prior to SNMPv3, providing customized views of MIB module data was
   difficult.  This led to objects being defined such as the following
   from [41].

   docsDevNmAccessEntry OBJECT-TYPE
       SYNTAX      DocsDevNmAccessEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry describing access to SNMP objects by a
            particular network management station.  An entry in
            this table is not readable unless the management station
            has read-write permission (either implicit if the table
            is empty, or explicit through an entry in this table.
            Entries are ordered by docsDevNmAccessIndex.  The first
            matching entry (e.g., matching IP address and community
            string) is used to derive access."
       INDEX { docsDevNmAccessIndex  }
       ::= {  docsDevNmAccessTable 1 }

   New MIB modules should capitalize on existing security capabilities
   of SNMPv3 Framework.  One way they can do this is by indicating the
   level of security appropriate to different object types.  For
   example, objects that change the configuration of the system might be
   protected by using the authentication mechanisms in SNMPv3.
   Specifically, it is useful to design MIB module object grouping with
   considerations for VACM views definition, such that users can define
   and properly scope what tables are visible to a given user and view.

7.  Policy-based Management

   In some designs and implementations, a common practice used to move
   large amounts of data involves using SNMP as a control channel in
   combination with other protocols defined for transporting bulk data.
   This approach is sub-optimal since it raises a number of security and
   other concerns.  Transferring large amounts of configuration data via
   SNMP can be efficiently performed with several of the techniques
   described earlier in this document.  This policy section shows how
   even greater efficiency can be achieved using a set of relatively new
   design mechanisms.  This section gives background and defines terms
   that are relevant to this field and describes some deployment
   approaches.

7.1.  What Is the Meaning of 'Policy-based'?

   In the past few years of output from standards organizations and
   networking vendor marketing departments, the term 'policy' has been
   heavily used, touted, and contorted in meaning.  The result is that
   the true meaning of 'policy' is unclear without greater qualification
   where it is used.

   [42] gives the term 'policy' two explicit definitions:

   -  A definite goal, course or method of action to guide and determine
      present and future decisions.  "Policies" are implemented or
      executed within a particular context (such as policies defined
      within a business unit).

   -  Policies as a set of rules to administer, manage, and control
      access to network resources.

      Note that these two views are not contradictory since individual
      rules may be defined in support of business goals.

   As it pertains to our discussion of the term 'policy-based
   configuration', the meaning is significantly more specific.  In this
   context, we refer to a way of integrating data and the management
   actions which use it in such a way that:

   -  there is the ability to specify "default" configuration data for a
      number of instances of managed elements, where those instances can
      be correlated in some data driven or algorithmic way.  The engine
      to do this correlation and activate instances from defaults may
      reside in the agent or externally.  Where the representation of
      these defaults are in the MIB design itself, the object types
      supporting this notion are referred to as "template objects".

   -  the activation of instance data derived from template object types
      results from minimal activation directives from the management
      application, once the instances of the template object types have
      been established.

   -  somewhat independently, the architecture of the overall management
      agent may accommodate the definition and evaluation of management
      and configuration policies.  The side-effects of the evaluation of
      these policies typically include the activation of certain
      configuration directives.  Where management data design exposes
      template object types, the policy-driven activation can (and
      ideally, should) include the application of template object
      instances to the analogous managed element instance-level values.

   As it pertains to template object data, the underlying notions
   implied here have been prevalent for some time in non-SNMP management
   regimes.  A common feature of many command line interfaces for
   configuring routers is the specification of one or more access
   control lists.  These typically provide a set of IP prefixes, BGP
   autonomous system numbers, or other such identifying constructs (see,
   for example, [42]).  Once these access control lists are assembled,
   their application to various interfaces, routing processes, and the
   like are specified typically in the configuration of what the access
   control list is applied to.  Consistent with the prior properties to

   define our use of policy-based configuration, a) the access list is
   defined independent from its point of application, and b) its
   application is independent of the access list definition.  For
   example, changing the application of an access list from one
   interface to the other does not require a change in the access list
   itself.  The first point just mentioned suggests what is necessary
   for template-based data organization.  The second suggests its
   application in a policy-based manner.

   Let us now examine the motivation for such a system or subsystem
   (perhaps bounded at the level of a 'template-enabled' MIB module,
   given the above definition).  Let us explore the importance of
   policy-based techniques to configuration specifically.

7.2.  Organization of Data in an SNMP-Based Policy System

   The number of configurable parameters and 'instances' such as
   interfaces has increased as equipment has become larger and more
   complex.

   At the same time, there is a need to configure many of these systems
   to operate in a coordinated fashion.  This enables the delivery of
   new specialized services that require this coordinated configuration.
   Examples include delivery of virtual private networks and connections
   that guarantee specific service levels.

   The growth in size and complexity of configuration information has
   significant implications for its organization as well as its
   efficient transfer to the management agent.  As an example, an agent
   that implements the Bridge MIB [24] could be used to represent a
   large VLAN with some 65,000 port entries.  Configuring such a VLAN
   would require the establishment of dot1dStpPortTable and
   dot1DStaticTable entries for each such virtual port.  Each table
   entry would contain several parameters.  A more efficient approach is
   to provide default values for the creation of new entries that are
   appropriate to the VLAN environment in our example.  The local
   management infrastructure should then iterate across the system
   setting the default values to the selected ports as groups.

   To date, this kind of large-scale configuration has been accomplished
   with file transfer, by setting individual MIB objects, or with many
   CLI commands.  In each of these approaches the details for each
   instance are contained in the file, CLI commands or MIB objects.
   That is, they contain not only the value, and type of object, but
   also the exact instance of the object to which to apply the value.
   It is this property that tends to make configuration operations
   explode as the number of instances (such as interfaces) grows.  This
   per-instance approach can work for a few machines configured by

   experts, but there is a need for a more scalable solution.
   Template-based data organization and policy-based management
   abstracts the details above the instance level, which means that
   fewer SET requests are sent to a managed device.

   Realization of such a policy-driven system requires agents that can
   take defaults and apply them to instances based on a rule that
   defines under what conditions the defaults (policy) are to be
   applied.  A policy-driven configuration system which is to be
   scalable needs to expose a means of layering its application of
   defaults at discrete ranges of granularity.  The spectrum of that
   granularity might have a starting hierarchy point to apply defaults
   at the breadth of a network service.

   Ultimately, such a layering ends up with features to support
   instance-level object instance data within the running agent.

   An example of this kind of layering is implicit in the principle of
   operations of a SNMPCONF Policy-Based Management MIB [36] (PM-MIB)
   implementation.  However, other entity management systems have been
   employing these kinds of techniques end-to-end for some time, in some
   cases using SNMP, in some cases using other encodings and transfer
   technologies.  What the PM-MIB seeks to establish, in an environment
   ideal for its deployment, is an adaptation between MIB module data
   which was not designed using template object types, and the ability
   to allow the PM-MIB agent engine to apply instances of that data as
   though it were template-based.

7.3.  Information Related to Policy-based 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.  Even in those cases where policy-based
   configuration is not in use, much of the information described in
   this section can be useful input to the decision-making process about
   what type of configuration operations to do.

   For this discussion it is important to make distinctions between
   distribution of policy to a system, activation of a policy in a
   system, and changes/failures that take place during the time the
   policy is expected to be active.  For example, if an interface is
   down that is included in a policy that is distributed, there may not
   be an error since the policy may not be scheduled for activation
   until a later time.

   On the other hand, if a policy is distributed and applied to an
   interface that should be operational and it is not, clearly this is a
   problem, although it is not an error in the configuration policy

   itself.  With this as background, here are some areas to consider
   that are important to making good policy configuration decisions and
   establishing when a policy has 'failed'.

   o  The operational state of network elements that are to be
      configured.

      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 installation or if
      the condition is even acceptable.  This decision is separate from
      the one to be made about policy activation.  Installation is when
      the policy is sent from the policy manager to the managed device
      and activation is turning on the policy.  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 or if the 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 [36].

      Historically, management applications have had to obtain this type
      of information by issuing get requests for objects they might want
      to use.  This approach is far less efficient since it requires
      many get requests and is more error prone since some instances
      will not exist until configured.  The new capabilities table is an
      improvement on the current technique.

   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 obtain the capacity of the managed elements to perform
      the desired work directly, 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 done 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 in a reasonable
      period of time.

7.4.  Schedule and Time Issues

   This section applies equally to systems that are not policy-based as
   well as policy-based systems, since configuration operations often
   need to be synchronized across time zones.  Wherever possible, the
   network elements should support time information using the standard
   DateAndTime TC that includes local time zone information.  Policy-
   based management often requires more complex time expressions than
   can be conveyed with the DateAndTime TC.  See the Policy-Based
   Management MIB document [36] for more information.  Some deployed
   systems do not store complex notions of local time and thus may not
   be able to process policy directives properly 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.

7.5.  Conflict Detection, Resolution and Error Reporting

   Policies sent to a device may contain conflicting instructions.
   Detection of such commands can occur at the device or management
   level and may be resolved using any number of mechanisms (examples
   are, last configuration set wins, or abort change).  These unintended
   conflicts should be reported.  Conflicts can occur at different
   levels in a chain of commands.  Each 'layer' in policy management
   system should be able to check for some errors and report them.  This
   is conceptually identical to programs raising an exception and
   passing that information on to software that can do something
   meaningful with it.

   At the instance level, conflict detection has been performed in a
   limited way for some time in software that realizes MIB objects at
   this level of resolution.  This detection is independent of policy.
   The types of 'conflicts' usually checked for are resource
   availability and validity of the set operations.  In a policy enabled

   system, there are no additional requirements for this software
   assuming that good error detection and reporting appropriate to this
   level have already been implemented.

7.5.1.  Changes to Configuration Outside of the Policy System

   It is essential to consider changes to configuration that are
   initiated outside of the policy system.  A goal of SNMP-based policy
   management is to coexist with other kinds of management software that
   have historically been instance based management.  The best example
   is the command line interface.

   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 affected, the
   instance of the element that was changed and the object and value
   that it was changed to.

   Even for those systems that have no concept of policy control, the
   ideas presented above make sense.  That is, if SNMP co-exists with
   other access methods such as a CLI, it is essential that the
   management station remain synchronized with changes that might have
   been made to the managed device using other methods.  As a result,
   the approach of sending a notification when another access method
   makes a change is a good one.  Of course this should be configurable
   by the user.

7.6.  More about Notifications in a Policy System

   Notifications can be useful in determining a failure of a policy as a
   result of an error in the policy or element(s) under policy control.
   As with all notifications, they should be defined and controlled in
   such a way that they do not create a problem by sending more than are
   helpful over a specific period of time.  For example, if a policy is
   controlling 1,000 interfaces and fails, one notification rather than
   1,000 may be the better approach.  In addition, such notifications
   should be defined to include as much information as possible to aid
   in problem resolution.

7.7.  Using Policy to Move Less Configuration Data


   One of the advantages of policy-based configuration with SNMP is that
   many configuration operations can be conveyed with a small amount of
   data.  Changing a single configuration parameter for each of 100
   interfaces on a system might require 100 CLI commands or 100 SNMP
   variable bindings using conventional techniques.

   Using policy-based configuration with SNMP, a single SET PDU can be
   sent with the policy information necessary to apply a configuration
   change to 100 similar interfaces.  This efficiency gain is the result
   of eliminating the need to send the value for each instance to be
   configured.  The 'default' for each of the instances included in the
   policy is sent, and the rule for selection of the instances that the
   default is to be applied to can also be carried (see the Policy MIB
   module [36]).

   To extend the example above, assume that there are 10 parameters that
   need to change.  Using conventional techniques, there would now be
   1,000 variable bindings, one for each instance of each new value for
   each interface.  Using policy-based configuration with SNMP, it is
   still likely that all the information can be conveyed in one SET PDU.
   The only difference in this case is that there are ten parameters
   sent that will be the 'template' used to create instances on the
   managed interfaces.

   This efficiency gain not only applies to SET operations, but also to
   those management operations that require configuration information.
   Since the policy is also held in the storage for cross-instance
   defaults (for example, the pmPolicyTable in [36]), an entire data set
   that potentially controls hundreds of rows of information can be
   retrieved in a single GET request.

   A policy-friendly data organization such as this is consistent and
   integrates well with MIB module objects which support "summary"
   activation and activation reporting, of the kind discussed in Section
   3.3.5.