[Policy] (no subject)

Policy WG:  

I just submitted the following minutes to the proceedings coordinator.  The
minutes I submitted also included the charts that were presented, but I did
not attach them here.  They should appear in the proceedings in a few days.
If anybody needs the charts before then, please send me a note.  

Sorry I did not get the minutes out in time for review (they were due
today.)  You have already seen the summary, which I sent to the list
immediately after the meeting.  These minutes just fill in some detail from
the discussions.  The conclusions are the same as they were in the summary.

Ed

<Begin Minutes>

Minutes of Policy Framework Working Group:  

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 (and as previously submitted to the policy working
group mailing list):    

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. 

_______________________________________________
Policy mailing list
Policy@ietf.org
http://www1.ietf.org/mailman/listinfo/policy