Subject: Minutes - Interim Policy Framework Meeting

From: "John Strassner" <[email-masked]>
Date: Fri, 4 Jun 1999 17:58:27 -0700

Proposed Minutes are attached directly below. Please send
comments to the list if you have any additions.

regards,
John and Ed

------------------------------ snip away from here
down ---------------------------------

Policy Framework WG Interim Meeting
Ft. Collins, Colorado
May 27-28, 1999

Thursday, May 27:
-----------------

Attendees:

1. Ed Ellesson, IBM, [email-masked]
2. John Strassner, Cisco, [email-masked]
3. Scott Hahn, Intel, [email-masked]
4. Hugh Mahon, HP, [email-masked]
5. Chris Martin, Xylan, [email-masked]
6. Raju Rajan, ATT, [email-masked]
7. Mark Stevens, Lucent, [email-masked]
8. Fran Reichmeyer, Nortel, [email-masked]
9. Bert Wijnen, IBM, [email-masked]
10. Patrick Thompson, Microsoft, [email-masked]
11. Shigeru Miyake, Hitachi, [email-masked]
12. Tomoichi Ebata, Hitachi, [email-masked]
13. Ryan Moats, ATT, [email-masked]
14. Glenn Waters, Nortel, [email-masked]
15. David Partain, Ericsson, [email-masked]
16. Andrew Smith, Extreme, [email-masked]
17. Lee Rafalow, IBM, [email-masked]
18. Yzhak Ronen, ATT, [email-masked]
19. Randy Bush, Verio, [email-masked]

Agenda Bash (Ed)
----------------

Agenda approved.

Thank you, to Hugh Mahon and HP, for sponsoring this interim
meeting,
and for arranging the logistics. The conference room, lunch, and
refreshments were most appreciated!

Discussion of "Missing Piece" to Working Group's Efforts (Straz)
----------------------------------------------------------------

 -What is the missing piece?
 -What document/deliverable does it need to be in?
 -What context does the working group need, in order to make
progress?

Summary of John Strassner's presentation, and associated
discussion:

SLA/SLO's in the "Policy Meta Model":

We can talk about the existence of high level business policies
as
part of a total solution, but business level semantics are not
the
purview of the IETF.

We can show a block diagram in the policy architecture that
reflects
the business level, but we can not and should not address the
business models that are enabled at this level, in our
discussions
and documents.  We can only address the services enabled at this
level in the broadest terms, such that we understand the support
required for the interface between the device-level, device-
independent policy building blocks (e.g., the structure that we
are
standardizing) and the next level up (i.e., the business level
policy).

In the application of policy to networks, the content of this
business level view of policy is termed SLA's (Service Level
Agreements), and SLO's (Service Level Objectives). The SLA/SLO
(business) level of policy is the "business contract" level which
we are not standardizing in the IETF.

Raju: Agreed that you can't dictate the business model, or the
services, which is what the business level policies deal with.

Bert: Suggests that the arrows in the picture need to go upward,
rather than downward, on the Policy Meta Model. (This was agreed
by consensus of those present.)

More about the Meta Model:  Some confusion expressed about what
each
level in the diagram represents, at an abstraction level. Need
more
description in the work group documents about what we mean by
policy and schema.

Clarification:  The Core Policy Schema and the
discipline-specific
sub-classed schemata that will follow from this (QOS, IPSEC,
etc.)
are both at the same level in the Policy Meta Model. This level
is
the technology-independent, vendor-independent, device-level
policy
in the middle block, that we are standardizing. The PIB (Policy
Information Base) exists as a connection to the device-specific
MIB,
which is at the lower-level in the meta model.

Hugh:  Stressed need to reflect in this schema what is do-able,
in
terms of existing technologies and protocols, at the device
level.

Straz:  The schema at the "Policy" level in this diagram needs to
know about groups of users and devices, that apply to policy, but
the
PIB does not. The PIB needs to understand groups of ports,
interfaces, etc. that represent the user at the device level.

Lee:  Recommends that we don't spend time on defining the upper
boundary of policy. Too different from company to company.
Vendors
will innovate there. Can't agree on this in this group. Work on
Policy level instead, and then discipline-specific work will
iterate on this.

Hugh: Agrees we don't want to standardize the SLA/SLO's. But
suggests
that we do need to define what we are not defining. Need a
description of it with examples. This captures the influence
without standardizing it.

