2.4.11 Policy Framework (policy)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00


Joel Halpern <joel@longsys.com>
Ed Ellesson <ed_ellesson@tivoli.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion:policy@raleigh.ibm.com
To Subscribe: policy-request@raleigh.ibm.com
In Body: subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy

Description of Working Group:

Note: Russ Mundy is the Security Technical advisor for this WG.

Problem Statement:

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). For now, only a directory schema will be defined. Third, to extend the core information model and schema to address the needs of QoS traffic management (called the QoS information model and schemata).

The viability of the framework will be proven by demonstrating that high-level policy information can be translated into device configuration information for network QoS applications. This requires the coordination of the core and QoS schemata, the PIB and MIB being developed in DiffServ, and possibly extensions to COPS provisioning, which is being developed in RAP. A secondary goal of this framework is to show that this general development process can be extended to other application domains.


The objectives of this working group are to:

1. Identify a set of representative use cases to guide us in defining a policy framework, information model, and schemata to store, retrieve, distribute and process policies. These use cases should map to a set of policy rules, and aid us in defining the composition of policies.

2. Define a framework for intra-domain policy definition and administration for a heterogeneous set of Policy Decision and Enforcement Points. Here, "intra-domain" refers to policy components that are all under the same (and exclusive) administrative control. The framework will be shown to be able to be used to represent, distribute, and manage policies and policy information in an unambiguous, interoperable manner in a single administrative domain. This framework will be applied to network QoS.

3. A general information model, derived from the CIM/DEN policy model, will be produced. This is intended to serve as a generic means for representing policies and policy information. In addition, a mapping of this information model to a form that can be implemented in a directory that uses LDAPv3 as its access protocol will also be done.

4. Refinements to the above, for representing signaled and provisioned QoS, will be done. That is, both the information model as well as the schema will be extended to focus on network QoS. This will also be used to prove the general extensibility of the model.

5. A key part of demonstrating that this model can provide end-to-end translation of high-level policy specifications to device configurations is to ensure that the information model and schemata are compatible with and can use the information contained in the PIB(s) and MIB(s) being developed in the Differentiated Services WG. To this end, the Policy Framework WG will supply input to the development of the PIBs, and include all applicable PIBs and MIBs in its development considerations for the framework, information model, and schemata.

6. Policy information may be communicated using several protocols. The COPS protocol, being developed in the RAP WG, is an example of one such protocol. The Policy Framework WG will work with the RAP WG to define usage directives for use of the COPS base protocol to support policy information exchange transactions within the framework being standardized in the Policy Framework WG.

7. The Policy Framework WG will work closely with the IPSP WG to ensure that the IPsec data model fits and can be supported within the general framework defined by the Policy Framework WG.

8. The Policy Framework WG will work with other WGs as needed to ensure that the framework, information model, and specific schemata produced meet the needs of these WGs.

9. The charter specifically excludes:

-protocol definition

-schema attributes or classes that are vendor-specific (although the schema defined in this group will be defined in a way that is extensible by specific vendors)

Goals and Milestones:

Mar 99


WG Last Call for FYI RFC

Aug 99


WG last call on Policy terminology draft (Informational Track)

Aug 99


Submit Internet Draft on Use case definition (Informational Track)

Sep 99


WG last call on Core information model draft (Standards Track)

Oct 99


WG Last Call on Use case definition (Informational Track)

Dec 99


WG Last Call on Framework draft (Informational Track)

Mar 00


WG Last Call on QoS Schema draft(s) (Standards Track)


No Request For Comments

Current Meeting Report

Summary and Minutes
Policy Framework Working Group Meeting
49th IETF, San Diego
Submitted by Ed Ellesson, January 7, 2001

Charts submitted separately to minutes@ietf.org

1. Summary and Action Items, combined from both wg sessions:

1.1 QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath Device Info Model)

-Differences with DiffServ are now resolved

-Expect name change to the QDDIM draft to reflect generic qos datapath focus for traffic handling and conditioning (ie. not just diffserv), but qos signaling (control plane) will continue to be out of scope for this document.

