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 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.)