Mark: Agrees with Hugh. This process will help us understand the
level of abstraction we need. Starting from the top with examples
will help. Need to work through the examples by deconstructing
them.

Fran: We need to describe what we mean by "up" and "down" in the
meta model.

John:  Example: Let's say the goal is to provide intranet access.
SLO describes VPN tunnels with some set of characteristics.
"Policy", as defined by the policy building block in the Meta
Model,
is the device-independent specification of device-level
configuration,
which is specific to the parameters that technically define the
means
of carrying out the policy with conditions and actions. The
schema
can not, and will not, specify specific configuration
information,
since that is device-specific. The PIB is intended to first
announce
the capabilities of a device to the PDP, and translate policy
specifications to device-specific MIBs. That way, the same policy
can be applied to heterogeneous devices, and those devices can
give
relatively the same service to a given type of traffic even if
their
capabilities and mechanisms are different.

Bert: agreed. 1 Mb/s is the device-independent param, but Gold
Service
is higher level, and may be different by ISP for the same
bandwidth.

Raju: Concerned with the level of abstraction at the lowest level
in
the Meta Model, while still being device-independent and
implementation method-independent. This is hard.

Patrick: Volunteering to bring in 30 or 40 examples of SLA level
definitions, as a means to describe what the Policy module in the
meta model needs to support.

John: Great, but need to be QOS Networking examples. Others can
be
archived for future work.

Lee: Should we have breadth across disciplines in the schema
examples?

John: No, we need to dive into QOS as a worked example. Our goal
should focus on showing that we can define how to translate SLAs
to a
form implementable by heterogeneous devices that delivers end2end
services.

Raju: Problem with the process: doing the examples in multiple
disciplines is critical.

Mark: Don't wait until the car is finished before you take it out
on
the test track.

John: We must demonstrate a full end2end solution. This has more
value that portions of solutions that aren't end2end.

Bert: If you go to proposed standard, the IETF is saying you
should
implement to this, so we can see if it works. The IETF does not
guarantee that things will not change at Proposed Standard. The
vendor takes a risk that the standard won't change.

Procedures are clear. You have to show multiple implementations
of
every feature, in order to move it to draft standard. That's when
the
IETF takes a stand that there are multiple independent
implementations. Recycling at proposed is ok and expected.
Retooling required.

Yzhak Ronen: Agrees with the levels we have identified. Core
Policy
independent of discipline, discipline-specific is next. Build on
that
with specific types of QOS schemata, and then vendor builds on
that.
When you change things in the device level, with new version, or
new
version of RSVP, don't want to have to change the next level up.

The challenge of abstracting. Also, informaton sharing is a
factor
here. That is why we are not standardizing the business level.

Raju: May not be able to do RSVP and DiffServ "under" QOS, but
maybe
have parallel RSVP, DiffServ, and generic QOS discipline that is
common, and potentially beyond these two. Maybe add this to the
charter.  E.g., maybe needs to be inclusive of ATM, FR CIR, end
system concepts of QOS, so you can get to a end-to-end QOS.

Andrew: Do vendors subclass further?

Ryan: For vendor-specific things, you might want to use another
protocol besides LDAP.

Andrew: Does the schema to PIB arrow carry the vendor-specific
stuff?

Mark: What about vendor-interoperability? Need to specify the
policy
in vendor-independent way, and let the vendors innovate and
differentiate in how they accomplish and carryout the policy.

Andrew: The vendor-specific stuff needs to be opaque. Must accept
the
fact that there will be product differentiation. Does not need to
prevent interoperability if the abstraction is general enough.

Scott Hahn: Don't want CLI commands in the schema! Let's defer to
the schema discussion.

Summary of what we agreed to, during the above discussion:

1. Work group will talk about high level (SLA/SLO) level as
examples
   only, to create and validate the building blocks in the core
and
   QoS schemata. Patrick volunteered to provide 30-40 SLA
examples;
   John and Ed to filter these into a smaller set specific to
this
   working group's intentions. We are not standardizing this
level
   (SLA/SLOs) in this group.

2. Show the arrows going up in the meta model, from policy to the
   higher level. Ensure that this is put in the terminology
draft,
   and perhaps rename the terminology draft. Explain specifically
   what the arrows mean.

3. Policy, as expressed in higher- to lower-levels, needs to
reflect
   what is practical in technology, within a particular