* Action: Bob Moore

-Schedulers/Queues relationship: Expect co-author consensus to be posted on the policy mailing list, in approximately two weeks.

* Action: Walter Weiss

1.2 QPIM: (QOS Policy Information Model)

* Action: QPIM Authors:

-Overlap and linkage with QDDIM: Need added text/terminology to describe how/why policy objects are approached differently in QPIM, than from device level view in QDDIM.

-Further clarification may be added to describe distinctions among the following functions: Configuration, policy (operational behavior), and state.

-QPIM continues to be device independent, and mechanism independent. Examples are needed that show the abstraction level for QPIM, including policy vs. mechanism.

-A new PCIM extensions draft will be written, which describes generic PCIM functions that can be broken out separately from the current QPIM draft (ie. those that are not QOS-specific. The first phase of this was agreed to be done by the current QPIM authors, themselves.

-RSVP with diffserv in the same network. Positioning statement needed for this situation.

1.3 ICIM (IPSP Configuration Information Model):

-The content of this document is owned by the IPSP working group.

-Our liaison with IPSP (Lee Rafalow) will take a look at similarities with QPIM, to determine if there is any reason to recommend further harmonizing any of the functionality there with QDDIM or QPIM approaches, such as in the area of sequenced actions.

1.4 Packet classification work effort proposed:

-Small design team will be formed to clearly document the motivations for the differing approaches to packet classification across QDDIM, QPIM and ICIM. This team will clearly express the design goals of each approach.

*Action: Volunteers to contact WG chairs

-Consideration will be given, to converge or not, the four approaches to packet classification presented by Bob Moore:

a) single field generic (filter entry)
b) variables/operators/values (qpim)
c) single field specific (ipsp's icim)
d) multi-field specific (6-tuple)

-Consideration will be given to documenting this in the separate, common document, (see above) which defines general purpose mechanisms, or to document why general purpose approaches are not appropriate. These guidelines will be intended to guide further application of our models to other domains.

-If multiple approaches continue to exist after this design team effort, mapping the methods, one to the other, will need to be documented.

1.5 Terminology Draft:

-Expect document rev in a few weeks, then working group Last Call.

* Action: Andrea

1.6 PCLS (Policy Core LDAP Schema):

-Expect another rev with recent input from mailing list, and a new security considerations section.

*Action: Ryan Moats, Bob Moore and Ed Ellesson.

-Expect this document to be ready for last call next month.

1.7 MPLS Policy:

-Authors will discuss potential homes for this work with wg chairs, and the appropriate AD's . The Policy Framework wg charter does not cover this. As a general rule, it is expected that further application of the policy model, beyond qos, will be accomplished within technologly-specific working groups, which is where the subject matter experts are for those technical domains. This is similar to the way mibs/pibs are developed.

* Action: Joel will help by discussing this with the chairs and/or AD's for MPLS.

1.8 Charter Milestones:

The co-chairs will work with Bert on a new set of wg charter-milestones, now that our first document (PCIM) has been approved for advancement to Proposed Standard.

* Action: Joel and Ed

2. Detailed Minutes from the Monday, December 11 Session:

-The order of the minutes is in the order of the agenda topics.

2.1 Intro/Objectives/Milestones: Joel Halpern:

-Welcome. Thanks to the many authors who have worked to get drafts for this meeting.

-However, we are WAY behind schedule.

-Particular items of note that need to be worked on include:

a) Framework
b) Requirements
c) Use Cases
d) Terminology

-The QPIM and QDIM work has made some significant progress.
Remember: "A key part of demonstrating that this model can provide end-to-end translation of high-level policy specifications to device configurations is to ensure that the information model and schemata are compatible with and can use the information contained in the PIB(s) and MIB(s) being developed in the Differentiated Services WG. To this end, the Policy Framework WG will supply input to the development of the PIBs, and include all applicable PIBs and MIBs in its development considerations for the framework, information model, and schemata." So we need to get QPIM and QDIM aligned with each other and with the diffserv work. QDIM is now much more closely aligned with diffserv than in the past. Cooperation with DiffServ here is a key goal.

