NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Joel Halpern <joel@longsys.com>
Ed Ellesson <eellesson@lboard.com>
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Bert Wijnen <bwijnen@lucent.com>
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
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)
Done |
|
PCIM submittal for Proposed Std Status |
Apr 01 |
|
PCLS working group last call |
Apr 01 |
|
Terminology draft wg last call (fyi track) |
Jul 01 |
|
PCIM Extensions Final Draft, and wg last call |
Jul 01 |
|
QDDIM Final Draft and wg last call |
Jul 01 |
|
QPIM Final Draft, and wg last call |
Aug 01 |
|
QPLS Final Draft, and wg last call |
· Policy Framework LDAP Core Schema
· Requirements for a Policy Management System
· Policy Framework QoS Information Model
· Information Model for Describing Network Device QoS Mechanisms
RFC |
Status |
Title |
RFC3060 |
PS |
Policy Core Information Model - Version 1 Specification |
Minutes of Policy Framework Working Group: (Charts also attached)
First Session: (Monday, August 6, 1300-1500)
1. Agenda Bash: Ed Ellesson reviewed the agenda, which ended up as on the charts attached. The following minutes are in the same order as the agenda.
The agenda incorporated the following changes from what was previously submitted, before the meeting:
Added Cees de Laat and Andrea Westerinen to the agenda.
No comments or objections.
2. Cees De Laat: New IRTF Policy Language Draft
Cees mentioned that the AAAARCH IRTF wg has completed a draft on a policy language that they would like input on from policy wg members. He also stressed that they are chartered to work on topics that we cannot, like inter-domain policy, so this is the chance to contribute to some early work in that area.
http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-generic-policy-00.txt
More at:
www.aaaarch.org
3. Joel: WG Status Review
Joel reviewed the status of the current documents and their status. Major point: we need to quickly finish the info models so that we can get on with finishing the mapping documents. We are planning only one slot in Salt Lake City to finish up what's on our plate.
4. Andrea: Policy Terminology Draft Status
http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-04.txt
A multiple wg last call was held on the policy terminology draft. There were approx. 7 or 8 last call comments. Dialogues to resolve issues were held on both relevant wg's: the policy wg, as well as the wg that was the source of the comment.
Andrea reviewed the changes she made. See the charts she presented for details (attached below).
The PolTerm draft is now ready to forward to the IESG. (See summary.)
5. Bob Moore: Policy Core Information Model Extensions (PCIMe) Draft
This is the draft which Bob has updated since the meeting (Thanks, Bob!):
http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-03.txt
Status on PCIMe:
-Objective: reach closure in the room on these issues, and get list to validate the closure, and move on
-pcime publish dates reviewed see Bob's charts
-PCIMe Issues:
5a. Encoding of filter properties: IpVersion, Addresses, Ports:
Result of discussion: No Change to what is in the draft on this issue, other than specific changes listed below: .
Summary of discussion:
Only 3 or 4 people appear to care which way we go on this issue. It is more important to pick a way to go, than exactly which way we pick. Andrea feels strongly that it is wrong in the spec right now, because she wants the model to be consistent. There were several comments about how other working groups are handling filter specs, including AAA and IP Flow wg's. Joel: AAA appears to have a different perspective than us. IP Flow is new, and won't have finalized results for awhile. We can't wait for a new working group, and we can't please everyone, so let's just go with what we have, as long as we are not missing anything.
We have a seven-tuple now, including the flow spec. Decision: Accept the filter properties we have now, with expectation that some things will likely be needed in the way of extensions later. icmp filters can be part of that extension (icmp filters were requested some individuals in the ipsp working group).
The name of the class changes to "IPHeadersFilter" (was "IPHeaderFilter")
There was a question about whether there should be multiple subclasses of FilterEntryBase. The decision was no change...no multiple subclasses.
5b. How to specify "don't care" for a filter?
Decision: We may not need to add anything ... Bob will review to be sure, and will submit appropriate text.
5c. "Do until failure " ExecutionStrategy: Decision: No change.
CompoundPolicyAction has the ExecutionStrategy, "Do Until Failure": The question is about what it means when that a compound action itself has failed? a: If all component actions fail. b. if at least one of its component actions fails. Do we need both? What we have now in the doc is alternative "b". This gets into the question of "what constitutes success" in the execution of a action?
Lee: there is nothing in pcime that handles failures. we are not doing error conditions now. we need a whole error condition set of functions and something better than "folk architecture" if we go down that slippery slope.
David D: Does "do all" and "do until success" cover what we need? Bob says it will do what David wants already.
Joel suggested that we leave it as it is in the current doc...no disagreements.
5d. Policy explict variables: Decision: No change to draft.
Lee says we don't need it. Joel says we need it. We can do more later.
It's useful the way it is.
Lee thinks the utility is so limited we will have to redo it. but Lee won't stand in the way of PCIMe moving forward to insist on taking it out.
Marcus will live with what we have in the document, even though he does not like it.
Done: we will go with what people can live with, it stays the way it is.
5e. Compounding Policy Conditions: Decision: No change to draft.
We used same technique of rfc 3060 to aggregate conditions into PolicyRules, and there is significant implementation experiencee with this way of aggregating. there was a suggestion on the list to make it better (simpler). The issue: consistency vs. stability. if we change it, should we also change policyrules?
Joel: We can't change the pcim document itself. Unless there is new function, let's stay with the old way.
No disagreement with leaving things as they are. Per Bob, there is no new functionality of expression being added.
5f. Evaluation and Execution Order: Decision: No change to draft.
Issues relative to execution context for rules, conditions and actions. Key question: How much should pcime constrain the implementation of a rule-based engine in a pep? What do we constrain now? (issue has to do with side-effects).
Even back in pcim rfc, condition evaluation could not have side effects.
Lee: we want to enable both types of rule engines: procedural and declarative. we want the restirctions to allow for declarative approach to work. do we need to change the document? no problem expressed in the meeting, so we see no need to change.
5g. criticality of conditions and actions: Warning will be added to text (see discussion below)
The issue is: how to treat unrecognized conditions and actions? should all actions that are do-able, be performed, or should we be able to express that if one of the actions are so important, and you can't do it, don't do any of them (like turn on the gas valve...you may want to only do that if you also have the action capability to subsequently turn it off).
Lee's proposal: All policy actions on a particular device should not be executed, if you cannot do any one of the actions in any one of the rules. The safe thing is to reject the policy, and ask the administrator to make it right. Lee's definition of failure is that policies fail catastrophically.
Andrea: we already have this at the level of the rule. Mandatory means you have to understand the action, and if you don't the rule fails.
Marcus: if condition or action is not understood, then throw the rule out, but not the whole policy set. It' can be just as dangerous to not execute a policy, as it is to execute one.
David Durham: COPS says if anything fails in a decision message, you roll back to the previous config. cops has the concept of a transaction so that works for cops.
Problem is: Policy Model has to support more than just protocols that have a transaction model, such as CLI. With CLI, we don't have a concept of defaulting back to the known case before the change. If we go further down this path, we get into device capabilities, which are not currently part of the model (Ron Cohen).
If necessary, specific device models can address this, such as at the QDDIM level.
Agreed: Bob will add a warning in the spec that you should use policy with knowledge that network behavior could be unpredictable if one of the rules or actions is not understood, warning about side effects, etc. Joel will help Bob with the warning text.
5h. compliance to pcime: Language will be added to the spec to explain (see discussion below)
pcime deals only with the infrastructure classes. There is no compliance without a submodel. In some cases pcime deprecates something in pcim.
So, you either comply with pcim or pcime, which means pcim as modified by pcime.
Agreed: Bob will add this text about compliance in the document. "musts" and "mays" are appropriate at the level of the submodel and not at the level of pcime. No disagreements.
6. Bob Moore: QDDIM: Information Model for Describing Network Device QoS Datapath
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-05.txt.
Reviewed history of published QDDIM drafts. See the charts.
Reviewed changes: modeling of droppers, etc. ...see the charts.
6a. Modeling of droppers:
-droppers are hard to model: diffserv has bounced around on this issue also.
Walter: two types: dropper on a queue, and dropper that drops everything. dropper on a queue head or tail, in the data path. this works ok on a threshold value for a specific queue. but sometimes the dropper is on multiple queues. How do you say which set of queues you want to have it operate on. The only way is to put them on a queue structure, rather than on the data path. Problem is that this is a difference from the diffserv wg, which we need to justify. David D agrees that it should not be on the data path.
Walter: The status in diffserv has not changed. The informal model does not work if the algorithm is to operate across multiple queues.
The last call on the mib is coming. someone can be expected to bring this up. the pib is more flexible.
Joel: what we are doing is a superset, and we are not preventing what the diffserv model can represent, from being represented in the QDDIM model. The fact that we are at variance with the informal model should be ok.
Decision: Walter and Bob will work on the proposed text to close on this in the draft.
6b. Preamble marking:
The idea is to add a marker and filter to capture what can be lost at the layer 2 layer (for example) and to pass it on in the packet handling. This does something like what we used to call the TrafficClass class in qddim.
Decision: We need proposed text to broaden the scope of preamble marking, but not change the attribute itself. John Strassner and Walter will come up with this text.
6c. Modeling queues and schedulers: See the document. No comment = No changes.
6d. Four extensive models in the doc: from Walter. are they helpful, and do we need more? No comment = No changes.
2nd session: (Thursday, August 9, 1530- 1730)
7. John Strassner: PCLS (Policy Core LDAP Schema)
http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-11.txt:
Stability of DMTF references: Lee has action item to communicate DMTF's solution to stability problem, for both mutability and availability. Other option is to break the normative reference to the DMTF CIM Model. If we sever, there is a greater technical review effort required to understand dependencies on attributes we are inheriting in subclassing from the CIM classes, and add them back in, if required. John will communicate the result of the DMTF solution to the IESG designated reviewers.
John reviewed the changes and needed changes to the document, as a result of the IESG last call review. John reviewed the document not only with the IESG reviewers, but also with X.500 people. These charts are the results of those reviews. See the charts for the accurate detail of the presentation.
Goof: Mismatch of OID for content rule: will be fixed.
X.500: Use of structure rules causing a problem: solution is to remove the structure rules and move the content of them to text. Will add ordering and substring matching rules to facilitate use of policy, and fix the content rule problems.
Content rule problems: LDAP reviewers suggested one approach. X.500 suggested that the content rules stay as content rules, with some changes in how they are used.
John will update, but another review cycle will be required.
Readability restructuring: DESC field to be shorter. Prefixes will be changed to consistently be PCIM. Word "policy" will be clarified to avoid problem of conflict with X.501 definition of policy.
Normative reference text changes for readability.
Organization of schema spec: will change the order of presentation of the classes, name forms, and attribute definitions to be more readable.
2252 syntax line wrapping reference will be more prominent.
abstract shortening
dn pointer referential integrity will be clarified
appendix will be stated as non-normative
adding an oid statement from iana
typos being fixed
constraints: text adds needed to clarify what to do when outside the range values are encountered by an app.
8. Yoram Ramberg: Policy QoS Information Model
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-03.txt
Reviewed history of the document and approach used
Reviewed design goals:
Objective is to document a policy-definition-based approach, to define desired effect, not the configuration itself. This is also a domain level model, not at the individual element level.
Roles and reuseability of objects are important.
QPIM must be enforceable and independent, and must support diffserv and intserv, plus the interop of pdp's and mgmnt apps; schemas for directories also need standardization.
Yoram's abstraction layer model of QPIM, within the overall policy management approach:
Business policy, topology, and qos paradigm feed into the QPIM and PCIM(e) modeling can be designed. Next you add the device info and capabilities, and then you can iterate and map the model to the device configuration functionality associated with the multiple devices to be policy-managed in the network. Various config methods are possible, including CLI.
Example of abstraction level idea: voip telephony. There are different roles for edge and core devices, to support the QOS functionality to support packetized voice. High level example requires mapping to the configuration level.
Yoram also added clarification of relationship to other policy docs moving thru the working group, incl pcime and qddim. See his charts.
Yoram explained the usage of group/rule hierarchies: uses pcime nesting model. Hierarchies can't be flattened in QPIM, in some cases. Usage examples were added.
Variables and values: subclassing vs. enumeration in pcime. Decision was to subclass from the base class to add a new variable. Division of classes between pcime and qpim: pcime deals with ip addresses, ports, etc. qpim is qos-specific now (it was not before pcime existed). Narrowed binding of variables to specific context for things like ip addresses.
Many reviewer comments addressed: including ambiguity removed, examples fixed, use of booleans fixed, and many others, editorial, typos etc.
No outstanding major issues. More recent comments will be incorporated. Watch pcime changes for consistency.
Yoram wants to move next version (after -04) to go to last call. Then ldap schema for this model will be submitted.
Question: In the abstraction layer model, what is responsible for the translation of policy. Answer: The pdp would be in some scenarios. Others: management appliction would be responsible.
Marcus Brunner: In the abstraction layer model: a domain model means the whole network, correct? Answer: yes Marcus is missing the notion of a flow or per-domain behavior for diffserv, if this is indeed a network-wide abstraction. Marcus has implemented this, and some rules can be translated directly to a node. Is this a node level view or a network-wide level view?
Yoram replied with an example rule: Behavior rules can be for a type of diffserv treatment, for edge and core nodes. But at the network level view, there is an edge-to-edge level policy. Yoram calls that a "business level rule" and "business level policy", which is not described by QPIM. The way QPIM is applied, one rule applies to a role, and that role can apply to more than one device, or interface on devices, at the device level.
Marcus would like some new text/clarification added to the draft to explain this.
9. Ed Ellesson: Wrap-up
Objective is to have one last wg session in Salt Lake City, and the queisce the working group.
See the summary charts. Their content was communicated to the Area Directors as follows:
1. PolTerm: Multi-wg lc issues resolved, draft updated. Will submit to IESG
2. PCIMe:
Issues requiring changes to current draft:
Class Name: change IPHeaderFilter, to read IPHeadersFilter
How to specify "don't care" for a filter: Bob Moore to review and submit appropriate text
Criticality of conditions and actions: Add warning. Text to be supplied by Joel working with Bob. No additions to the model.
Compliance language: Add text: "musts" and "mays" come in at the level of the submodel and not at level of PCIMe model.
Issues resolved with no changes to current draft:
Encoding of filter properties: IpVersion, Addresses, Ports
"Do until failure " ExecutionStrategy
Complete list of fields to filter on
Policy explict variables
Compounding Policy Conditions
Evaluation and Execution Order
3. QDDIM:
Modeling of Droppers: Walter/Bob to write text
Preamble Marking: New text to broaden the scope (John S./Walter)
No changes: Modeling of queues/scheduler, and the four examples
4. PCLS: Status of IESG last call reviewer comments:
DMTF Normative References: Lee will provide updated policy from DMTF in couple of weeks. John will provide to reviewers to determine if norm ref is now ok.
X.500 considerations: John will update, incl. various fixes, moving content of structure rules and removing the rules.
IESG LDAP reviewers: John will update, incl. various fixes to improve readability, content rule treatment, clarifications, moving text around, fixing typos, formatting, etc.
Another review cycle by LDAP/X.500 reviewers required
5. QPIM:
General agreement on the content, altho more review required
Offline discussion on the abstraction concept
One more version, and then to last call (6wks?)
6. Next IETF:
One session in Salt Lake, then queisce wg.
Schemas need to be closed before following ietf.
Charts Presented in the Meeting, in this order (with exception of summary charts, presented last, which are part of the agenda chart package):
1. Agenda and Summary Charts (Ed Ellesson):
((Policy Framework WG Agenda and Summary.ppt))
2. Policy Terminology Charts (Andrea Westerinen)
((PolTerm-04.ppt))
3. PCIMe Charts (Bob Moore)
((PCIMe-02 Issues.ppt))
4. QDDIM Charts (Bob Moore)
((QDDIM-05 Status.ppt))
5. PCLS Charts (John Strassner)
((Policy Core LDAP Schema-ietf51.ppt))
6. QPIM Charts (Yoram Ramberg)
((QPIM-04.ppt))
Agenda
Policy Core LDAP Schema
PCIMe-02 Issues
QDDIM-05 Status
Policy Terminology - 04
QPIM-04