Final Minutes: Policy Framework WG, 43rd IETF Tues, Dec. 8, 1998 Reported by: Ed Ellesson 1. Agenda Ed Ellesson kicked off the session with a review of the agenda, and a promise that the mailing list problems would be dealt with by the holidays (unfortunately, the mail list is not yet fixed, but we are working on it.) The planned agenda was as follows: -Agenda -Relationship to DMTF (liaison proc), DEN, and other IETF working grps -Proposed plan for deliverables (docs), their purpose, target sched. -Brief review of architecture -Core policy object classes -PFDL, language definition -Wrap-up, Proposed Interim Meeting 2. Relationship to other working groups: -Ed reviewed background for DEN, and how DMTF and IETF interwork. Noted that there has been an explosion of interest in policy and schemata in many different working groups. -Reported that Ken Roberts from Nortel provided two relevant documents that covered previous work in this area: ITU-T X.749 and Management by Business Objective (Nortel). -DMTF liaison: --Different membership model than IETF (paying members, restricted access to information, though we're working on this). Advantage of DMTF is that CIM is a pure OO information model. Our goal is to use this as the foundation to develop LDAP schemata. Liaisons from IETF to DMTF are Ed and John, who are the chairs of the Service Level Agreement and the Networks Working Groups of the DMTF, respectively. --Change control: Both the IETF and DMTF need their own individual change control. This will progress into a formal relationship once we resolve the (DMTF) document access problems. --DEN has transitioned from an ad-hoc working group to the Networks working group of the DMTF. DEN is being integrated with the latest versions of CIM, as well as adding information to CIM and forming an extension to CIM. -Relationships with other IETF working groups: We (your co-chairs) would like to see the core policy classes document used as the standard in the IETF, and for the various IETF working groups to meet their application-specific needs by subclassing from this set of core policy classes. John and Ed will make themselves available to the other working groups to facilitate this. (See document: Policy Framework Core Information Model, currently, as of the date of these minutes: draft-ietf-policy-core-schema-00.txt, to be updated shortly to -01.) 3. Deliverables: -Core Schema I-D has progressed sufficiently, such that we want to go to Last Call in Minneapolis. Language I-D is progressing, but more slowly. Framework draft is in progress; we'll have a solid draft by Minneapolis. We'll have an interim meeting to ensure that these dates are met. (Editor's Note: Interim meeting is now being scheduled for Raleigh, NC on February 15 and 16. Details to follow.) 4. Architecture Review: Ed's Slide: Overall architecture supports multiple protocols between various components in the architecture as shown (e.g., LDAP, SNMP, and CLI could all be used to affect configuration changes). Our purpose is NOT to define protocols, but to define schema. However, we need to identify protocols that can be used to prove that the architecture is viable, as well as identify any requirements for extensions to these protocols. Touched briefly on the concept of policy domains. We are focused on attacking the single policy domain problem, and will then expand to consider multiple policy domains. Comment from floor: IPSEC needs dynamic policy negotiation across domains, initially. (Editor's Note: This topic was subsequently discussed in the IPSEC wg meeting on Wed. Dec. 9. The point was made there that policy negotiation across domains, which is inherent in IPSEC protocols, can and will proceed, without any need for the data that is stored in the policy repository schema itself to be dynamic or negotiated.) --------------------------------------- John's talk -------------------------------------------------- 5. Core Schema Objects Draft Presentation -John reviewed the documents, deliverables. Core schema and pfdl drafts will be rev'd within next few weeks, or so. -Policy concept described: explanation of the If condition, Then action. Objective is to achieve a desired state. Then monitor results. -Meta-model: SLA, SLO, Policy, Conditions and Actions PFDL, the Policy Framework Definition Language, applies to the Policy, and, therefore, to the Conditions & Actions levels of the meta-model -John maintained that both the core object schema and the pfdl are required for a complete solution. Synchronization between repositories and PDP's cited as one application of pfdl. (Editor's note: there was lack of consensus on the need for pfdl. See below.) -Summary of Comments and Questions related to PFDL: There were multiple questions about the utility of the pfdl on top of the expression of conditions and actions in the schema. To resolve this: -01 revision of pfdl draft will have examples. A framework draft is also needed before the interim meeting to provide a context for this. Interim meeting is target for resolving this. --Michael Richardson: 1. The local repository of legacy devices must be free to have their own store, independent of the structure of the repository, and this working group's effort should accommodate this. 2. Cross-domain focus is needed, in his opinion, in order to provide a solution for "the Internet". (Editor's note: cross-domain interworking is provided for in this working group's framework via static SLA's between service providers, as well as between a service provider and it's customer. However, to quote the charter: ".extending the framework to include exchange and management of policy data between heterogeneous policy domains.. is NOT part of this [working group's] Charter.") --Question from Bob Moore: pfdl plays where? The original terminology draft that kicked off the documentation associated with this working group did not call for communicating policy information directly from the Management Tool to the PDP, without going through the schema in the policy repository, so why do we now need a language that goes beyond the schema? John responded that the Management Tool communicates policy to the PDP using PFDL. PFDL is a higher level language than the schema, from which schema can be derived. PDP then uses the information gained via PFDL to churn and produce what each PEP needs. In response, John reasoned that the pfdl language is required for more dynamic policies, which were not addressed by the architecture in the terminology draft that kicked off this policy work in the IETF. --In response to another question, ("What is relationship between pfdl and ldap?"): PFDL allows the management tool to present conditions and actions that are more flexible than those represented by the schema. --Comment by Sanjay Kamat: Dynamic data and other data can be addressed/captured by rules in the schema, and therefore a language that includes more than what is in the schema is too complex and ambitious for this working group to tackle as a first priority. John agreed that the working group's focus should be on simple things done quickly. Sanjay: Pushed for examples of scenarios where pfdl is necessary, which John agreed should and would be in a future version of the pfdl draft. --Another question from the floor: What is the protocol carrying pfdl? Response: Need to discuss on the list. --Another comment: Complexity of the goal is perhaps too great. How do we manage this? Response: We manage complexity through limiting the scope to QOS initially. Experience is necessary. --In response to a comment about business models, Brian Carpenter, as chair of the IAB, stated: "You can't discuss business models in the IETF." `nuff said. Related to this, someone commented that the framework should address linking to SLA's, but this is different than discussing business models. --Another question: Does pfdl add to the schema? Response: No, not used to dynamically add object classes to the schema. Follow-up question: Then, why is it so fundamental to the architecture? Response: Will write some examples. --Steve Jackowski: Why not put the additional granularity in the schema, rather than just in the pfdl language? Answer: talk off line and on list. --Elwyn Davies: Time is important in the schema. Once this is done, the needed dynamics are captured. --Comment from floor in favor of PFDL: PDP and Management tool may not ship at the same time, so need a language between them. --Finally had to cut the Q&A and get back to the pitch -Description of the Policy Model: PolicyGroup, PolicyRule, Policy Condition, PolicyConditionList, Policy Action. -Aggregations: PolicyGroup can use DIT for aggregation. PolicyRules will need pointers to DN's of other objects to which they are linked, since they are distributed throughout the directory, typically. Visual representations presented of aggregrations of Policy Conditions and Actions. -PolicyRule Definition included explanation of policyValidityPeriod, and policyRulepriority for conflict resolution. -Ordering: At this point there was a long Q&A on the topic of ordering, which is obviously a contentious issue. Need more proposals and discussion on the list. The Q&A is summarized as follows: --Question: How is policy rule ordering used? Confused about priority rule order, vs. priority action. John: Used to resolve conflicts in actions. --Raju Rajan: don't need orders in the actions. Need flexibility in the implementations. John: may be more obvious once there are examples. Also, this is a "may" attribute. Michael Richardson agrees with Raju. Examples so far are all examples of action order, not rule order. --Comment: We need the field for order in the ***execution*** of rules. --David Black: We need ordering to be able to turn rules on and off. We can express this by turning on conditions and turning off conditions in the expression language. --Andrea Westerinen: Rule order depends on the placement of the rule in policy groups, and therefore needs to be sensitive to what group it is in, not just what the rule is. --Comment: RFC 2401 is a Proposed Standard.look at this for precedent. Algorithm for overlapping policies to decorrelate them. See related internet draft as well. --Raju: RFC 2401 ordering can be achieved by policy rule ordering within a policy group. Raju objects to ordering conditions.that is an "or" list. Need examples in a framework document to establish the requirements. John: -01 version of the draft will have these examples. --Michael Richardson: argues that rule order is too limiting for implementations. The PEP should be free to use its own view of what should be executed first. --Comment: Is it true that all PDP's need to download and understand the entire policy that exists? Slippery slope here. Maybe policy should be more static to be more manageable. -Policy Conditions: Definition, and visual representation. --Comment: Do you really need both PolicyCondition and PolicyConditionList? Answer: It's a canonical list; however, we may need a "NOT" operator on both input and output to the list. --Keith McCloghrie: Suggests changing the name to PolicyConditionMember. --Comment: Do we need both Boolean AND to OR, and OR to AND? Need examples. Off line discussion suggested. -PolicyConstraint Data and Encoding: This is an escape mechanism in the draft. It was suggested that we skip the discussion of condition ordering for now, since ordering in general is such a contentious issue. -PolicyActions: definition and visual representation presented. -PolicyAction Data and Encoding: This is an escape, similar to above PolicyConstraint Data and Encoding. -Question from David Black: What happens when a policy action fails? (Deferred to later discussion, perhaps on list.) -PolicyValidityPeriod Definition described. -Debasish Biswas: Concern about the way pointers are being used. With a lot of dn pointers, you are using a directory like a data base. This could be bad from a performance perspective. Too many pointers to follow, to do all these lookups. John S's response: can use dit, or can use non-ldap store. We are not limiting to ldap. Follow-up: The simplest answer is to be able to express a policy in one object. Can we do this? --Steve Jackowski: The solution needs to be general at the beginning. Agrees that policy repository can be anything that can store data. -Conflict Resolution. Step one should be static resolution at the time of policy creation. To take next step is difficult. Run time resolution is harder. Policy rule priority should be used to resolve this. Is this really confllict resolution? --Raju question: what happens when something blows up, and an error occurs. Question about sequencing. --David: Wants to introduce explicit state into the rule engine. Keith: But how to debug? David: use artificial intelligence tools. ---------------------------------------- Ed wrap-up ----------------------------------------------- 5. Wrap-up: -Need examples in the PFDL and the framework documents to justify PFDL, and to explain the approach to ordering. The existing core schema and pfdl drafts will be rev'd in the next few weeks. -Strong interest in interim meeting - over 80 people raised their hands. (Editor's note: Tentative date of interim meeting is Feb. 15 and 16 in Research Triangle Park, NC , ie: the Raleigh/Durham area. Details to be posted to the list in a few days. We will be asking for confirmation regarding who will attend, when I get the notice out.)