Current Meeting Report
Slides


2.3.13 Policy Framework (policy)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 04-Dec-01
Chair(s):
Joel Halpern <joel@stevecrocker.com>
Ed Ellesson <eellesson@lboard.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@ietf.org
To Subscribe: policy-request@ietf.org
In Body: subscribe your_email_address
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.

Objectives:

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:
Done   PCIM submittal for Proposed Std Status
Done   PCLS working group last call
Done   Terminology draft wg last call (fyi track)
Jul 01   QDDIM Final Draft and wg last call
Jul 01   QPIM Final Draft, and wg last call
Done   PCIM Extensions Final Draft, and wg last call
Aug 01   QPLS Final Draft, and wg last call
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC3060PSPolicy Core Information Model - Version 1 Specification
RFC3198 Terminology for Policy-Based Management

Current Meeting Report

52nd IETF, Salt Lake City
Minutes of Policy Framework WG (policy)

Tuesday, December 11 at 1700-1800
===================================

CHAIRS:
Joel M. Halpern <joel@stevecrocker.com>
Ed Ellesson <eellesson@lboard.com>

AGENDA:

1. Agenda Bash: (Ed)

Only change: None of the QPIM authors could be here in Salt Lake City, so Joel will review the status charts sent by Yoram Ramberg for the QPIM agenda item (see below).

2. Review of document status (Joel)

http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-13.txt (pcls: sent to IESG for approval as proposed standard)

http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-04.txt (qpim: revised to be consistent with pcime)

http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-06.txt (qddim: revised to be consistent with pcime)

http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-04.txt (polterm: now RFC3198, thanks to all the authors and esp. Andrea Westerinen for leading the effort.)

http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-06.txt (pcime: Bert Wijnen has some feedback for us on the PCIMe document, but there is some confusion about the status of those comments, where they are, etc. Bert will be looking into that.)

-Authors/editors needed: There are three remaining mapping documents that we will need in order to show interoperability: pcls-e, qpls, and qdls.

3. QDDIM Issues (Joel)

http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-06.txt

>From Bob's Moore's Charts and Notes, presented and reviewed by Joel:

Technical changes since QDDIM-05:

-PreambleFilter / PreambleMarkerService generalized (Paragraph's 3.8.3, 4.3.13, 4.3.34).

-Queue / Dropper updates (3.10, 3.10.2, 4.3.30, 4.4.6).

-HeadTailDropQueueBinding clarified (3.10, 3.10.1).

-Cardinality change for ElementInSchedulingService (4.4.28).

-QoSService moved to inherit directly from Service (4.2, 4.3.23).

-AllocationPercentage property added to the QueueAllocation association (4.4.10).

Issues to discuss in SLC (or on the list) for QDDIM-06:

A. How do we apply here the lessons learned in PCLS and PCIMe related to specifying agent behavior in response to unexpected / illegal values? Should we specify what an application should do when the values are out of range? If we do this, we should do it in the model before it is mapped to an LDAP schema.

Action: Agreed. This issue needs to be addressed in the QDDIM document. Bob Moore to supply suggested text.

B. It would help scalability if we had a way to represent reusable combinations of ClassifierElements, very similar to CompoundPolicyConditions, which could be combined to form Classifiers.

Discussion:

On the topic of the list of filters, Walter Weiss suggested that it would be better to represent classifiers hierarchically by set, or bundle, rather than to re-specify for each group of users. The relevant PIB did something to add hierarchy, so seems reasonable to do this in the QDDIM model.

Andrea Westerinen and Walter discussed whether the classifier service provide the needed grouping, or whether whether this should be done in the filter. The question has to do with how to collect the classifiers and bind them into specific sublists, and then how to make larger supersets out of these groups. Perhaps "Next Service" could do this.

Action: Andrea and Walter will work offline together and propose text for the QDDIM document, to use associations to enable something like this grouping idea, since it seems to add substantially to the power of what the model can represent and reuse.

C. Alignment of QDDIM's BufferPool class with CIM's StoragePool class.

No work to be done here. You represent what is behind the queue as a buffer pool. Andrea explained that a StoragePool in CIM is not the same thing (amorphous blobs) and can't be used for what we need in QDDIM.

D. QoSService subclasses: There is the appearance of overlap between these subclasses and ConditioningServices, and ClassiferElements.

Discussion: ConditioningService is alligned with the diffserv and intserv pibs, so that is ok, and should not be changed. Agreed.

However QOSService does some of the same things, but something is needed in this area to complete the mapping to diffserv.

Action: Joel and Andrea will put together the needed words to clarify. Need to cleanup the phb words, and make sure all the diffserv funtionality is covered.

4. QPIM Issues (Joel)

http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-04.txt

Status:

Per the authors, all known outstanding issues are resolved, and the comments from the mailing list and the London meeting have been addresses. (Only comment received since -04 was a typo.)

Changes since London were reviewed. (See the charts)

These include changes due to the updates to PCIMe, which incorporates generalizable policy concepts from earlier versions of QPIM, which are applicable to more than just QOS types of policies.

Action: Chairs will progress QPIM to last call in the next few weeks, subject to input from mailing list.

5. Wrapup of WG Status and Actions: See charts labeled "Policy Framework WG Agenda and Summary".

6. Next Meeting: Intention is to finalize the work on the mailing list and not require a meeting in Minneapolis.

Submitted:
Ed Ellesson, with Joel Halpern
Co-chairs, Policy Framework Working Group

Slides

Agenda
QDDIM Status and Issues
QPIM-04