[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf FW: individual submission - draft-saperia-policysnmp-00.txt



I have had a 'to do' item for a while to write up some information about the
SNMP Configuration work we have been doing in an ID form. I have been
working on this document for some time and it has undergone a number of
revisions.

Below is the request I just sent to the ID people to get the document
published. Attached to this email is the document. Note that I sent the
document in as an individual contributor, not as an SNMPCONF WG submission.
I think some of the text is valuable and have used some in the documents we
are working on.

If people are interested, I am happy to turn the document over to the WG for
future modification. If not it is an interesting document of where I believe
we are in our work and some of my ideas.

Please note that the document was originally written with a several detailed
drawings that are obviously not in the .txt.

I have placed the fancy versions on my web site and they are available in
both .ps and .pdf form.  The URLs are:

    http://www.jdscons.com/snmpconf.pdf
    http://www.jdscons.com/snmpconf.ps

Hope this helps
/jon

P.S. - Steve Moulton has agreed to place the document in archive to make it
easy for people to get at the information.
----------
> From: Jon Saperia <saperia@mediaone.net>
> Date: Thu, 06 Jul 2000 10:55:53 -0400
> To: <internet-drafts@ietf.org>, Jon Saperia <saperia@mediaone.net>
> Subject: individual submission - draft-saperia-policysnmp-00.txt
> 
> This is an initial version of an individual submission that I would like
> posted as and ID.  The file in .txt form is attached with the name of:
> 
> draft-saperia-policysnmp-00.txt
> 
> Abstract:
> 
> This paper is an introduction to terms and principles of
> policy-based network configuration management that is based on
> work in the IETF. A generic model for the realization of
> policy-based network configuration management is presented
> based on these terms. The last portion, and focus of the
> paper, examines the current work of the SNMP Configuration
> Working Group in the IETF and maps that work to the previously
> defined terms and model.
> 
> Thanks
> /jon
> 
> 

Internet Draft  Policy Configuration with SNMP    July 6, 2000


                                                    J. Saperia
                                           JDS Consulting, Inc

                Policy Configuration with SNMP
               draft-saperia-policysnmp-00.txt

                         July 6, 2000

                     saperia@jdscons.com





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.










Saperia            Expires January 6th 2001           [Page 1]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


1.  Abstract

This paper is an introduction to terms and principles of
policy-based network configuration management that is based on
work in the IETF. A generic model for the realization of
policy-based network configuration management is presented
based on these terms. The last portion, and focus of the
paper, examines the current work of the SNMP Configuration
Working Group in the IETF and maps that work to the previously
defined terms and model.



2.  Introduction

Configuration management of network elements based on a set of
rules or business objectives is not new. Payroll, order
processing systems, and many other business critical
applications have been configured to receive priority
processing in preference to other computer tasks for decades.
For years, routers have been configured to send traffic over
certain links in preference to others based on the lowest
dollar cost link versus what the routing protocols have
selected - policy-based routing.

What is driving much of the recent public discussion of policy
is the demand for improved and predictable service level
qualities - Qualities of Service (Qos).  Related to this
demand is the associated explosion in the size and complexity
of networks and the scarcity of human resources with the
requisite skills manage to them. An example of a technology
that can be used to help deliver different qualities of
service is Differentiated Services [DIFFSERV]. Since some
traffic in this and other Qos approaches is treated
preferentially over other traffic, there is also an increased
need for authentication of the monitoring and control
functions in the network. This is necessary to avoid
unauthorized use of network resources and the subsequent
reduction in service quality by those who had paid for
improved Quality of Service. This authentication needs to be
flexible since some network operators need control and
monitoring, while others need only monitoring functions. In
fact some operators may be permitted to control some functions
on a device only when accessing them from a 'secure' location.
The concern over security extends to the need in many





Saperia            Expires January 6th 2001           [Page 2]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


environments to provide protection against the unauthorized
disclosure of management information as well as protections
against modification of authorized commands.

In order to effectively make configuration decisions, policy-
based configuration tools need information about the
operational state and available resources in the network. This
information includes:


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


     -  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.


     - 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.


     -  Utilization refers to how much capacity for a
     particular capability has been consumed.


To understand policy-based configuration with SNMP and the
work of the SNMP Configuration Working group, the primary
focus of this paper, a review of some background and history
is helpful. This paper is divided into 3 Parts:

[1]  Background and recent history related to policy and
     policy based management.

[2]  Definition of terms. The meaning of policy and policy
     related terminology has been problematic. In this section
     a few terms are defined that help provide a context for
     the discussion on the approach that the SNMP
     Configuration working group is taking in this area. An





Saperia            Expires January 6th 2001           [Page 3]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     effort has been made to harmonize these terms with the
     activities of those in the Policy Working Group.


[3]  Current work of the SNMP Configuration Working Group


3.  History and Background


An examination of the archives of the Policy Framework Working
Group in the IETF [POLICY] will reveal that they have been
discussing the issue of policy-based management since the
middle of 1998. The archive is located at:

        http://www.raleigh.ibm.com/maillists/policy

The first few sentences of the charter read:

        "There is a need to represent, manage, share, and
reuse policies and policy information in a vendor-independent,
interoperable, and scalable manner. This working group has
three main goals. First, to provide a framework that will meet
these needs. Second, to define an extensible information model
and specific schemata compliant with that framework that can
be used for general policy representation (called the core
information model and schema). Third, to extend the core
information model and schema to address the needs of QoS
traffic management (called the QoS information model and
schemata)."

For additional details of the charter and the current working
group activities please reference the charter page for the
working group at:

        http://ietf.org/html.charters/policy-charter.html

During this same period of time, SNMPv3 [SNMP] moved from
PROPOSED to DRAFT STANDARD status. This important evolution is
relevant to the operational considerations associated with
policy-based management since security is an important issue
when a single high-level command can be issued that has
network wide impact.

The Resource Allocation Protocol Working Group [RAP] has been





Saperia            Expires January 6th 2001           [Page 4]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


working on policy based management for some time using
protocols other than SNMP. For additional details on these
protocols, see the reference section at the end of this
document.

The fact that there were multiple approaches caused some
concern and generated a number of papers that were reviewed
and discussed. These discussions culminated in a BOF on
configuration management at the 46th IETF held in Washington,
DC in November, 1999. One of the outcomes of that BOF was to
explore the creation of a working group that would later be
called the SNMP Configuration Working Group (snmpconf).
Additional details about the working group charter and
activities can be found at:

        http://ietf.org/html.charters/snmpconf-charter.html

This paper outlines the current state of the activities in the
SNMP Configuration Working Group and illustrates how an
effective, efficient, and integrated management system can be
built using the Internet Standard Management Framework, SNMP.
The terms used in this paper have been aligned as much as
possible with the work in the Policy Framework Working Group
as an example of an implementation of the three goals
described in the working group charter previously cited.

Using the Internet Standard Management Framework (SNMP) as the
foundation for policy-based configuration management as well
as for more traditional instance based configuration (e.g,
such as setting an IP address on an interface) provides a
powerful solution to the problem of configuration management
since it [SNMPv3] also has the extensive security
infrastructure that is also needed to ensure that resources in
the network are only used by those authorized. Policy-based
configuration management functions can be accomplished using
the existing SNMP architecture as it is today without any
changes to the framework.

The SNMP architecture provides for the definition of new MIB
modules as needs arise. In the case of both policy-based and
instance-based configuration, all that is needed is the
definition of configuration objects. The important distinction
to be made here is that some of the new objects will be
aggregate (Policy) configuration commands that can concisely
convey to the managed element a series of configuration





Saperia            Expires January 6th 2001           [Page 5]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


commands that should be executed. The new objects represent
information at a higher layer of abstraction than has been
common in previous MIB Modules.

Another advantage of using SNMP as the foundation for
configuration management is that it makes it easier to perform
other related functions of fault or performance management.
Consider how much easier it will be to understand the effect
of an interface failure or an abnormally terminated server
process if the mechanism that configured them to deliver some
policy supporting uses the same name space (MIB Object
Identifiers) as is used for fault information. For example, if
an interface fails that is supporting a customer with a
particular service level guarantee, knowing that that instance
is associated with the delivery of a policy can greatly
improve the ability to rapidly understand how service levels
are affected by failure or oversubscription.  Other approaches
do not have this direct connection. This does not mean that
each instance of configuration object in each interface must
be sent to the managed device. Rules for the expansion of the
configuration commands can be efficiently transmitted to the
managed element with just a few MIB Objects.

Later sections of this document outline how these new objects
relate to each other and the thousands of MIB objects that
have already been defined in RFCs and a large number of vendor
specific MIB Modules.



4.  Definition of Terms



4.1.  Defining the Term Policy

One difficulty for the advancement of policy-based
configuration and control of networks is the definition of
terms. The single most problematic term is policy. To begin,
policy-based management is simply a particular type of
configuration management. The distinction here is that often
the policy is expressed in terms that are neither instance or
technology specific. The configuration management that we are
most familiar with, where we might set the IP address for an
interface, tends to be technology and instance-specific. What





Saperia            Expires January 6th 2001           [Page 6]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


this means is that the configuration software knows about the
format of an IP address and how to send it to the managed
device so that it gets applied to exactly the interface
desired.


4.1.1.  What is a Policy and how does it relate to
Configuration?

Part of the difficulty with policy discussions has been that
policy is often used to describe several different concepts.
This overloading impairs our ability to communicate.

What is often unclear is the level of detail or abstraction
that the speaker intends.  For many people, policy means
business level or service level agreement expressions. For
others, policy means configuration of one or more elements in
a network to behave a certain way. For many that have thought
about the issue, policy is on a continuum that ranges from
very high level business abstractions to very low level device
configuration parameters. The distinction between all these
different levels of abstraction is the detail associated with
the expression of the policy.


4.1.2.  Terms and Relationship to Policy Framework Working
Group

Much of the information in this section is an adaptation and
expansion of a presentations given at the 47th IETF in during
the Policy Framework Working Group session. By adopting terms
used by the Policy Framework Working Group wherever feasible;
the SNMP Configuration Working Group hopes to reduce the
terminology confusion that has existed in this area. Work is
ongoing in the SNMP Configuration and Policy Framework groups
as well as others; so some change is inevitable. Here are
terms that are used to describe policy information at
different levels of abstraction moving from the most general
to the most specific.


[1]  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,





Saperia            Expires January 6th 2001           [Page 7]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     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.


     There is little in common between how one would configure
     differentiated services with how one would configure
     IPSec [IPSEC]. They may both be required for a particular
     service agreement however. For example, people who want
     to use a voice over IP application might also want to
     ensure a certain level of security for these
     communications.


[2]  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 support differentiated services and the
     applications on which they rely. Policy descriptions that
     include the details associated with a particular
     mechanism, are said to be mechanism-specific.


[3]  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





Saperia            Expires January 6th 2001           [Page 8]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     of work on the different processors for that protocol
     would be implementation-specific.


[4]  Instance-Specific. Network operators are most familiar
     and comfortable with information of this 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
     routing protocol that has a number of parameters that
     describe information about a particular router's view of
     other routers that it is sharing information with, peer
     routers. One such parameter defined in the BGP MIB Module
     [BGP MIB] 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.10.0.0.1 = 120 we would be
     looking at the retry interval of the peer router found at
     IP address 10.0.0.1. The value for this instance is 120
     seconds, instance-specific data.


     One of the goals of policy-based (configuration)
     management is to improve the efficiency of configuration
     operations. This is accomplished in part by eliminating
     the necessity of sending to the managed device a
     configuration object for every instance of that object in
     a system. For example, if we wanted to change one of the
     BGP parameters referenced above on a large system for
     each interface that is supporting the BGP, there may be
     many individual commands needed to accomplish this task.
     If a command line interface were used as the primary
     configuration tool in this example, many configuration
     commands would be needed as well.


     When we say that a a policy is at the instance
     independent level of abstraction, we mean that the value
     for a particular parameter is independent of the
     instances to which it will be applied.

     To make things more concrete, consider a voice over IP
     application. In order to 'make the sale', the service





Saperia            Expires January 6th 2001           [Page 9]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     provider must guarantee certain characteristics of the
     traffic to the customer. At a business or non-technical
     level, what the customer may want is that the voice over
     IP application traffic carried by the service prover has
     the same general characteristics as regular telephone
     service. More specifically, his might be expressed as
     'Authorized IP phone calls get enough bandwidth and
     latency and jitter control for TDM (time-division
     multiplexing) equivalent telephone service'. While this
     is important from a business perspective, it does not say
     much about how the network would be configured to deliver
     this type of service.  This is where the additional
     levels of detail are required. The increasing levels of
     detail that are needed to fully specify this service all
     the way down to specific values for specific instances
     are illustrated in the following table using the terms we
     have defined:

     TABLE 1. Increasing Detail for Each Level of Abstraction

     See .ps version of this paper for table with graphics.

     Domain-Specific (DiffServ is used for our examples):

             if sourceIPAddress == 172.3.128.0/15, && DSCP == 101110 THEN
             mark voice traffic with Expedited Forwarding.

     Mechanism-Specific:

             For DSCP value == 101110 then set Random Drop
             Parameters (e.g., RED) to be QMin (minimum queue size) = 0 and
             PMin (lowest drop probability) = 0 and QMax (maximum Queue Size)
             = 5, and PMax (maximum discard probability = 100). There is no
             MIB Module for RED currently defined, but to carry our example
             further we could create MIB Objects that would contain these
             default values:

             QMin = 0 PMin = 0, QMax = 5, PMax = 100

     Implementation-Specific:

             In this example we are not adding any implementation-specific
             parameters. Were they needed, they would appear at this
             level. One might see them as augmentations to the table shown in
             the mechanism-specific level.





Saperia            Expires January 6th 2001          [Page 10]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     Instance-Specific:

             At this level of abstraction, the specific values for each
             instance of each queue that has been selected to enforce the
             policy would be visible.  If there were just 10 queues that
             would be 40 objects with just the 4 objects that were speci-
             fied in the previous level. In our fictional RED MIB Module we
             would have a table that looked in part like:

              Index             QMin    PMin      QMax        PMax

                1                 0        0         5         100

                2                 0        0         5         100

                3                 0        0         5         100

                4                 0        0         5         100

                ...........

4.1.3.  Levels of Abstraction

A policy management system must be able to work with
information at all these levels of abstraction from the domain
to instance-specific since they are so closely interrelated. A
policy system must also make it easy to move and map from one
level of abstraction to another.

As one moves from the least specific to the most specific
level of detail, the instance-specific, the lower layer
depends on the layers above. In the BGP example we used
earlier it would make little sense to talk about a data value
of 120 without knowing what the value was describing. We use
the terms dependent and independent to describe this
relationship. Here is an examples from the previous table:


    1. Domain Dependent, mechanism, implementation and instance
    independent. If sourceIPAddress == 172.3.128.0/15, && DSCP == 101110
    THEN mark voice traffic with Expedited Forwarding. At this level of
    abstraction, notice that this policy has not been applied to any
    specific device, nor has the specific mechanism through which the
    Expedited Forwarding is to be realized been defined. We have simply
    moved to a more specific level of abstraction. In this case we have





Saperia            Expires January 6th 2001          [Page 11]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


    selected a specific technology area, Differentiated Services since
    we are using Expedited Forwarding, a term defined within that
    technology area

    2. Mechanism Dependent and Implementation and Instance Independent. If
    DSCP value == 101110 then set Random Drop Parameters (e.g., RED) to
    be QMin (minimum queue size) = 0 and PMin (lowest drop probability)
    = 0 and QMax (maximum Queue Size) = 5, etc.  Notice that this
    information is dependent on mechanism-specifics but not on any
    implementation or instance information.

A policy can be expressed, at least in theory, in a
mechanism-specific and implementation-independent fashion.
Refer back to the RED mechanism in the table, there are
several parameters that will require configuration to achieve
a particular result. People would like to express policy
configuration in such a mechanism independent way to make work
simpler. The details of the implementation from one device to
another, even when the devices come from the same vendor, make
it unlikely that mechanism-specific, implementation
independent configuration information will be deployed on
systems. Accordingly, the implementation-specific information
in Table 1 would generally be filled-in in a realization of
differentiated services by a particular vendor.

The reason for this is that while mechanism-specifics such as
routing protocols, etc.  are published as standards, most
vendors add to these standards in their product
implementations. What will be deployed more often, will be
mechanism and implementation dependent defaults that a policy
system can send to managed devices that match a particular
implementation and mechanism pair as was the case in the
routing software example in the implementation-specific
definition section. The vendor added the capability to support
features that were not part of the standard which defines
mechanism-specific details. To properly configure that
vendor's system, both the mechanism-specific as well as vendor
extensions, implementation-specific, information must be
supplied. Some vendors make these additions as a result of
customer requests or the perception that they will improve
their market differentiation. Another reason for this is that
standards are not perfect. They can be incomplete for any
number of reasons including the fact that vendors are often
able to respond more rapidly to changes in customer
requirements than the standards bodies.





Saperia            Expires January 6th 2001          [Page 12]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


5.  The SNMP Configuration Working Group

This section, and the ones that follow, describe how SNMP can
be applied to the area of policy-based configuration while at
the same time performing simple configuration tasks and all of
the other tasks to which it has been successfully applied.  An
important benefit of using SNMP for simple as well as policy-
based configuration is that with all configuration data
associated with instance level details, e.g., specific
interfaces and their status and counter values, it is much
easier to understand the relationship of faults and
utilization of resources with specific policies.  This
association still allows for the efficient transfer of
configuration commands to the managed devices in terms of the
policy levels described above. SNMP-based policy configuration
offers considerable flexibility by allowing the selection of
the level of abstraction needed for the task. It is still
possible to set individual instance level parameters as has
always been the case. This approach also provides for higher
level configuration abstractions to be sent to the managed
devices in a network which can provide a significant reduction
in the amount of information to be exchanged between the
management application and managed devices.


5.1.  Charter and Goals

The working group is examining configuration management with
SNMP in a fairly broad context. It is not limited to policy-
based configuration nor is it limited to traditional
instance-specific configuration issues. There are three
deliverables that have been chartered:


        1. A Best Current Practices document to provide guidelines on
        how to best use the existing Internet Standard Management
        Framework to perform configuration management.

        2. A MIB module which describes a network entities capabilities
        such as support for a particular type of security or a
        particular queuing method on certain interfaces. The module will
        also convey the capacity of the device to perform certain work.

        3. A MIB module which can be used to concisely convey
        information about desired network wide DiffServ Based QoS





Saperia            Expires January 6th 2001          [Page 13]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


        behavior.

5.2.  The SNMP Architecture and Configuration Model

An understanding of Policy and the different levels of
abstraction that are used when discussing policy, enables
mapping of the Internet Standard Management Framework to the
Policy Framework.

RFC 2571, An Architecture for Describing SNMP Management
Frameworks, restates some of the basic architectural
principles that have guided SNMP-based management for over a
decade. From section 1.2

        An SNMP management system contains:

         - several (potentially many) nodes, each with an SNMP entity
         containing command responder and notification originator
         applications, which have access to management instrumentation
         (traditionally called agents);

         - at least one SNMP entity containing command generator and/or
         notification receiver applications (traditionally called a
         manager) and,

         - a management protocol, used to convey management information
         between the SNMP entities.

The architecture assumes AT LEAST one management system which
implies in many cases that there is a need for more than one.
The SNMP architecture has been designed to support multiple
managers since its inception. As networks become more complex,
the redundancy possible with this architecture will become
increasingly important. For the purpose of this document, a
policy management application is a generic term. It can be any
combination of the five applications that are described in RFC
2571:  Command Generators, Command Responders, Notification
Originators, Notification Receivers, and Proxy Forwarders. A
common combination will be Command Generators combined with
Notification Receivers.

FIGURE 1. The Internet Standard Management Framework







Saperia            Expires January 6th 2001          [Page 14]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


5.2.1.  The Policy MIB Module

Given this architecture, it is a simple and low-cost matter to
add policy-enabled management within the SNMP architecture. In
fact all that is required is the addition of one MIB Module.
The SNMPCONF Working Group has named this the Policy-Based
Management MIB Module, or Policy Module for short.

FIGURE 2. The Policy MIB Module - See the .ps version.

The Policy Module helps translate from one level of
abstraction to another. It helps move from the mechanism
independent to the mechanism dependent and helps move from the
instance independent to the instance dependent level of
abstraction.

Here are some terms used in the Policy-Based Management MIB
Module. Note that Policy, Policy Filter, Policy Action and
Role definitions are from the Policy-Based Management MIB
Module draft:

    http://ietf.org/internet-drafts/draft-ietf-snmpconf-pm-
01.txt:


     Policy - in the context of the Policy MIB Module, a
     policy is expressed as: if (policyFilter) then
     (policyAction).


     Policy Filter - The policy filter is an SNMP object that
     contains an expression that results in a boolean that is
     used to determine if an element is to be a member of a
     set of objects on which an action is to be performed.


     Policy Action - The policy action object contains what
     parameters are to be modified on instances in the system
     that match the policy filter expression. These actions
     could be to turn an interface on or off, or cause the
     configuration of a complex set of objects as might be the
     case in Differentiated Services. In that case, the action
     would be expanded by the information for the policy found
     in the mechanism, and if necessary, implementation-
     specific tables. An action could also be as simple as





Saperia            Expires January 6th 2001          [Page 15]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     causing a particular device to download a new version of
     operational code.


     Role - A role is an abstract characteristic assigned to
     the element.  These abstract roles can express a
     geographical, political, financial, legal or
     architectural attribute. Most often these attributes are
     not algorithmically determinable.

     The Policy MIB Module contains standard MIB tables
     managers can populate that:


     1. Tell the managed system what policy filters to apply
     in order to select the instances to which a specific
     policy (action) should be applied.


     2. Tell the managed system what roles apply to which
     instances. We can define roles such as; serves customer
     A, or is a backup interface in tables in this MIB Module.
     For our Voice over IP customer, these could be interfaces
     that have had the role assigned to them of serving this
     specific customer and are also currently up to date on
     their premium service payments. When the managed system
     must determine to which instances to apply the policy, it
     evaluates these roles and their associations with
     instances (interfaces in our example). It accomplishes
     this function based on the filter object that is supplied
     with each policy. This filter is applied to the roles
     assigned to instances in the device, and a result list is
     created to which the configuration operations appropriate
     to the policy are applied.  Part of the filter
     specification can be information that the managed system
     can use to restrict the scope of the role search for
     efficiency purposes.


     3. Tell the managed system when and how long the policy
     should remain in effect, for example every Monday to
     Friday from 9 am to 5 pm.







Saperia            Expires January 6th 2001          [Page 16]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     4. Tell the managed system if and how to apply
     mechanism-specific such as DiffServ and instance and
     implementation independent parameters as needed to the
     instances that are appropriate to the local system. The
     mechanism-specific parameters are found in the
     mechanism-specific MIB Modules such as the Differentiated
     Services Policy MIB Module that is described in the next
     section.

     The policy MIB Module also provides important information to the management
     system. This information includes:

     1. The current state of the Policy.


     2. Global utilization information about the resources
     used by a particular policy.


     3. The mechanisms that the implementation supports. The
     Policy Module contains objects that identify the
     capabilities that the system supports. It is planned that
     standard capabilities will be published by IANA.


     4. The specific instances that are associated with one or
     more of the roles identified earlier.

     The first part of a policy in the Policy Table is a policy filter. This
     contains the roles that a specific instance must match before the policy
     action part is to be applied.  The second part is a policy action that
     contains the operations the system is to perform on instances to which
     the policy applies. The policy table also contains pointer information
     for the scheduling of a policy as well as information that can be of
     value when debugging and information about the status of each policy.

     The Role Table in the Policy Module is configured with roles strings
     that are to be associated with elements of a system under policy
     control. The role table is really two tables; first is the pmRoleESTable
     where role strings are assigned to specific elements. The pmRoleSETable
     is a read-only table indexed by role string and could be very helpful in
     debugging situations. Scheduling information is contained in tables
     external to the Policy MIB Module. That information is in [SCHED].

     In the case of differentiated services and other complex technologies





Saperia            Expires January 6th 2001          [Page 17]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     there can be many objects that need to be configured to realize a
     particular policy. Having these objects separately visible makes
     inspection and modification of parameters for such complex policies an
     easier matter and makes it possible to download policy in a mechanism
     and implementation independent fashion to the Policy Module since the
     mechanism and implementation-specific details are potentially in
     mechanism and technology specific modules.

     In the cases where mechanism-specific and instance-specific MIB modules
     have been defined, both MIB Modules should be supported. A object will
     be defined so that if a change is made to the instance-specific MIB
     Module that affects an instance under the control of a policy, the
     Policy MIB Module will be able to reflect that an object under its
     control has been changed. If present, a
     mechanism/implementation-specific MIB Module will also be able to convey
     that a change or changes have been made at the instance-specific
     level. This information can be conveyed via MIB objects that reflect the
     state of the policy.

     The Policy Module allows for the expansion of the Mechanism Independent
     to the Mechanism and Implementation Dependent, when needed, through the
     connection to the Mechanism/Implementation Dependent MIB Modules. These
     specific modules take the instances that have been selected as a result
     of the expansion of the policy filter and then expand the 'default'
     mechanism, and where appropriate, implementation-specific parameters to
     each of the selected instances.

     In some simple domains, there may be no value in both mechanism
     dependent and independent levels. An example would be policy which
     states that all devices must run the latest approved version of the
     operating system. In these cases there are not a number of different
     mechanisms and related parameters so this additional component may not
     be needed. In this case, the Policy MIB Module may interact directly
     with the instance-specific, the lowest level of abstraction,
     instrumentation in the device.The SNMP Configuration Working Group has
     developed an example of a MIB Module that converts from the mechanism
     and implementation independent methods to mechanism, implementation, and
     instance-specific levels. This MIB Module is the Differentiated Services
     Policy MIB Module.

5.2.2.  Mechanism and Implementation-Specific MIB Modules

Sometimes mechanism-specific attributes are needed to fully
specify a policy. In some cases, both mechanism and
implementation-specific attributes must be specified for an





Saperia            Expires January 6th 2001          [Page 18]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


effective policy to be configured if the vendor has added
extensions to a standard mechanism or has created a mechanism
inside a particular domain. The architecture allows for the
policy action to contain mechanism and implementation-specific
references. However, there are cases where there is value in
having this policy action include this mechanism and/or
implementation-specific information by reference rather than
by value.The value of having these separate tables pointed to
by the higher layer Policy MIB module is for facilitating good
management applications that can operate on these different
levels of abstraction as needed by the various users. This
separation also avoids unnecessarily complex configuration of
policy actions in the Policy Module and potentially makes
debugging a bit easier since the policy action is an
expression that an application would have to know how to parse
in order to reasonably present the information whereas the
mechanism and implementation-specific MIB Modules contain the
information in a form that most SNMP-based management
applications are well able to 'understand' and display.  This
helps leverage the considerable investment in our SNMP-based
infrastructure.

FIGURE 3. Mechanism and Implementation-Specific MIB Modules -
See .ps version

The part of our policy enabled system that can move from the
mechanism independent to the mechanism dependent is a
Mechanism-Specific MIB Module. Implementation-specific
attributes can be defined in a vendor specific extensions to
mechanism-specific MIB Modules since the IETF does not specify
implementation-specific mechanisms. If a vendor were to
require implementation-specific extensions to a mechanism that
has been defined, they would add them to this MIB Module,
probably through the use of an AGUMENTS clause. This approach
is identical to the approach vendors have used for the
extension of standard instance-based attributes with their
own. The SNMP Architecture was designed with this
extensibility in mind. Many vendors realize both standard and
vendor specific MIB Objects in the same software module, and
it is expected that this will also be the case when a vendor
extends IETF standard MIB modules that have been defined at
the mechanism-specific level of abstraction.

The information in the mechanism-specific MIB Module does not
always have to be located apart from the instance-specific MIB





Saperia            Expires January 6th 2001          [Page 19]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


Module. Some working groups in the future may choose to create
policy tables in their instance-specific MIB Modules. Having
the extra MIB objects, whether in a separate MIB Module as we
have for the differentiated services domain, or as extra
tables in future domain specific MIB Modules is of less
importance than having the information separately available.


5.2.3.  Instance-Specific MIB Modules

The last element to add to our architecture is the traditional
MIB module. This module is at the instance-specific level of
abstraction. It, too, can be based on an ITEF standard and
have augmentations for implementation-specific instance values
as has been common for some time. If a vendor has
implementation-specific MIB objects, they should also provide
MIB objects for these implementation-specific details at the
instance independent level (mechanism and implementation
dependent). An implementation-specific MIB module without a
corresponding instance based version of those objects would
make it impossible for an SNMP based management system to see
the instance-specific values on which the implementation-
specific MIB module is presumed to operate on.

The information sent by the management station to the
mechanism and implementation-specific MIB Modules is expressed
in Implementation and Mechanism dependent and instance
independent terms. When the policy management application
wants to have the policy activated in the managed device, a
command is issued that causes the managed element to take the
information in the Policy MIB Module and the mechanism and
implementation-specific MIB Modules and combine them to create
the implementation, mechanism and instance-specific
information used by the device. The instances are created
using the native facilities in the instance-specific MIB
modules and the values of the instances are visible in the
instance-specific MIB modules as has traditionally been the
case with SNMP-based information.

FIGURE 4. Mechanism, Implementation and Instance-Specific MIB
Modules - See .ps version.








Saperia            Expires January 6th 2001          [Page 20]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


5.3.  The process of Configuration Management

In this section we will walk through the steps an integrated
SNMP-based policy management system would take to configure a
system that is


     1. Users provide policy information to the management
     applications. In order for the policy management
     applications to correctly control policy in all of the
     managed elements, users must provide information of
     several types to the policy management applications. It
     is possible that 'users' in this case could also mean
     software that extracts information from other sources.
     The types of information needed by a policy management
     application are:


     - The filter/rules that are to be sent to each managed
     device. This is the information that is used to determine
     to what instances a policy is to be applied. This
     information will be sent to the Policy Filter object in
     the Policy Table of the Policy MIB Module. A policy could
     require several conditions to be met before an instance
     in a device is to be included. For example, the filter
     could require that the policy be applied only to
     interfaces that are Ethernet and are also connected to
     certain departments such as the accounting department. A
     different rule for another policy might require that an
     interface be an OC-12 and be connected to a particular
     carrier before the policy is applied.


     - Schedule information. Some policies are intended to run
     continuously, while others 'fire' once, and still others
     run only at specific time periods. The information that
     is to be sent to each managed device in the network that
     is to carry out this policy must be provided to the
     management application.


     - Implementation and mechanism-specific information.
     These are the details of how the policy is realized in a
     device. This is how the administratively defined policy
     and policies expressed at the implementation, mechanism,





Saperia            Expires January 6th 2001          [Page 21]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     and instance independent levels of abstraction get
     translated to something that is meaningful to a network
     device. To use our telephony example, the parameters
     would be specific to a particular vendor and perhaps even
     model. This is the instance independent information that
     is sent to the mechanism and technology specific MIB
     Modules. In the case of differentiated services, this
     information could include the values that all queues
     associated with a specific policy should use for their
     Weighted Fair Queuing parameters.


     - Many of the 'Roles' that are expressed in the policy
     filter object are not algorithmicly determinable by a
     computer system and must be assigned on each network
     device. It may not be possible for the network element to
     know that some interfaces are connected to the accounting
     department or that other interfaces are connected to a
     specific carrier. For this reason, the management
     application will have to configure the 'Role Table' in
     the Policy MIB Module. This is how the managed element
     will know that a particular interface matches or does not
     match a particular policy filter. One of the advantages
     of using SNMP for policy based management is that many of
     the 'filters' that people would want to use are already
     defined in terms of MIB objects and thus can be used
     directly. For example, the type of interface used in the
     example above would be very easy to specify to a managed
     element by giving the specific value of the object that
     contains the interface type as one of the parts of the
     policy filter.

     FIGURE 5. An SNMP-Based Policy Management System - Inputs
     - See .ps version

     Figure 5 represents inputs that are required for a policy
     enabled SNMP management system. Note that the
     architecture does not specify or assume the origin of the
     role, schedule, filter or mechanism and implementation-
     specific information. This is consistent with current
     practice in the SNMP community. Management software today
     takes inputs from humans, database systems and other
     repositories as well as a wide variety of standard and
     proprietary APIs. Also note that the architecture does
     not assume that the management applications run in a





Saperia            Expires January 6th 2001          [Page 22]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     particular location. It is likely that manager stations
     dedicated to policy or other management activities will
     be used to manage numbers of network elements at one
     time. SNMP will be the protocol used to communicate that
     management information. There is nothing inherent in the
     policy work that would prohibit a vendor from putting
     these applications on any system, mid-level manager or
     managed element.

     Configuration in an SNMP-based policy management system
     continues after the first step is completed as just
     described, see item 1 that began this section. The next
     steps are:


     2. Mechanism-specific subsystem in the managed device
     registers with policy module. The policy module has a
     capabilities table that is populated by the various
     mechanism-specific subsystems in a machine. In our case,
     the Differentiated Services Policy MIB Module would
     register with the Policy MIB Module that it is present
     and can perform Differentiated Services Functions. This
     registration mechanism would really be no different that
     the registration mechanism that many implementations of
     master and subagent technology use today. Many such
     technologies provide a way for a subagent to tell the
     master agent what MIB objects it supports when the
     subagent is started.


     3. Manager then 'knows' system capabilities (e.g., Web
     Server, VPN Support, Differentiated Services, MPLS).
     Managers will need to know the mechanism-specific details
     supported by each subsystem. In some cases it may not be
     easy to disambiguate what they are without interrogating
     the mechanism-specific subsystem (e.g., what WFQ
     parameters are supported on this system that is running a
     particular software release). There are two mechanisms
     through which a manager can 'learn' the capabilities of a
     device as represented in the capabilities table. The
     first, and preferred method, is by the managed device
     sending an INFORM to the manager whenever there is a
     change in the capabilities table. Some management
     applications may want to check the entire contents of
     these tables periodically. Note that in the case of an





Saperia            Expires January 6th 2001          [Page 23]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     SNMP INFORM, these messages are acknowledged by the
     manager so that the managed device knows the message has
     been received. An important advantage of this approach is
     that multiple management systems can be kept in sync with
     the managed devices in a network without polling and
     without having to maintain a TCP connection to every
     managed device in the network.


     4. Managers/management software send previously defined
     roles to each device and associate them with specific
     instances in the device. This is accomplished by the
     manager via sending SNMP SET operations to the Role Table
     in the Policy Module in each managed device. Roles can be
     just about anything from an indication that an interface
     marked with this role serves an Executive office, to the
     interface is a backup, to the person connected to the
     interface has not paid for premium services. Roles can be
     associated with any instance specific element, from a
     particular instance of an Ethernet interface to a
     specific instance of a Web server.


     5. Managers send policies to managed devices. This can
     take one of two forms as mentioned previously. In a
     simple case, the policyAction MIB Object contains a
     simple expression (we used the load Operating System
     version earlier). In the case where there is a great deal
     of mechanism-specific information to be conveyed as in
     the case of Differentiated Services or Routing Policy,
     then a mechanism-specific module is recommended.  The
     mechanism and implementation independent policy is loaded
     into the Policy Module by the management application and
     the implementation and mechanism-specific defaults (where
     necessary) are loaded into the mechanism and
     implementation-specific MIB Modules in the device by the
     manager. The policyFilter object in the Policy table
     contains the expression sent by the management system to
     the device that the device is to use to determine which
     instances to apply the policyAction to.


     6. Managed devices evaluate the Policy Filter and Policy
     Action Objects to determine where and when the policy is
     applied. Note that an important part of the Policy Module





Saperia            Expires January 6th 2001          [Page 24]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     is a pointer to [SCHED] that tells the system when and
     for how long to execute a policy. The expression
     contained in the policy filter contains the information
     that the managed device requires to look through the Role
     table to determine which instances of objects to apply
     the action contained in the policyAction object.


     7. Implementation and Mechanism-specific module sets
     necessary values via instance-specific subsystem. If the
     policy action indicated a mechanism and implementation-
     specific module, then the various mechanism and
     implementation-specific parameters associated with the
     policy would be applied to the instances that were the
     result of the policy filter evaluation of the Role Table.
     An important characteristic of this approach is that
     implementation-specific additions are easily accomplished
     with this approach via augmenting the mechanism-specific
     MIB Modules. This is exactly the same approach that
     vendors have used for some time to add extensions to
     standard MIB Modules for configuration and monitoring
     operations.


     8. Management software monitors usage and status to
     refine policy and verify policy changes. Since this
     approach does make it possible for a management system to
     know the instances that are being used to support
     policies, they can better monitor and control overall
     network behavior. For example, if there is an interface
     failure that is associated with a policy, a manager can
     be informed and perhaps display the policies that are
     likely to be impacted by such a failure. Additionally,
     this approach would allow more effective data collection
     of performance statistics so that vendors can better plan
     what resources they need to upgrade in order to support
     their customers before the resources reach exhaustion.

     Part of the power of an SNMP-based policy system is the
     integration of fault and other types of information in
     the same infrastructure, they use the same administrative
     framework, and share common access methods. Without the
     feedback provided by fault, utilization, performance and
     other data, it is like driving a car with your eyes shut.
     You have all the control offered by the steering wheel,





Saperia            Expires January 6th 2001          [Page 25]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


     brake and accelerator but your feedback is limited to
     what you can hear and feel when you touch something. It
     is possible to have someone tell you where you are on the
     road, or if a car is approaching, but this is far less
     effective than using your own sight that is directly
     linked to your control system, your feet for brake and
     accelerator and your hands for the steering wheel input.
     This level of indirection is even more severe if the
     person watching the road speaks a language that you
     cannot understand and must be first translated to your
     language by another unfortunate rider in your car.  The
     same is true of systems that attempt configuration
     operations without the important data noted above. It is
     possible to have another system inform the configuration
     system about faults, over-utilization, and remaining
     capacity. The additional levels of translation and
     indirection can be expensive and are not necessary if all
     the data is in a common language. We have that language,
     the SMIv2, and the MIB Objects that are defined with it.
     This is not to say languages cannot evolve - the v2
     indicates this. As new features are required for the
     future they can be added, just as new features have been
     added to routing protocols and other essential elements
     of the Internet infrastructure.

     Not included in this discussion is the important work of
     the application development that must take place. These
     applications will take information from policy servers,
     the network and humans to do the right things.

     The diagram that follows illustrates parts of an SNMP
     policy-enabled management system involved in the various
     steps described above. This example is for Differentiated
     Services, though many others are possible and expected
     over time. Users provide information to the management
     applications that the applications will use to configure
     the various network elements. This information is used by
     the network elements to evaluate the information that
     fully describes the policy and then configures the
     required parts of itself to achieve the desired behavior.

     FIGURE 6. A Complete SNMP-Based Policy Management System
     - See .ps version.






Saperia            Expires January 6th 2001          [Page 26]

Internet Draft  Policy Configuration with SNMP    July 6, 2000

5.3.1.  But Can I do Simple Configuration?

The MIB Modules described do not in any way interfere with
basic, simple configuration operations that people may want to
perform. Traditional instance based configuration operations
can continue to be used in combination with the more powerful
policy-based configuration operations.


6.  Conclusion

This document provides a framework for policy-based
configuration with SNMP and an introduction to common terms
used in that framework. The SNMP Configuration Working Group
has not yet completed its initial work though substantial
progress has been made on all of the documents it is working
on. It is now clear that with just a few MIB Objects, it is
possible to create a powerful, efficient and integrated policy
management system using the Internet Standard Management
Framework. It is also clear that this approach to policy based
management maps well to the work undertaken in the Policy
Framework Working Group.


7.  Acknowledgments

Many ideas in this paper have been informed by conversations
with and comments by my colleges. I would like to acknowledge
their contribution to my understanding of the problem. A few
individuals that have made special contributions I would like
to acknowledge: Andy Bierman, Jeff Case, Joel Halpern, Bob
Quinn, John Schnizlein, John Strassner, Steve Waldbusser,
Walter Weiss, and the other members of the editing team that
have contributed to the SNMP Configuration documents, Harrie
Hazewinkel, Thippanna Hongal, Mike MacFaden, and David
Partain. Some individuals have also provided feedback on
numerous revisions of this document. I would also like to
thank the SNMPCONF co-chair, David Harrington, for his
detailed editorial review of several drafts of this document.


8.  General References to Web Pages

Here is a list of URLs to the various documents or working
groups that may be of interest referenced in this paper. The





Saperia            Expires January 6th 2001          [Page 27]

Internet Draft  Policy Configuration with SNMP    July 6, 2000

working group pages contain some of the summary information
used in this document as well as pointers to relevant IDs as
well as many of the RFCs that are of interest.
[SNMPCONF]

Configuration Management with SNMP (snmpconf):

     http://www.ietf.org/html.charters/snmpconf-charter.html

[POLICY]

Policy Framework (policy):

     http://www.ietf.org/html.charters/policy-charter.html

[RAP]

Resource Allocation Protocol (rap):

     http://www.ietf.org/html.charters/rap-charter.html

[SNMP]

SNMP Version 3 (snmpv3)

     http://www.ietf.org/html.charters/snmpv3-charter.html

[DIFFSERV]

Differentiated Services (diffserv)

     http://www.ietf.org/html.charters/diffserv-charter.html

[IPSEC]

IP Security Protocol (ipsec)

     http://www.ietf.org/html.charters/ipsec-charter.html

[INTSERV]

Integrated Services (intserv)

     http://www.ietf.org/html.charters/intserv-charter.html




Saperia            Expires January 6th 2001          [Page 28]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


[BGP MIB]

     ftp://ftp.isi.edu/in-notes/rfc1657.txt

[SCHED]

Definitions of Managed Objects for Scheduling Management Operations

     ftp://ftp.isi.edu/in-notes/rfc2591.txt








































Saperia            Expires January 6th 2001          [Page 29]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


9.  References

[1]  Harrington, D., Presuhn, R., and B. Wijnen, "An
     Architecture for Describing SNMP Management Frameworks",
     RFC 2571, April 1999.

[2]  Rose, M., and K. McCloghrie, "Concise MIB Definitions",
     STD 16, RFC 1212, March 1991.

[3]  Rose, M., "A Convention for Defining Traps for use with
     the SNMP", RFC 1215, March 1991.

[4]  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.

[5]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
     Rose, M., and S. Waldbusser, "Textual Conventions for
     SMIv2", STD 58, RFC 2579, April 1999.

[6]  Case, J., Harrington D., Presuhn R., and B. Wijnen,
     "Message Processing and Dispatching for the Simple
     Network Management Protocol (SNMP)", RFC 2572, April
     1999.

[7]  Blumenthal, U., and B. Wijnen, "User-based Security Model
     (USM) for version 3 of the Simple Network Management
     Protocol (SNMPv3)", RFC 2574, April 1999.

[18] 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.

[9]  Levi, D., Meyer, P., and B. Stewart, "SNMPv3
     Applications", RFC 2573, April 1999.

[10] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
     Access Control Model (VACM) for the Simple Network
     Management Protocol (SNMP)", RFC 2575, April 1999.

[11] Case, J., Mundy, R., Partain, D., and B. Stewart,
     "Introduction to Version 3 of the Internet-standard
     Network Management Framework", RFC 2570, April 1999.





Saperia            Expires January 6th 2001          [Page 30]

Internet Draft  Policy Configuration with SNMP    July 6, 2000

10.  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.


11.  Authors' Addresses


     Jon Saperia
     JDS Consulting
     174 Chapman Street
     Watertown, MA 02472
     email - saperia@jdscons.com



12.  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





Saperia            Expires January 6th 2001          [Page 31]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


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 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.




























Saperia            Expires January 6th 2001          [Page 32]

Internet Draft  Policy Configuration with SNMP    July 6, 2000


Table of Contents

^
1 Abstract ..............................................    2
2 Introduction ..........................................    2
3 History and Background ................................    4
4 Definition of Terms ...................................    6
4.1 Defining the Term Policy ............................    6
4.1.1 What is a Policy  and  how  does  it  relate  to
     Configuration?  ....................................    7
4.1.2  Terms  and  Relationship  to  Policy  Framework
     Working Group ......................................    7
4.1.3 Levels of Abstraction .............................   11
5 The SNMP Configuration Working Group ..................   13
5.1 Charter and Goals ...................................   13
5.2 The SNMP Architecture and Configuration Model .......   14
5.2.1 The Policy MIB Module .............................   15
5.2.2  Mechanism   and   Implementation-Specific   MIB
     Modules ............................................   18
5.2.3 Instance-Specific MIB Modules .....................   20
5.3 The process of Configuration Management .............   21
5.3.1 But Can I do Simple Configuration?  ...............   27
6 Conclusion ............................................   27
7 Acknowledgments .......................................   27
8 General References to Web Pages .......................   27
9 References ............................................   30
10 Intellectual Property ................................   31
11 Authors' Addresses ...................................   31
12 Full Copyright Statement .............................   31




















Saperia            Expires January 6th 2001          [Page 33]