discipline,
   such as QOS. The end goal is to develop policy schemata
related
   specifically to protocols standardized in the IETF.

4. We focus on IETF QOS in this charter as the worked example.
This
   includes RSVP and DiffServ. We are open as to whether we
consider
   specific QoS mechanisms of specific media (e.g., FR CIR).

5. We need to formalize a responsive process of getting input
from
   other working groups. Schema Doctors and Chairs to implement a
   formal process as a feedback mechanism. In Oslo, we should
have a
   meeting of relevant working group chairs and editors and
   Schema Doctors.

6. We can advance the core schema to proposed standard, when the
   worked example proves that it works in that one case, at
least.
   This case is defined to be QoS. It is likely that no one
vendor
   will implement the entire core and QOS schema; however, it is
   certain that a set of vendors will do so, thus enabling the
   interoperability proof for further advancement.

7. Vendor interoperability: target is to provide interoperable
   policy, with implementation differences masked by the level
   of abstraction in the policy schema that is standardized.

8. The QOS schema has multiple pieces, including RSVP/INTSERV,
   DiffServ, and generic QOS. Structuring these will be part of
the
   on-going process.

Thursday Charter Discussion (Straz):
------------------------------------

Note:  See also Friday's Charter Discussion, which was documented
in
the form of the changes to the proposed charter. John Strassner
to
post this revised proposed charter to the mailing list for
further
comment and wordsmithing.

John presented Fran's architecture chart, to help us understand
how
to position the role of architecture in the process of the
working
group. John's point is: policy drives architecture, not the other
way around.

Raju: wants the "architecture" document to expand and elaborate
on
what is in the charter, to further explain the purpose of policy,
and the overall approach we are taking as a working group.

John would like to reposition the "architecture" document
deliverable
as a "framework" document instead. Hopefully, this re-missioning
of
the document will re-focus the work to a different level, and
therefore enable a greater degree of consensus.

It was agreed that we must scope the framework doc to include
elaboration on the charter, and to carefully describe the purpose
of
the policy work we are doing, at a minimum. The framework doc
should
also go forward at the same time as the core schema to wg last
call.
Glenn Waters will put the doc together, and take input.
Working group must agree on its content.

Policy for QOS: We are using networked QOS as the validation case
for
the core schema, as well as for serving the policy needs of the
multiple qos protocols and disciplines developed by IETF working
groups, including RAP, DiffServ, IntServ, RSVP, and ISSLL.
The framework doc should reflect this.

Declarative vs. Procedural: We agreed long ago (Chicago), that
this
working group would base its work on a declarative model, not a
procedural one.  Framework doc must state this.

PIB and Related Issues:
-----------------------

Add bullet to charter: We are capturing dynamic data in the
framework, but not in the schema. This allows the RAP group to
proceed. This is one place where the PIB comes in.

Edited draft charter to include "PIB-like" mission and an
associated
document. Some disagree with the addition of PIB to the mission.
Does
it de-focus us? John argued that it is a necessary piece of
accomplishing our mission (end2end policy control and
expression).

Bert: The IESG AD's may not agree to this PIB expansion of the
charter, until the Policy wg has advanced some drafts. Other
groups,
such as RAP, have a proven track record of accomplishing last
calls.
This could be a later piece of work for the Policy Framework WG,
just the same as MIB's are done in other working groups, or,
alternatively, the RAP wg could do it. Needs more discussion.

In the end, there was not consensus to add the PIB to the
charter.
Expect further discussion on this topic on the list.

One idea: change the name of the core policy schema to read
information model and core schema. Randy believes we need to
clearly
delineate the information model separate from the storage model.
(Note: On Friday, we agreed to split the "core schema" document,
currently a single monolithic document, into two separate
documents,
one for the information model, and one for the core policy
schema.)

Further discussion on the charter was tabled until Friday
morning,
in order to give Lee time to present the schema changes.

Lee's presentation: Schema
--------------------------

-Simple Policy Rule:

Lee described the new approach to simple and complex policy
rules,
using aux classes. Note that the underlying information model is
independent of these changes.

The simple policy rule representation maximizes lookup efficiency
(which meets a requirement of those working on a schema for dhcp
and other wgs). The complex policy rule, on the other hand, is
oriented toward data efficiency, in that it enables re-use of
condition and action instances, (which meets a requirement of
many
of those working on pre-standard versions of a schema for other
wgs, such as QoS). The complex rule mechanism also enables the
DNF
and CNF mechanisms currently described in the core schema, which
the
simple policy rule approach does not support.

