Subject: Minutes of Policy Working Group Meeting in Orlando

From: [email-masked]
Date: Wed, 06 Jan 1999 23:09:42 -0500

The following is being forwarded to the policy mailing list.
Message originally sent by Ed Ellesson <[email-masked]>
---------------------------------------------------------------------------

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.

-Comment from floor:  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. 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 J:  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.)

Ed and John

Regards, 

Ed Ellesson
Sr. Engineer, TCP/IP Technology Management
IBM Networking Software Products
Research Triangle Park, NC 
[email-masked]
919-254-4115