-Similarly, we need to work with the IPSP folks to align the usage of the model there. We will work to put together a new schedule.

2.2 Agenda Bash. No changes for now. (see later changes to second day's agenda)

2.3 QDDIM Issues Presentation: Bob Moore

-Bob's charts were also presented in the DiffServ working group, just prior to this Policy Framework meeting. Some of the decisions on these issues are DiffServ's to make, since they are the owners of the diffserv conceptual model, mib, and pib, with which we want to be consistent.

-The word "device" was added to the title, to reflect the fact that rsvp is no longer included in the initial focus of this document.
(It proved to be too hard to reach closure on both diffserv and rsvp at the same time.)

-See the charts that Bob presented, for the details of each specific issue.

* Issue 1: On whether the QDDIM Scheduler class is to be a subclass of Condition:

-It was decided that Scheduler is, indeed, to be a subclass of Condition.

* Issue 2: should scheduling disciplines be modeled as associations or as classes?

-Walter: It turns out that the DiffServ MIB will not allow one approach, but the conceptual model will support it. The question is: should we align with the mib or the informal conceptual model?

-Andrea, Walter, John Strassner and Dave Durham all had opinions on which was a better representation, and the vote among them was split. The decision was to revisit this...see the summary for the resolution.

* Issue 3: How should the tail drop and head drop dropping algorithms be represented?

-The resolution is that the the DiffServ working group will loosen the language in the conceptual model to allow for the dropper to be represented either before or after the queue, and the MIB will be tightly defined, as it is now, to include a property to describe a dropper as tail drop or head drop. This leaves the policy working group clear to document the model as we are doing it now.

* Issue 4: Bob described a taxonomy for the four ways to represent filters, used across multiple documents in our working group.

-We will take up this topic for discussion in the Wednesday session, after the ICIM presentation.

2.4 QPIM Issues Presentation: Ron Cohen

-QPIM includes PCIM extensions, including those that are QOS-specific (both diffserv and intserv), as well as those that are useful beyond just the QOS discipline.

-See Ron's charts for a complete list of the changes from the last draft of the QPIM document and for the generic and qos-specific extensions included there.

-Generic Extensions to PCIM include the modeling of variables and values, which allows for the reuse of values, and for specifying value constraints, and for adding new variables and values without changing the syntax. See the charts for other extensions.

-Mapping to the DiffServ MIB is supported.

-Reuse and "domain-wide" application of QPIM, are the primary drivers for organizing the model the way it is currently.

-Missing Pieces:

* a model of the "capabilities" functionality in the PIB

* an approach for binding roles to entities

-Status of QPIM: The last call on this document forced discussion, and the feedback was valuable and incorporated into the current draft.

2.5 QPIM and QDDIM Compatibility with DiffServ Discussion Moderators: Joel and Ed

-On QPIM relationship to QDDIM: This relationship is not formally documented in the QPIM document. John Strassner commented that this is a "works with" relationship, rather than a "mapping" relationship, between QPIM and QDDIM.

-Bob Moore questioned the issue about DSCP markers not having two values. This may need to be clarified. Also, Bob suggested not reusing the class names from the QDDIM model, in the QPIM model, since that could cause confusion.

Ron accepted this last comment as a valid point.

-Andrea expressed the opinion that a mapping from QPIM to QDDIM is, indeed, required. We also need to work on clarifying the "configuration" vs. "state" issue.

-It was agreed that a new PCIM extensions document would be created, and the relevant parts of QPIM that are generically applicable, would be pulled out and documented separately. The QPIM authors will articipate, as well as volunteers, as they come forward.

-Lee Rafalow: Not convinced that the following aspects of QPIM are justified: complexity of "atoms" approach, compound conditions, and Rules within Rules.

-Yoram Bernet requested that more attention be given to admission control, and to those conditioning services that are in common to both intserv and rsvp.

-Shai Herzog questioned the level of the policy documented here...is it "mechanism" or is it "policy"?

2.6 Monday's Session Wrap-up:

-See Section 1, above, for the combined summary of both Monday and Wednesday sessions

3. Detailed Minutes from the Wednesday, December 13 Session:

3.1 Intro and News: Changed the agenda to continue the discussion of Queues and Schedulers. See the sixth item on the agenda (item 3.6, below).

3.2 ICIM: IPSP Policy Model Presentation, Lee Rafalow:

-Lee suggests that we harmonize among the various document authors on appropriate re-usable components for packet classification, across the several documents which address this.

-See Lee's charts for his review of the IPSP (ICIM) Model.

* Basic model structure

* Filter-based conditions

* Actions, Proposals, and Transforms

-Discussion Points:

-Differences between the multiple models that do packet classification were reviewed. Lee noted the different objectives for each model, which motivated the different approaches. See the charts.

-Semantics of subclassed condition class, as used in the ipsp's icim model, are specific to the ipsec negotiation, which can change from true to false, as more info is received about the security association. This is a different semantic than in the case of QOS.

-Grouping differences were also discussed.

-Evaluation order is always determined ahead of time, in IPsec policy. This is always mandatory, but the semantic is different from the mandatory semantic in the rest of the policy model. The semantic is: "Try this first, and if it does not work try the next one."

-Roles: As used in the policy model, roles represent a binding of policy to interfaces. This is not the appropriate semantic for IPsec, so the PolicyRole object was not used. Instead, the ipsp icim model uses IdentityContexts.

-The IPSP model is more oriented toward individual device policy, like QDDIM, rather than the domain level, like QPIM, but the IPSP model derives from the policy classes, like QPIM does.


* Strassner: QPIM differences have to do with the reusability of the classes, without binding to specific devices.

* Ron Cohen: Sequenced actions: There is a similar function in QPIM, with a selector, for path messages. Suggests we take a look at whether we should have the same basic approach in both QPIM and IPSP's ICIM

* ICIM is a model for the PDP to PEP configuration function; it is not a domain level model

* Rules are "leaf" objects in the IPSP's ICIM model

3.3 Applying and Linking Policy Discussion (including the discussion about packet classification)

-Proposed objective: Harmonize the reusable components across the documents which describe how to represent policy for packet classification, or clearly document why there are differences, due to different design points, different disciplines, etc. Are the semantics really different?

-Walter Weiss: Questions whether the IPSP's ICIM model should be handling both levels in one model. Conditions and Actions, can one thing be both?

-A work effort is proposed: mapping the different approaches, one to the other.

-Reuse of instances vs. reuse of classes: this motivates some of the differences in QPIM.

-The usefulness of the QPIM "atoms" approach might drive the QPIM method of representing filters, as being different from other models. On the other hand, maybe convergence of documentation is called for: perhaps a single document which describes the generic approaches, and when each is called for: single field generic (filter entry), variables/operators/values (QPIM), single field specific (ICIM), multi-field specific (6-tuple).

-A separate document is proposed to split out the portion of QPIM that documents functions, such as packet classification, that can be re-used across multiple disciplines, with an explanation of the different approaches that remain, if they do indeed remain after the attempt to harmonize them. The current authors of the QPIM document will take the lead with this effort, but volunteers are encouraged, as well. We may do this in a two-step process, with the current authors taking the first shot at the generic document.

-The MPLS needs for packet classification should also be taken into account, since this is also valuable experience that we can learn from for the purpose of coming up with a generic approach.

-Example: "Source Port = 80" appears to be in all the models.

-There is controversy about this point: The distinctions between QPIM and QDDIM may be defensible, given the difference in their scope (network domain-wide scope, vs. device level scope), but what about ICIM (the IPSP's model), which appears to be device-level? But we should be able to articulate the reason that any differences remain, if we can.

-The topic of policy languages came up. This is not in our charter, but Andrea suggested we might want to look at the language constructs developed by Morris Sloman at Imperial College in London.

-There was also a question about how SNMP handles differences in mibs. Does the SNMP area directorate push back on working groups that taken different approaches to the same problem?

Bert: Yes, the Ops and Management area pushes back on working groups that want to go a different way, but the AD's are not always successful in pushing for common approaches. Despite the best of intentions, there are mibs that provide duplicate function in different ways.

(BTW: Wasn't Policy supposed to solve this?)

3.4 PCLS Update: (Ryan Moats and Ed Ellesson)

-Changes for the -08 version: Please see Ryan's charts for details.

-Ryan reviewed the syntax changes from the previous version, as well as other changes, including an issue associated with matching rules, and the fact that there will be a -09 version shortly, with new aux classes, and a new security considerations section.

-Security Considerations section: Please see Ed's charts for details.

-Ed reviewed the security considerations which will be re-written for the next version. The challenge is to make sure that all the necessary security considerations are covered, across the multiple documents which complete the standardized "policy package" of documents for any specific discipline.

-For example, the QOS group of policy documents will include the core policy documents, PCIM and PCLS, as well as the QOS-specific policy info model (QPIM), and the device level info model for QOS (QDDIM), plus whatever the appropriate mapping of these QOS- specific models turn out to be, to an LDAP-accessible directory.

-The security considerations sections of all these documents taken together, have to cover all the appropriate issues for applying QOS policy in a real world environment. The security considerations section of PCLS is part of this total coverage.

-Please contact Ed if you want to contribute to this section.

3.5 Polterm Harmonization: Andrea Westerinen

-See Andrea's charts.

-The team which created this draft was successful in achieving its goal: to finalize common policy terminology across multiple working groups, without creating new terms.

-The team resolved the conflicting use of the term Policy Rule in different wg's

-Polterm draft will be revised with changes discussed in presentation and sent to last call.

-References to I-D's will be removed and maintained separately in a cross-reference table linked from the policy framework working group's home page.

3.6 Queues and Schedulers: Walter Weiss

-See Walter's charts. This is meant to provide a context for continuing the discussion from Monday on this topic.

-In the current QDDIM model, we have greater flexibility in representing queues and schedulers than is currently available in the DiffServ mib with SMIv2. This was accepted as not being a problem, since individual vendors may extend the DiffServ mib in proprietary ways, and we want the QDDIM model to be able to map to these extensions, if possible, to the extent that we can anticipate them.

-Brian Carpenter stated that the DiffServ working group's criteria for including something in the DiffServ mib is that it be expressible, and that vendors want it there. Further, it should be clear that QDDIM does not drive the content of the DiffServ mib.

-There was considerable discussion of the six charts which Walter presented, which described the pro's and con's of different ways of representing queues, schedulers, and their relationships to each other.
This presentation and discussion further clarified the issues, and will be used to help the QDDIM authors come to an agreement for finalizing how that model will represent queues and schedulers and their relationships.

3.7 Use of Policy in AAA Architecture: Cees de Laat

-See charts from Cees de Laat, at:


-Cees presented the policy work that is going on in the IRTF, under the AAA Architecture working group.

-This working group has an inter-domain focus and an architectural focus, which differentiates it from the work in the policy framework working group, in addition to the fact that they are working on AAA.

3.8 Use of Policy in MPLS: Ritu Chadha and Marcus Brunner

-Ritu presented the changes and convergence from the first drafts which dealt with MPLS policy. The authors re-used a number of the ideas for packet filtering, roles and other functions, from the QDDIM and QPIM drafts.

-Marcus presented the open issues, including the fact that MPLS policy has not been accepted as a charter item by any IETF working group, including policy framework, mpls, and traffic engineering.

-Joel committed to talking to the chairs of the mpls and tewg to help determine the appropriate home for this work. It seems appropriate to host this work where the subject matter experts are (mpls or tewg), with help provided from policy liaison people who have experience in applying the policy information model.

3.9 Wrap-up: See Section 1 of these minutes for the combined summary for both sessions.


Properties on Associations
IPSP Configuration Model Framework Feedback
Policy Framework MPLS Information Model for QoS and TE
PCLS Syntax Changes
PCLS Security Considerations
Policy Terminology - 01
QDDIM-02 Issues