Raju's proposal in Minneapolis: By way of reference, Raju's
proposal
for the structure of the policy rule included both simple and
complex
policy rules as separate classes.

-Problems with the proposed structure:

Lee reviewed problems that have been pointed out with the
proposed
policy schema (-03 version), which makes extensive use of
auxilliary
classes (this from email, DMTF, and Schema Doctors discussions):

  1. Objectclass attribute values: There is a problem with
searching
     on the object class type in one important directory
     implementation, when the object class is picked up with the
     aux class that is attached to it. One way around this
problem
     is to use keywords for searching and put a word like
"policy"
     in the keyword list.

     -DHCP example was presented, with the address range class
      playing multiple policy functions. Address range can be
both
      a condition semantic and an action semantic. That is, when
      a DHCP system is choosing an address range to apply to a
      given user, the address range object is an "action" in the
      DHCP policy schema. When an element of a QOS system is
      choosing a queuing strategy based on the address range of a
      packet, that same address range object is a "condition" in
the
      QOS policy schema. If each policy subtree (DHCP and QOS)
had
      its own address range object instances, policy
administration
      would be more difficult. Thus, object re-use simplifies the
      job of the policy administrator. The PolicyElement aux
class
      object serves as simply a flag that says this object class
to
      which it is attached, in this example, address range
object,
      is a policy thingie, so that directory searches on "policy"
      will find it, and so that policy parsers will identify it
      easily and properly.

     -Note: Search on keywords vs. object class type may have
      security implications, since, in mainstream directory
      implementations, one  can enable only certain users to
query
      on certain object classes using Access Control Lists
(ACL's),
      but there are no limits on keyword searches.)

  2. Attach binding time:

     -One directory implementation (the same one as noted in item
#1,
      above), binds the aux class to its associated structural
classes
      at schema definition time. This would require that the
      PolicyElement aux class be bound to all structural classes
for
      which it could possibly serve as a flag, at the time of
      initially loading the schema into the directory.
Potentially,
      this could mean attaching the PolicyElement aux class to
all
      structural elements in the directory. For those instances
which
      are not policy objects at the time, the PolicyElement
      attributes would be assigned null values. Unfortunately,
this
      eliminates the searching efficiency of the PolicyElement
flag
      function. For this specific directory implementation, one
would
      have to use keyword instead.

  3. Derivation from top.

     The same directory implementation noted in items # 1 and #2,
     above, requires that aux classes can only inherit from
"top".
     This prevents our schema aux classes from inheriting
attributes
     from higher level policy classes. The work around for this
     directory implementation is that one must redefine what
would
     otherwise be inherited attributes, in each of the aux
classes.

     Another implication: every time you subclass
PolicyCondition,
     for discipline-specific attributes, one would have to repeat
the
     PolicyCondition attributes again, in the subclass. This is
     vendor-specific, for that directory implementation.

     -Discussion (of schema changes and associated
implementation-
      specific problems):

      Ryan: 1. Parsing structured pointers is hard for thin ldap
               clients
            2. LDAP-accessible directories should have an ability
               to unwind references.

      Response to Ryan's comment #1: it is true that dn pointers
and
      structured pointers require code that is not in a standard
      ldap client api implementation, but people are already
writing
      that code for their pre-standard implementations. It works.
      Discipline-specific code is required in any case.

      Response to Ryan's comment #2: Reference chasing
(unwinding)
      suggestion: this should be proposed to the LDAPEXT wg, but
when
      will LDAPEXT get to this? This could be DOA for us if we
are
      dependent on it, leading to a long time lag when
directories
      finally support reference unwinding.

      Raju: 1. Reviewed PolicyRule, which subclassed into
               SimplePolicyRule and ComplexPolicyRule.

            2. Why we need aux classes: Without multiple
inheritance,
               you have to create new subclasses every time you
have
               new attributes to add, when you start with
structural
               objects. With aux classes, you get the "effect" of
               multiple inheritance, you get to mix and match
what
               attributes you want into an instance, without
               attribute clashes.

      Lee: a byproduct of the implementation-specific set of
           problems, is that, all the attributes must be "mays"
in
           the aux classes. There are many attributes that should
be
           "musts", per the semantic of the attribute.

      The use of aux classes requires that our working group
