Subject: Minutes submitted to Proceedings

From: Ed Ellesson <[email-masked]>
Date: Fri, 13 Apr 2001 18:31:23 -0400

Here are the minutes I submitted to the IETF Proceedings this morning.  I
thought I was in danger of missing the deadline, so I submitted them as-is.
It turns out that we actually have until Monday, so if you see something
here that I screwed up on, let me know, and I will fix it and try to ask the
kind folks at the secretariat to accept an update on Monday.Actually, we
went over the summary in the meeting wrap-up in Minneapolis, which includes
the important actions items, revised charter, etc, so I felt somewhat safe
in going ahead and releasing these to the proceedings, but I'll be glad to
change them if I made a mistake or left something out.  

I also submitted everyone's presentation charts to the proceedings, (thanks
to all of the presenters for giving them/sending them to me!),  but I did
not attach them here, due to the size of the attachment files.    You should
be able to access the charts from the IETF proceedings repository in the
near future.  

Thanks, 
Ed Ellesson

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.

Minutes taker:  Ed Ellesson