NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-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)
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) |
· 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 from Policy Sessions at Minneapolis IETF
Highlights:
Notes: First session of Policy Framework
Monday, March 19, 2001
Agenda:
Monday, March 19
* Agenda Bash/Intro (Chairs)
10 min
* PCLS Status, Ryan Moats
20 min
* <draft-ietf-policy-core-schema-09.txt>
*
* QPIM Status and Issues, Ron Cohen
20 min
* <draft-ietf-policy-qos-info-model-02.txt>
*
* PCIMe Status and Issues, Bob Moore
60 min. (Part One)
* <draft-ietf-policy-pcim-ext-00.txt>
*
* Recap/Summary (Chairs)
10 min
*
* Wednesday, March 21
*
* Agenda Re-Bash/Recap (Chairs) 5 min
* PCIMe (Continued), Bob Moore 40 min. (Part 2) <draft-ietf-policy-pcim-ext-00.txt>
* QDDIM Status and Issues, Bob Moore 20 min
* <draft-ietf-policy-qos-device-info-mofel-02.txt>
* IPSec Policy Update/Issues, Lee Rafalow 20 min (ipsp)
* <draft-ietf-ipsp-config-policy-model-02.txt>
* PP VPN Issues, M. Iyer 20 min (fyi)
* <draft-iyer-ipvpn-infomodel-req-00.txt, draft-iyer-ipvpn-infomodel-00.txt>
* Terminology Status, Andrea Westerinen 20 min
* <draft-ietf-policy-terminology-02.txt>
* Recap/Summary (Chairs)
25 min
Incl. Proposed Interim meeting and charter discussion
Summary of Results of Meeting:
Summary of Policy Framework WG Meeting Results, at 50th IETF:
-PCLS to be modified with "MUST" changed to "MAY" for naming, and then to LAST CALL as of next week.
-Need quick new version of QPIM to comment on, and then another rev before London, after PCIMe is updated. (see date list below)
-New text will be created for PCIMe to address the remaining issues, including "State in Rule Engine". Authors will meet to plan way forward toward new text, prior to 2nd session. (update: multiple meetings scheduled and significant consensus on multiple issues accomplished during the week in Minneapolis. Further productive author discussions are in progress via email.)
-Another draft is ready for last call (terminology), with potential minor modifications on two terms possible, after consultation with snmpconf representative.
-Our model is getting used....let's take credit for it! (IPSP, and unchartered work on MPLS and VPN)
-Interim Meeting (See dates below)
-Charter refresh (See dates below)
-New Charter Dates, as well as Interim Draft and Meeting Dates (Discussed in Meeting):
*Nov. '00: PCIM submittal for Proposed Std Status (done)
*Mar. '01: PCLS last call
*Mar. '01: Terminology draft last call (fyi track)
*(May '01: Proposed Interim Meeting)
*(April 6 '01: PCIM Extensions Next Draft)
*Jul. 13, '01: PCIM Extensions Final
*(Apr 6, '01: QPIM Next Draft)
*Jul. 13, '01: QPIM Final
*Aug. '01: QPLS
*(Apr 27, '01: QDDIM Next Draft)
*Jul. 14, '01: QDDIM Final
*Aug. '01: last face-to-face wg meeting
Detailed Minutes:
Ryan Moats:
See charts.
PCLS: Accepted for last call with some minor modifications:
"MUST" changed to "MAY" for naming, and then to LAST CALL as of next week.
Ron Cohen:
see charts.
issues from San Diego:
-we need a clear separation between what is defined in QPIM and what is defined in QDDIM
-Yoram Bernet did not like the separation between RSVP and DiffServ.
Simplification:
-intend to use hierarchical rules instead of the explicit resource sharing that was in the current qpim document.
Relationship to QDDIM:
-removing the queue and meter classes were key, in order to remove confusion with QDDIM
Bob Moore: (question to chairs)
should we put variables, values, and compound condxs, into pcime, and take them out of qpim?
Joel: we need to see the document. dependence will exist. before next ietf.
We need a new qpim draft very soon after this meeting, and two revs of the draft before London. Agreed.
PCIMe presentation by Bob Moore:
see the charts:
The assignment was to take experience from modeling qpim, and generalize it, also based on experience in icpm, and mplspim.
-urgency recognized
-Transactional semantics for action execution: this was rejected and will not be in the next draft (do all or do none)
-variables and values: want to apply to actions, as well as conditions
-packet filtering in policy conditions: based on variables and values now.
The Open Issues in PCIMe: Need working group input.
-Lee Rafalow: Rules within rules, and the action of the first rule affects the conditions of the second rule, in the context of the state created by the first rule. You can call it a program counter. Lee thinks it is a mistake. Rule engine is no longer a table, but a interpreter of a language.
If we do this, we should just do the whole language thing, and not get half pregnant.
-Ron Cohen: we have requirement for both "match all" across multiple rules, and also the req for hierarchy of rules. We can perhaps agree that if the rules change the conditions of following rules evaluation, does that solve the problem.
-Joel: nobody has asked for removing match all. Ron is ok with adding text that the evaluation of subsequent rules should not be changed . Joel wants more text describing things very clearly.
-Andrea: does rule within rule always create a procedural situation?
Andrea says no. Just clarify about the side-effects.
-Ron Coehn: wants some flexibility to do hierarchical rules for bandwidth nesting rules.
Joel: let's wait for the new text from the authors
Implicit and Explicit Variables:
Need relative instance identification. Have not figured it out yet.
Variables rely on contexts for identifying the instances to examine/modify.
For implicit: can overall context lead to different fields? For explict, how to id an instance in an instance-independent way?
Ron does not see the need.
Joel: as participant: implicit variables are a mistake. Unbounded guessing of the context variables is the wrong answer.
Bob: Is it important for the administrator? no. but it is important for the policy engine rule evaluator: the execution engine needs to be told where to find, for example, the ip address
Walter: His main concern with implicit variables is that it is a flat, unstructured space, and tempts you to define things in a different way initially and then later re-user may change the semantics without the necessary constraints. Structured data needs to reflect the context for the data. Needs definition. Need new structure or extn of the structure. You want to encourage the crisp definition.
Mahadevan Iyer: agrees with ron. wants to specify that it is from the data packet, but not how it is obtained.
No resolution for now.
Issue 1: dnf/cnf for compound policy conditions
-when building compound policy conditions, should we allow the same dnf/cnf logic we have for aggregating policy condtions in a policy rule?
Alternative is to allow only ANDing and negation here, no ORing, and no parentheses.
-straz: tease out re-usable from this question. the reason this came up was efficiency. say we have source and destination port. this requires two separate objects in the model, which may require two separate accesses. want to avoid overhead. Not just for making it re-usable. don't want to lose function of the full boolean logic that we have in compound condtion.
-bob: does this really reduce the complexity?
-straz: yes, it reduces the number of associations to the rule. the compound condition is conceptually one object.
-lee: how general do we want to make it a general language? we have put re-usability at the core of what we are doing. are we building extensions to solve known problems, like filters, do we need to go farther than that?
ron: wants to build something that is re-usable. make it an arbitrary re-usable compound condition, why cripple it that way?
guy at mic: EE course for nand gates. You have the logic already, so why restirct urself. you already have it already. they want one level to make it simpler (joel)
straz: do we really believe that limiting the condition is simpler, then why arbitrary logic at rule level?
bob compromise on this issue?
mahedevan iyer: compound condition purpose is to make it more efficient.
what makes you think that you can use the and and not, but not the or's.
Lee thinks it is a reusable thing. a condition is reusable. a filter is one condition and reusable. filter is the use that lee has in mind. don't need the rest of the logic for a filter.
Iyer: its a different result, depending on reusable vs. efficiency.
issue 3: Transactional semantics for actions: we think we agreed to pull back from this: do all or do none (involves commit/rollback) the first on the list.
Ron: wants to explain what we agreed to: we cannot have the commit and rollback. we are gettng rid of it.
does not want to get rid of examining all ahead of time, then if you can't do none, if you don't have to roll back, cuz you know ahead of time not to do it.
Joel: if you are free to write the conditions to succeed, then you are free to write the conditions. but how can you tell the policy rule to figure out whether they will succeed or not, ahead of time?
Not resolved in this meeting.
Session 2, Wednesday
2nd policy session:
Issue 4: Packet Filtering
are we going to recommend a way to do modeling of packet filtering? (MUST or SHOULD?)
Lee: suggests we do make recommendation and say SHOULD. Before we said if you use policy classes, you should use variable and value. Let's slice it differently. Let's say device level model use filter entry mechanism, and domain level model use variable and value approach.
author of ipsp policy mib: first part of this is all generic not specific to ipsp. much more useful to have this working group set a recommended way to represeent this, but we may need to go beyond the 5-tuple.
ed: keep it extendable, but do the draft based on ipsec policy and qos policy requirements.
bob agrees: no dissenters
Issue 5: Prohibit Equal Priority Values
-pcime makes three changes to pcim for priorites for rules. most major change is to prohibit equal priorities, because it introduces indeterminate behavior.
-forces an admin to go ahead and pick a priority, even if he/she does not care.
-no dissenters
Issue 6: MATCH and SET Semantics
-In SimplePolicyCondition, the MATCH operator is currently implicit and overloaded.
but what does "MATCH" mean? flexibility is too great maybe?
Marcus: wants more explicit statement of what is going on with the match.
the implementation is complex enough. You need to have a clear statement of what operator means what?
Eric Fleischman: (Boeing) as end user, they like this. informal policy statement would be great. the implementation is harder.
Bob:is this past what the implentors can do to get right?
Marcus: at least define the operators and the objects.Marcus can write this up.
Good!
Issue 7: representation of policy values? like ip addresses.
Marcus sees problems with the match again. 32 bit match for ipv4. different match for ipv6. also depends on string vs. integer. Have to convert to an integer to compare.
m.iyer: wants determinism on type of value. reduce the ambiguity
marcus: its like the filters. top level spec of filters and device level spec of filters. it is different but interchangeable. depends on where it is. device or domain.
bob: the two are not independent. strings in pcime. more strictly typed in device level?
joel : we are talking about the string that the user types in. why not let the user put in one or the other, and let the syntax determine it.
comment: jeff wheeler: pattern matches require keeping it native in the format.
no resolution. on list
issue 9: rule priority in disjoint policy sets: how to prioritize two rules/groups that don't share a common aggregation tree? no answer to this now.
open work item.
M. Iyer: policy consumer (pdp) from two diff policy trees.
he suggests having pdp having a policy for each tree.
Bob: How do we represent this in the model is the problem?
Eric Fleischman: what about scoping the policy?
he has seen an implicit convention for this, in the tools he has played with.
QDDIM:
Status: see charts and new charter milestones
name change: now qos device datapath info model: because intserv/diffserv have same data path elements what about QOSService: this identifies diffserv? maybe don't need them here.
modeling schedulers and queues: yellow boxes by walter need to be worked into the model
alignment with diffserv: mib, pib and informal model: meetings this week to finalize. expect diffserv wg last call very soon. that means we need to pass thru and re-align to any changes
ipsec policy: lee rafalow
reviewed same charts that he went thru with ipsp working group.
ipsp info model will be updated to represent the "musts" for IKE
key point: filter representation
they won't wait for pcime. they will factor in the ideas per their expectations of pcime. other than that, it is based on pcim.
Bob asked Andrea: snmp conf policy mib: couple of uses of policy action and another term.
Will ask policy filter and policy action review by Steve Waldbusser, who is polterm liaison for snmpconf
For other agenda items, please see the charts.
Agenda
PCLS Changes from -08 to -09
QPIM Status Update
PCIMe-00 Issues
QDDIM Update
IPsec Configuration
Policy Model
IPVPN Information Model
Policy Terminology - 02 Report for 50th IETF