create
      an appendix of implementation notes with the above
      implications documented.

      -Discussion of using LDAP-accessible directories as the
       IETF-standardized "point of interoperability" for policy
(as
       opposed to, for example, a relational database approach):

      Randy: Are these ldap only issues? Are we commiting to ldap
as
             the only representation? How do we feel about the
             impedance mismatch of policy with ldap?

      Lee: Marketplace is demanding that we use ldap at this
point
           in time.

      Chris: Customers like what ldap-based directories already
do.
             We have implementation experience with them for
policy,
             and we also have work-arounds for many of ldap's
             shortcomings.

      Randy: Are we putting kludges in the schema as a result of
the
             binding to ldap?

      Patrick: Maybe we should have an info model instead, or in
               addition to, the ldap schema.

      John: We do. We're separating that out into two documents
to
            make this clearer.

      Agreement: Call the current schema an ldap schema, and the
                 info model something separate. (Later, we
decided
                 to make these separate documents. See the new
                 proposed charter.)

      Suggestion: (Randy and Ryan): The working group should
create
                  a separate information model draft, a draft
based
                  on current ldap standards, and a later
                  "ldapfuture" draft. (Base the ldapfuture on
                  ability to unwind references, for example. All
                  three will need to be standards track
documents.
                  One of the problems this addresses is the fact
                  that we are introducing kludges being made to
the
                  schema in the name of ldap limitations. We need
                  consensus on this approach on the mailing list.

  4. Policygroup and Policyrule associations:
     PolicyXXXContainmentAuxClasses. These are simply pointers to
     link groups to groups and groups to rules.

     Discussion and preliminary conclusion: One could use DIT
     containment to create these associations; however, this
     restricts re-use. (DIT containment was suggested by Steven
Judd
     on a DMTF phone call.) DIT containment also restricts
     implementors to not use the DIT to create other
associations.
     Finally, we have to realize that we do not have control of
the
     DIT! Customers have already defined their DITs, and >90% of
the
     time, the DIT was defined without taking Policy needs into
     account. DITs are already being used for administrative
     access control, by administrator. Therefore, the wg members
     present at this meeting reject this notion, and decide to
     stick with what we have for linking groups to groups and
groups
     to rules, subject to consensus on the mailing list.

  5. Efficiency of retrieval issue, using the subtree pointer
     mechanism in the schema:

     If you want to get some significant set of policy entries
     identified to the pdp, you can do this thru the subtree
     pointer. One operation, lots of objects. One retrieval per
     policy "sub-domain".

     Example shown. If you never implement it, you don't break
     interoperability, you just have less efficiency in lookups.

     PDP's need to be able to be configured with key words
defined
     by the customer, and by the discipline-specific schemas,
like
     dhcp.

     How do PDPs learn what their starting points are? Point high
     in the tree and have it point down. Blue, short, fat and
west,
     determines the set of objects I need to go to.

     Ryan wants an attribute at the root, defined in an I-D, so
that
     a new PDP can come up and find out where to go in the
subtrees.
     It's a well-defined attribute, perhaps a well-defined dn.
     Ldapext would have to document this. Ryan is proposing this
to
     the protocol group. It goes into the root of the tree.

     This is a change to the protocol spec for ldap. This solves
the
     PDP starting point problem.

     Could do this with a well-known dn, and register that. Blue,
     red:dn.

     Raju: Security problem, if you don't trust your PDPs. There
     are no ACLs on individual entries. You can put ACLs on the
     attributes. Needs more thought. Suggestion: Let the MIB be
     configured by the mgmnt tool, and it tells the PDP where its
     ldap directory is, and also can tell it what its starting
     points are.

  6. Choice of RDN:

     Discussion:

     We added multiple attribute names because we thought that
typing
     was a Good Thing. Following the CIM model, we thought that
we
     would equate CIM's CreationClassName to the LDAP-accessible
     directory's ObjectClass and CIM's Name to LDAP's cn. Problem
is
     that certain directory implementations don't support
multi-part
     RDNs, and many people don't like them. So we use a typed
name.

     Some people object to typed names due to GUI issues, and to
     overlapping semantics.

     In most implementations of ldap-accessible directories, any
     attribute can be a dn. It does not matter.

     Ryan: Must have multiple attributes in forming an rdn. (Lee:
     But the one implementation, the same one as noted in
previous
     comments as an exception to the rule, does not allow this.
     Without a lot of extra effort, that implementation requires
     that the rdn be the cn.)

     Lee: Proposes either policyClassname or cn to be the rdn.

     Typed names: should we have them? Does this put a
restriction
     on CIM to LDAP mapping? Note: XML mapping effort is
proposing
     that CIM change in 3.0 to drop creation class name.
(Patrick)

     Agreement (subject to mailing list consensus):

     Ryan wants "any attribute suitable for naming to be used to
     form the rdn". This group should define what those
attributes
     are. This does not imply a multi-part rdn as a requirement.

     Class-specific names. Consensus in this room:
     problem for IETF is resolved. (It is understood that this
     does not solve the CIM-to-ldap mapping problem.)

     Ryan: Customers will decide their own dit naming scheme.

     Lee: Policy gui's will probably not present ldap-looking
names.

Friday discussion:
------------------

  -Not recorded in meeting yesterday, but recalled from
yesterday:
   Discussion about finding your server, and finding an object or
   attribute in the directory that will tell it where its policy
is.
   Lee will prepare an update to the schema that involves subtree
   pointers in the root of the suffix.

Security discussion (Ed)

Need to identify users and user requirements in each of the
following
disciplines:
  - integrity
  - authentication
  - authorization
  - access control
  - confidentiality
  - non-repudiation

Russ talked about the three forms that we need to consider -
client,
on the wire, and end2end at the Minneapolis meeting.

Discussion on access control. Security through obscurity will not
fly.
But what about super-users, do we need to encrypt the data or can
we
just rely on directory ACLs?

Also denial-of-service concerns. Note that integrity means
verifying
that the data at the destination matches that of the source -
this is
different than encrypting on the wire.

What about security concerns when using LDAP? We either need to
get
LDAP to fix it or not use LDAP. Non-repudiation is what the
directory
service does in terms of an audit trail, and may be out-of-scope
with
respect to the protocol. Thus, it's a requirement for the
solution,
but not of LDAP (e.g., the audit trail would be stored in
the directory).

Protocols don't do this, implementers should be warned. We need
to say
that such auditing should be done, and that the customer should
consider this and choose a directory server that meets his or her
needs. We don't need a statement defining a minimum set of
functions
that must be logged. (Note that SNMPv3 didn't).

Seems like we should use LDAPv3 over TLS. Note that LDAP has as
its
mandatory-to-implement mechanism HTTP Digest, which is
insufficient
for large-scale deployment. We should say SHOULD for using TLS,
and
MAY for using HTTP Digest.

Three types of users - administrators of the schema,
administrators
of the schema content, and consumers like PDPs. Each needs their
own
specific security guidelines and permissions.

Directory service access control is problematic, since the
ACL/ACI
model is not yet standard and is still being worked on in the
LDAPEXT WG. The other problem, of course, is interoperability
between multiple directory solutions. So we need to document the
two administrative user cases. Note that ACLs are bound to the
user identity that logs onto the directory.

Problem in using LDAP security is that if we decide to use TLS,
there is no standard key distribution mechanism. One
recommendation
is to say that we do nothing to break this. We could also use
Kerberos. Perhaps the best solution is to recommend a strong
security mechanism (e.g., TLS OR Kerberos) and to advise against
using weaker mechanisms (clear text, HTTP Digest, etc.).

Denial-of-service is a serious problem, and we recommend the use
of multiple directories. However, this just makes it a "little
bit better" and doesn't really solve the problem. Note that the
schema is unaffected - we're not adding new ways for people to
set up a denial-of-service attack. We should document the fact
that such an attack, if executed successfully, could prevent PDPs
from getting to the directory. Note that DNSSEC is a similar
model
- zone files are not encrypted, but it does do on-the-wire
encryption.

We need to have boilerplate that says that the machine should be
put in a secure location, etc., etc.

We should recommend mutual authentication. The protocol supports
this, but the functionality varies with directory implementation.
We put text similar to what is in MIBs in the schema, and the
detailed comments in the framework document. We'll involve Russ
and organize a discussion on the list, possibly supplemented with
a conference call.

Suggestion: beyond what is transmitted on the wire, everything
else is out-of-scope. We need to document these things, but not
solve them. For example, DNSSEC and SNMPv3 did not talk about
how data is stored. We should say that we do nothing to
break anything or make it worse.

Why should we be treating policy schema any different than other
schema or MIBs?

  -Charter discussion - wordsmithed it in the meeting. See the
   proposed revised charter, to be posted by John Strassner.

  -Procedural issues:
   All ldap schema disccussion that occurs on other lists, such
as
   the DMTF SLA working group list needs to be cross-posted to
the
   IETF policy frameworks list. There are IETF members that are
not
   DMTF members. Solution: Use policy list for everything except
   pure CIM stuff.

   Comment: Need to put slides on a web site for the group

   -03 schema is different that the current visio. Needs
updating.
    (Action:  Bob Moore.)

   -New Framework draft: Glenn will put table of contents
together
    on the mailing list

Schema issues presentation (by Raju Rajan)
------------------------------------------

List of Tradeoffs:

Expressibility: closer to natural language, kind of conditions
and
                actions

Functionality: Analysis needed of constraints that protocol is
               capable of.

Query Optimization: Scalability issues

Data Optimization: Size and storage of data required for policy
Schema sanity checks and managability: Dynamic pointers and
loops.
If delete a user, how many places do I have to go and change
things

Parsing: How much effort required on part of client to parse the
policy info into something it can use.

Execution:  How much burden is added to the data path due to
policy.
(Use of terms execution and limits was controversial.)

Lee: Policy is the device-independent specification of
configuration.
It's not on the execution path.

The PDP and PEP have the job of turning this into execution
instructions.

Raju: The policies we enable should be reasonably compilable and
executable, and flag that this is a problem with some pep
devices.

Chris: where is this documented?

Raju: this is a list of trade-offs. Agrees that this is not
necessarily quantifiable as a set constraints in the wg
documentation.

  1. Expressibility: Raju objects to using the term "finite state
     machine" as the way we characterize what we are doing. It
was
     agreed to define this more strictly in the framework draft.

  2. Declarative vs. procedural. Declarative says if you see this
     condition, then go to this state. Procedural says, if this
state
     then do this. We want to use declarative. (Agreed to by
     all present; to be added to the framework draft.

     Action: Raju will write some words that describe that we are
     restricting our work to declarative, and what that means.

  3. Policy Scope: Make it multi-valued. Check this. A number of
     people have concerns about what it means, anyway.

  4. Hybrid Rules: not prevented by the syntax (combined simple
and
     complex). Raju wants simple and complex rules as separate
     objects. This would enforce the constraint without just text
     caveats. Lee: you have to do validity checks anyway.

     How can a particular discipline schema prevent or require
     simple vs. complex, if it wants to constrain this choice?
     Attribute collisions can result. Wants to give this
alternative
     to specify this by the discipline-specific schema.

     Needs more discussion on the list

  5. Priority and Policy Action Ordering

     -What happens when rules have actions for two different
      disciplines (e.g., both ipsec and qos actions)? How does
      rule priority resolve this, when the priority is on the
      rule and not the action?

      One solution would be for the discipline specific-schemas
      to resolve this.

      The expressibility needs to be there for the disciplines.
      Do we want to constrain the expressibility mechanisms in
      the core schema with structures that allow/constrain what
      is needed?

      The core document must say that certain policies can
conflict
      with the same priority and log an error.

      Andrew suggests that priority should be within the context
of
      the action discipline.

      Lee: Maybe should limit rules to having only one action
      discipline. Rules need to be complete for a particular
action
      and discipline. Requires careful definition of a
discipline.
      Pick and choose from different rules you have to be
complete.

      We need this discussion on the mailing list. Raju will
write
      this up for the list.

      Raju wants to remove action ordering from the spec. Let the
      action ordering be determined by the requirements of the
      disciplines. Requires rules about how to resolve ordering
in
      multiple rules when they both apply.

  6. Complicated Booleans:  DNF, CNF and Negation

     -Compiling of rules: processing time, lookup speed (search
      depth), and memory tree size. Decision tree may be in pdp,
or
      pep, if diffserv.  Could impact data path complexity.

      What is the sizing impact. Just raising the flag.

     -Suggests that we might want to re-examine CNF?.

Raju's presentation and associated discussion was the last agenda
item for this interim meeting. Further discussion prior to Oslo
will
be on the Policy Frameworks mailing list, [email-masked].

Thanks to all who attended, and especially to Hugh Mahon, and HP,
Ft. Collins, who sponsored the meeting.

regards,
John and Ed