Subject: Draft Policy Framework Minutes from DC

From: John Strassner <[email-masked]>
Date: Thu, 02 Dec 1999 22:30:12 -0800

Meeting Minutes for the Policy Framework Working Group, 46th IETF
Minutes recorded by John Strassner

Policy, Day One (Monday, 8 November)

Status of where we are at as a working group - Ed Ellesson/John Strassner

We are not only building a general policy model, but also concerned with
building out a detailed QoS model. As an example of the former, we are working
with members of IPSP and DHC. The latter is exemplified in the two QoS models,
one subclassing the policy model and one subclassing the network model
(representing the capabilities of devices).

The following summarizes our progress against the dates in our charter:

    Mar 99      WG Last Call for FYI RFC
     => typo left from last charter revision, should be removed

    Aug 99      WG last call on Policy terminology draft (Informational Track)
     => being replaced by terminology in new Framework draft, plus revisions to
terminology in
          other applicable working group documents. We’ve made some good
progress, particularly with
          Security, in coming up with common terminology. We will continue
working actively with
          other affected working groups (notably, DiffServ, RAP, and IPSP).

 Aug 99 Submit Internet Draft on Use case definition (Informational Track)
  => This was combined with a Requirements draft, updated, and revised Oct 22.
The second submission 
        expanded the scope to work with other working groups. This second
revision is on
        schedule to be updated in late December, with a last call anticipated
in late Jan 00.

    Sep 99      WG last call on Core information model draft (Standards Track)
    => Put on hold until we’ve revised the requirements and framework drafts
(see below)

    Oct 99      WG Last Call on Use case definition (Informational Track)
    => Estimated at Jan 00, updated version due December 

    Dec 99      WG Last Call on Framework draft (Informational Track)
     => A completely new version of the framework draft was resubmitted in
September. The framework
           draft is really somewhat dependent on the terminology and
requirements drafts. However, it is 
           proceeding by working directly with other working groups. New
revision by January at the latest.
           Estimated last call in Feb 00.

     Mar 00     WG Last Call on QoS Schema draft(s) (Standards Track)
     => Policy QoS schema draft (Snir, et. al.) revised, Device QoS draft
(Weiss, et. al.) in process. Note that
           there are two drafts here. The first refines the core policy
information model to explicitly represent
           policies for provisioned and signaled QoS. The latter isn’t part of
the core policy information model
           at all. Rather, it refines the network model, and represents the QoS
capabilities of a device. These
           two drafts then fit together to describe a QoS policy (more later).
They both appear to be on
           schedule

The Core Model is in very good shape, but should in our opinion be held up
until we have settled on a common definition of terminology, requirements and
framework. The schema draft has been tracking the core model. It is proceeding
a bit more slowly, since it is tied to a specific implementation (e.g., using a
directory), whereas the core model is a specification without regard to
specific implementation.

Policy Requirements Update and Discussion  Hugh Mahon

The draft starts out with an explanation of why policy is needed. The basic
motivation is to provide an abstracted, or simplified, management interface
that can be centralized to ease the administrative burden. Another driving
factor is that of automation. Network devices, as well as networks, are
becoming increasingly complicated in order to handle the increased demands of
them. So any automation of common management and configuration tasks is much
needed. This can take the form of fewer (e.g., more abstract) interfaces, or it
can take the form of representing common functions in common policies, or any
number of additional forms. The conclusion is that representing information in
policies is key to achieving these goals. 

New terms, such as policy consumer and policy target, were introduced to
reconcile the different uses of common terms across different working groups.
Please go to the policy terminology BOF for discussion and hopefully resolution
of a common definition of these terms.

Policy Conflicts. Conflicts can occur between rules within a policy, as well as
actions within a rule. This is discussed in detail in the draft; please
continue to discuss this on the mailing list. In the first version of the
draft, there was a discussion of policy conflict between multiple locations in
the network. This was pulled out in the latest version of the draft, but
feedback has been received indicating that it should be put back in. Please
comment on the list if you think it should or not.

Usage Cases. Several different ones are provided. Please read these carefully
and comment on the list.

Security issues: authentication is a MUST for all policies, and encryption of
policy information is a MUST for at least for Security Policies. In addition,
there is concern about protecting the flow of policy information between
different components that make up the policy system.

Requirements:
-       Policy information is the key to policy management
-       Some definitions exist (e.g., data model and schema) exist, but more
need to be defined

Need to better define conflict detection and resolution features.

Issues raised on the mailing list:

One-to-one relationship between policy and target. The basic issue is that if
you have more than one relationship between two entities, and multiple
administrators, then all of the information must be visible to each
administrator.

Relationship between policy target and policy consumer. The draft says that
there is one policy consumer for any particular policy target. If there is more
than one policy consumer, then there must be some coordination between the
policy consumers.

Q (Audrey): doesn’t this disallow notions like redundancy and load-sharing?
A (Hugh): You certainly can, and should, support notions like fail-over.
However, the intent is that only one manager is in force at any one time.
Q (Audrey): But these consumers may be talking over different interfaces. In
order to say that we have a distributed management interface  this seems to be
a risk.
A (Hugh): We could document this  do you have a counter-proposal?
A: (Yoram): the focus of the draft is to present a simplified set of
requirements to gain implementation experience. Not sure that this is
appropriate right now.

Q (Fran): Does target mean a single physical device?
A (Hugh): A target is a type of function that can be managed. The granularity
is whatever is appropriate to be managed  a router interface or an entire
device could both be targets.

Q (Joel): Some of the other WGs have had similar problems w.r.t. redundancy.
But if we don’t describe this, then we are likely to encounter interoperability
problems with multiple clients. Don’t think we should solve the problem now,
but we should reserve these as topics of future discussion.
A (Hugh): OK

Q (Joel): Can we handle fail-over in the same way as load-balancing?
A (Yoram): We shouldn’t restrict this from the protocol.

Q (Nitsan with John): Concerned over the satisfiability and feasibility of a
policy, and ensuring that these two terms are differentiated.
A (Hugh): Will try to incorporate this.

Note that there is also a 1 to N relationship between a policy consumer and
multiple policy targets.

Another issue is the ability to provide guarantees with or without signaling. 

Q (David B): This is true only if every device in the path understands the
signaling protocol that is being used.
A (Yoram): but the only devices that need to signal are those that are
experiencing congestion or are potential congestion points need to signal.
Q (David B): agreed, but is worried about what happens if you try and
generalize this. Not sure that we can define a general service-oriented model.

What’s missing in this version of the draft? Better statement of requirements
at the end of the document. What else do we need to add to improve the
document? Please provide input.

Q (John Sch): there are an awful lot of framework concepts, such as how to
deploy policy. Are these appropriate for this draft, or should they be split
into a separate draft?

Q (Bob): needs some discussion on how to think of policies. For example, is it
sufficient to think of policies as entities that are downloaded and then acted
on intact, or do they have to be programmable (w.r.t. RAP and Active Networks)

Q (Russ): Security section is much improved, but still needs work. Must define
what is needed w.r.t. integrity. Especially true if this is going to be used in
a multi-management environment  each input must be authenticated, and the
integrity of its transmission must be established. Also must talk about
securing the communication between different components of the overall system.

Q (Russ) Put another way, unless there is a way to give the input and output
points reasonable assurance that the policy submitted to the system was
delivered and deployed without alteration, and that the network is actually
using the policy, then we’ve failed.

Chair’s note: with respect to protocols, it would be a Good Thing if we
specified different requirements on the protocols that are used w.r.t. their
security capabilities and implications.

Q (Russ): We need to make a decision as a working group on the need for
mechanism(s) to control the application of policy from the input to the PEP.
The problem is that different components of the system may be protected, but
Russ is concerned that the overall integrity of the system is protected. Note
also that we need appropriate reporting mechanisms to provide feedback for
monitoring purposes.

Policy Framework Draft Update and Discussion  Mark Stevens

In August, the principal authors of the existing draft decided to divide it
into two drafts: a combination overview and framework (this draft), and a
requirements draft (Hugh’s draft). This division enabled the new drafts to
defined new terms for use across different working groups, as well as to
reconcile existing definitions (e.g., what, exactly, is a PDP).

Slide 5. Testing two variables in a policy condition, a and b. The test is if
(a > 5) and (b = 8). Note that a is more easily discerned external to the
element, whereas b is more easily discerned internal to the element. The point
is that there isn’t an external decision point, but there is still a need to
evaluate this policy. Thus, we have different types of decision-makers  the
PDP, which depends on receiving external data in order to make a decision, and
another (called “translating”) decision-maker, which really accepts different
input and makes its own decisions. The problem is that the latter doesn’t
include a PDP per se, and has confused people. Therefore, we came up with a new
term  policy consumer  to describe both cases. This will be discussed on Friday
in the POLTERM BOF.

Q (Shai): This seems to be too complex. Doesn’t want new terminology, doesn’t
think that these differences need to be explicitly documented into a set of new
terms.
A (John): The definition of a PDP is just way too broad. Saying that a the
difference between a PDP and a PEP is that the former makes a decision and the
latter executes a decision doesn’t make sense. Anything that executes something
is making a decision by definition.
Q: so the problem is that the name “policy decision point” was changed to
“policy consumer” over concern of the name decision? Any enforcement point will
always make a decision.
Q: and note that any target will always consume…
A (Chairs): This is a good discussion, but it should be deferred to POLTERM.
The name does have important semantics that we can’t afford to ignore, and we
must get right.

Q (Shai): Forget about names for now. At the bottom of the food chain is an
entity that sees packets, and can affect their handling and treatment. Now, the
question is, what is above that? It seems that there should be an entity
operating at a higher-level, which can give the lowest-level box some help.
There is also a policy repository. We also have a GUI component.

So maybe what the proper distinction is, is that we don’t say “I see a policy
decision”, but rather “I see a packet”.

Q (John): not all policies are packet-based.

Q: Note that target is a potentially bad word to use, since it has the
connotation of an end-user, and we’re talking about network elements.

Q: We also need to identify the translation of policy data, since it may be
stored in a form different than that required by the target.

Q: Problem is that it is focused on the distribution, not the functional,
aspects of the policy system. Thus, it doesn’t describe what information should
be supplied to the target, what translation needs to be there, and most
importantly, doesn’t focus on the fact that a target is a resource manager.

Q (Audrey): One of the things that bothered her was the notion of policy
distribution, and the fact that sometimes we talked about an active repository
that notified its PEPs/targets of new data, and other times we talked about a
passive repository that didn’t do this. Which is it?

Architectural picture from the Framework draft. Andrea points out that there
was a loss of architectural elements that was identified in both of the
competing drafts as a result of the merging in Minneapolis. This will be fixed
in the next revision.

Policy, Day Two (Tuesday, November 9)

Core Information Model Update and Discussion  Bob Moore

Slide 2, focusing on policyRule, policyCondition, policyAction, and
policyRepository
One change made is the addition of the PolicyRuleInSystem association. This is
defined to be a weak relationship. This means that it is scoped by the System
that it is contained in. We’ve also added the ConditionInPolicyRepository and
ActionInPolicyRepository associations. The PolicyRepository is an area that is
used to store reusable policy objects, such as conditions and actions. This
will be discussed more in the talk by Yoram Snir.

A PolicyCondition and a PolicyAction can be either rule-specific or reusable.
If it is rule-specific, then it can’t be reused, it is specific just to a
single PolicyRule. In this case, the PolicyCondition (or PolicyAction) would be
attached directly to a PolicyRule class. If the PolicyCondition or PolicyAction
is reusable, then it is stored in the PolicyRepository and referenced in a
class using a DN pointer. Note that if the PolicyCondition (PolicyAction) is
reusable, then it may be used in multiple PolicyRules, not just in a single
PolicyRule.

This implies that the existing naming scheme in CIM needs to be enhanced. In
CIM, weak relationships are used to scope a class. But this mechanism only
allows entities to be named by one superior. In LDAP, we have the concept of
possible superiors, which we use in the policy model to describe
PolicyCondition (PolicyAction) classes being scoped either by a PolicyRule, or
by a PolicyRepository. So we’ve submitted a formal change request to the CIM
specification to enhance its naming.

Also new is the concept of resource manager. The slide shows a subject (a user
sitting outside a firewall), a target (a host sitting inside the firewall), a
resource manager (the firewall), and an application of policy, that enables
some set of users to get through the firewall, while blocking others. This is a
general model (e.g., it could represent a user trying to get access to a file
system). This is an enhancement of the old jurisdiction model, and also an
enhancement of the concept of roles as it applies to policy. The concept of a
role can e thought of as something that enables the PDP/policy consumer to
retrieve policies that specifically apply to the PEPs/policy targets that are
under control of the retrieved policy. Subject and target are therefore
manifested as something that are defined by PolicyConditions in our model and
relationships between the PolicyCondition and entities in the System
(subclasses of ManagedElement).

Also new is the ResourceManager. This is modeled through the
ResourceManagerCollection class, and a set of 3 associations
(ResourceManagerCollectionPolicyRule, ResourceManagerManagedResource and
ResourceManagerPolicyRule) and an aggregation (MemberResourceManager). The
aggregation models the resource managers for the resources that are to be
controlled (since these are modeled as instances of a Service class). 

(No comments)

LDAP Core Schema Update and Discussion  Bob Moore

First chart shows the overall inheritance model of the LDAP Core Policy Schema.
There are 17 classes that comprise this schema. Most of this has been around
for a while, and is very stable. The second chart shows the various DN pointers
that are used throughout the schema. Of these, the
policyRuleConditionAssociation and the policyRuleActionAssociations are new.
This is in response to changing the definition of policyCondition and
policyAction into aux classes, so that they can be used either as rule-specific
or reusable building blocks.

The next slide illustrates the DIT containment defined in this draft. The far
left (policyRepository) is used to contain reusable policy objects, while the
center (policyRule) is used to build rule-specific classes.

The next slide summarizes what can be contained by what class. The
policyElement aux class is new  it can be attached to anything. Its purpose is
to identify a class that is not part of the policy schema as being related to
policy. This enables classes outside of the policy schema to be identified to
the PDP/policy consumer so that they can be included in the policy-based
management of the system.

For a rule-specific condition (action), there is the
policyRuleConditionAssociation (policyRuleActionAssociation) that is attached
to the policyConditionAuxClass (policyActionAuxClass). The condition or action
itself is via aux attachment, and is DIT contained under the policyRule. For
reusable conditions (actions), the condition (action) is contained in the
policyRepository. It has two structural classes (policyConditionInstance and
policyActionInstance) that are contained in the policyRepository, which are
used to attach reusable conditions and actions to, respectively. The
policyRuleConditionAssociation (policyRuleActionAssociation) classes have DN
pointers to the instances (policyConditionInstance, policyActionInstance) to
which the reusable conditions and actions are attached. Note that the DIT
containment for the reusable conditions and actions is in the policyRepository,
not in the policyRule. 

Q (Yoram): DN Pointer slide. There should be a DN pointer between policyRule
and policyRuleConditionAssociation (and also policyRuleActionAssociation)
because this is the only way we can ensure that the containment isn’t broken.
A (Bob): not sure, should discuss it later

Q (Yoram): Shouldn’t the subject and target associations be associated to a
policyRule instead of a specific policyCondition?
A (Bob): But reusability is at the condition and action level, not at the rule
level. In addition, this allows a more normalized model.

Q (David B): What else can we move up from the QoS models to the core model?
Concern is whether other users of other domains will invent incompatible ways
of representing the same thing.
A (John): We’ve pulled from the QoS schema the concept of a policyRepository
and invented the concept of a resourceManager to solve some problems implied by
the QoS schema. Perhaps additional things should be pulled up, but we should
first re-examine the new work on QoS schemata and then revisit this question
(either here or on the list).

Policy QoS Schema Discussion and Update  Yoram Snir

This schema is derived entirely from the core schema, and extends it in ways
necessary for representing provisioned and signaled QoS. We introduced the
notion of policy repositories (repositories within the repository) and reusable
objects, which have been moved into the core schema since they are generally
applicable to all policy systems. Policy repositories identify a section of the
DIT to be used as a storage area within the DIT. This is important, because it
enables reuse and solves some LDAP problems. It does this by requiring entities
that want to reuse objects in the policy repository to reference them via DN
pointers. This enables these (reusable) objects to be stored once in the
directory (avoiding nasty instance tracking and updating issues) and the
directory itself to update references to those objects. We’ve extended the
definition of conditions and actions to accommodate QoS-specific actions.

Slide 4 shows a sample containment hierarchy, which illustrates how policy can
be scoped at different levels of a system. Containers are usually based on
auxiliary classes, which enables them to be attached to any portion of the DIT
so that entries may be added at that particular containment level. The
qosPolicyDomains container represents the root of the policy repository. It
contains a number of containers, each an instance of the qosPolicyDomain class,
that model the different scopes (e.g., areas of administrative domain) of a
system. This lets different administrative (or other) scoping of policy rules
to be applied to different portions of a system.

Each qosPolicyDomain container contains an ordered list of QoS policy rule
groups, which are implemented as instances of the qosPolicyNamedContainer
class. The auxiliary class 
PolicyGroupContainmentAuxClass is used to associate these
qosNamedPolicyContainer objects to a specific qosPolicyDomain.

Next slide is an example of the policy hierarchical namespace. We see a Domains
instance, which is the root of a set of commonly administered policies.
Immediately below this is an instance of the qosPolicyDomain class, called QPM
Administrated Domain, which is an area of the DIT that is used to contain
policy rules for the QPM system. Policy rules for other systems are contained
in sibling containers to this container. The QPM Administrated Domain container
contains an instance of the qosNamedPolicyContainer, called My Application,
which in turn contains a set of policy rules. This structure enables these
policy rules to be commonly administered and reused.

Next slide is an example for how rules are processed. Two strategies are
defined: first-match and match-all. We also use rule priority to disambiguate
the rules. The example shows three sets of policy rules (XA and YA, XB and YB,
and XC and YC) which each have the same priorities (2, 3, and 4, respectively).
However, they are scoped by Group X and Group Y, which have priorities 6 and 9,
respectively. So, we can disambiguate all of these using first the group
priority and then the rule priority.

Next is an example of a QoSPolicyRule. What we have is a complex condition
followed by two actions (marking and policing). The slide shows that the order
of execution is determined not by the order of the listing of the rules, but
rather by comparing first the relative order of the priorities of the
policyGroup, and then the relative priorities of each of the policyRules within
a particular policyGroup.

Slide 8 shows the structure of a QoS policy rule. In this example, there is a
DN pointer to a set of policyCondition objects. There are also two DN pointers
to two different actions (a marker and a policer), with the policer having
special attributes attached via an instance of the DiffServPolicer class.

Slide 9 shows how a QoS policy rule is built by attaching appropriate aux
classes, and slide 10 shows an example of a complex condition. Slide 12 shows
graphically how a simple condition can be built thru referencing variable and
constant objects, while slide 13 shows the exact same simple condition built as
a reusable condition using aux classes.

Slides 14 and 15 define the use of variables and constants in this draft.
Variables and constants are also extensible, and support constraints on the
variables and constants as well as predefined variables and operators. We
currently support three defined types (number, string, and IP address) and can
add more as required.

Slide 16 defines specific QoS Actions that were defined in order to support
ordering, and then specialized to support DiffServ and IntServ specific
actions.

Slide 17 describes the goals in building reusable objects. Reusable objects are
used for several purposes: sharing objects between policy rules, encapsulating
a set of variables and/or constants (so that you don’t have to find and
maintain multiple instances of the same abstraction, like the value of a web
server port) and data integrity.

Slide 18 defines the goals for building reusable object-repositories. These
repositories provide a hierarchical namespace within a DIT that maps to
applying different administrative scoping to objects comprising the policy
system.

Slide 19 shows the repository structure. It has a list of containers, each of
which has a list of reusable objects. A sample set of repositories is shown in
slide 20. This is described in detail in the draft.

Future work is shown in slide 21. Currently, the QoS schema is not synchronized
with the latest version of the core schema, which will happen shortly. We need
to add the ABNF representation, and formalize this into a
repository-independent informaiton model. We need to extend the definition of
PHB support, and to extend the use of operators.

Q (Ed): When do you think that the core model will meet your needs.
A (Yoram): We’re close, but we still think that we need additional consistency
mechanisms as part of the core model. We also think that the atoms (e.g.,
variables and constants) should be moved up into the core model. 
Q (Ed): So you think you’ve already identified what needs to be moved into the
core model?
A (Yoram): Yes.

Q (David B): Question is not if we can extend the core model, since this draft
has already done that. Question is rather what additional concepts from the QoS
model make sense to be moved into Core. For example, look at the decision
strategy approach in the QoS model. He has constrained the basic generic
structure of groups, for example, to be able to disambiguate which rules fire
in groups.
A (Yoram): We’ll look at this and report back to the list.

Q (John Sch): Thinks that most of the machinery in this draft can also be used
for security. However, have a concern over atoms  if we don’t constrain them to
networking functions, then they aren’t as usable.  Wants support for masked
variables, and this should also be moved into the core model. Mentioned
well-known ports, but these are done through IANA. So shouldn’t the schema
reflect this?
A (Yoram): But this shouldn’t be part of the schema per se, right? If you want
to use IANA’s values, then the user could add those.
Q: problem is that an integer is not sufficient to represent the semantics of
things we are interested in. For example, both DSCPs and a port number can be
integers, but the semantics are different. Also, there are symbolic names (IANA
calls them KEYWORDS) assigned to these. The core schema should have a mechanism

A (John) : John Schnizlein gets this action, to work with John, Bob and Ed to
determine if this should be added to the core schema

Q: on the containment hierarchy and scope slide, the conditions and actions
aren’t reusable, correct?
A (Yoram and John): Correct, conditions and actions here are rule-specific. The
qosNamedPolicyContainer object, which is an instance of policyGroup, is used to
group together related policyRules for (for example) administrative purposes.

Q (Yoram B): Presented a draft yesterday in RAP that associate string names
with application names and IDs. This mechanism should be combined with the
mechanisms here. If done right, this enables us to identify different uses of
the web port (e.g., identifying HTTP traffic is not enough). We should support
this in the core and QoS models.
A (Yoram S): We do this, but as an extension.

Q (David D): What do you mean by constraints?
A (Yoram): We have provided a mechanism to add constraints that are
application-specific. We haven’t embedded it into this schema directly, because
it is application-specific.

Q (Yoram B): How closely does this map to the MIB and the conceptual model
A (Yoram S): This is a higher-level abstraction of that.
A (John): Walter (next presenter) will be talking about the lower-level QoS
draft, which models the QoS capabilities of devices. This draft is directly
related to both the conceptual model and the MIB.

Device QoS Model Description and Update  Walter Weiss

Slide 2. This draft is complementary to the draft just presented. Whereas the
previous draft described extending policy structure by subclassing the policy
core model, this draft refines the network model to represent the QoS
capabilities of devices. We’ve tried to map this explicitly to the conceptual
mode, and are in the progress of mapping this to the DiffServ MIB. This also
sets the stage for differentiating between modeling the state vs. the
configuration of a device, and for incorporating roles.

Slide 3 is a simplified overview of the QoS Model. The red classes are those
that are new; the black classes represent the existing network model classes
that this draft refines.

Slide 4 describes the concept of a QoS Service. This includes not just the
separation of configuration vs. state, but more importantly the representation
of the capabilities of the device vs. any constraints that may be applied that
prohibit or otherwise restrict the use of one or more of its capabilities.

Slide 5 shows the FilterEntry and FilterList classes. These provide a way of
specifying a particular condition to test, such as sourceIPAddress. 

Q (Ron): Isn’t filter the same class as in Yoram’s draft.
A (John): No, this is a more general, yet device-specific, concept.

Q (Chris): Don’t these drafts conflict?
A (Walter): The objective of this draft is to explicitly call out attribute
level binding.
A (John): The previous draft subclasses the policy model, and this draft
subclasses the network model. Think of the previous draft as aimed at
specifying the high-level structure of a policy, whereas this draft specifies
the operands that can be used in that high-level structure. 

Q (Yoram S): We should combine the two drafts into a single draft.
A (John): Think we should complete the specification of this draft and then
consider doing that.

Slide 6 describes the the different types of QoS Capabilities that we represent
in a device. The purpose of this is to describe what is available in a given
environment, or what is available for use by a specific application.
Constraints are used to limit what capabilities can be applied on an
application-specific basis.

Slide 7 shows the different Service Relationships that are modeled. Main
purpose of this slide is to draw attention to the ServiceServiceDependency
association. This is used to resolve the modeling of data flow. One of the
problems identified in the conceptual model is the flexibility in the
composition and ordering of components in the forwarding path. So, referring to
the next example, you might have a higher level service that conditions HTTP
traffic. This might use a set of ServiceServiceDependency associations to bind
together the different component services (marking, metering, etc.) that are
used by the (higher-level) service that conditions the HTTP traffic.

Slide 9: Roles. There are two different interpretations for roles. One is to
provide a list of targets for the policy. The other is to provide a context for
the policy to execute in, binding policy attributes to an instances (e.g., the
set of queues in an interface). We debated this, and decided that there was a
problem. Roles are defined on a policy level, and can’t be used to specify both
interface-level and queue-level attributes. So we decided that we really needed
additional information (e.g., if we have a role talking about QueueDepth, then
we need additional information, such as the Service that is using it, in order
to provide a context for setting this attribute). Furthermore, we can’t use
PIBs and MIBs unless this context is identified.

Note that if we incorporate things like “use queue 3” in a policy, this only
works for the interface (and possibly a specific device) that this policy was
built for. In particular, this policy doesn’t work well for systems that only
have 2 queues! So, referring to the Service Relationships Example slide, we
combine the specific attribute to be set with the name of the service that is
providing the context to set this attribute.

Q (Ron): how do monitoring attributes apply to a directory?
A (John): They don’t. Remember, this is a general information model, not a data
model. As such, we represent all necessary data in the model. Various data
models can be produced from this information model; the mapping of the data in
this information model to a data model useful for directories would not include
such data.

Wrapup  Ed Ellesson

The sense is that we’re getting very close to stability in the policy core
model and schema. We should first stabilize the requirements and framework
document, and target these for a January release. We could then get the core
information model and schema drafts out around March. We should comment on
merging the two QoS drafts in the list.

---

From: Andrew Smith <[email-masked]>
Date: Fri, 3 Dec 1999 09:52:16 -0800

John,

Thanks for the excellent minutes (hours?). As one who was not at the
meeting, it would help if you could disambiguate the namespace of Yorams and
Johns mentioned in the minutes - full DNs would help match up the Weisss and
the Snirs with their first names too (Everyone knows who Ed, Ma and Pa are
of course). Or else you could just make the list of attendees available
using some standard schema in an LDAP directory somewhere :-)

Andrew

> -----Original Message-----
> From: John Strassner [mailto:[email-masked]]
> Sent: Thursday, December 02, 1999 10:30 PM
> To: [email-masked]
> Subject: Draft Policy Framework Minutes from DC
> 
> 
>           other applicable working group documents. We've 
> made some good
>     => Put on hold until we've revised the requirements and 
> framework drafts
> (see below)
> 
>            policies for provisioned and signaled QoS. The 
> latter isn't part of
> Q (Audrey): doesn't this disallow notions like redundancy and 
> load-sharing?
> But if we don't describe this, then we are likely to 
> encounter interoperability
> problems with multiple clients. Don't think we should solve 
> the problem now,
> A (Yoram): We shouldn't restrict this from the protocol.
> 
> What's missing in this version of the draft? Better statement 
> of requirements
> using the policy, then we've failed.
> 
> Chair's note: with respect to protocols, it would be a Good 
> Thing if we
> requirements draft (Hugh's draft). This division enabled the 
> new drafts to
> is that there isn't an external decision point, but there is 
> still a need to
> another (called "translating") decision-maker, which really 
> accepts different
> input and makes its own decisions. The problem is that the 
> latter doesn't
> Q (Shai): This seems to be too complex. Doesn't want new 
> terminology, doesn't
> latter executes a decision doesn't make sense. Anything that 
> executes something
> Q: so the problem is that the name "policy decision point" 
> was changed to
> "policy consumer" over concern of the name decision? Any 
> enforcement point will
> always make a decision.
> Q: and note that any target will always consume...
> The name does have important semantics that we can't afford 
> to ignore, and we
> must get right.
> 
> So maybe what the proper distinction is, is that we don't say 
> "I see a policy
> decision", but rather "I see a packet".
> 
> connotation of an end-user, and we're talking about network elements.
> 
> aspects of the policy system. Thus, it doesn't describe what 
> information should
> importantly, doesn't focus on the fact that a target is a 
> resource manager.
> 
> passive repository that didn't do this. Which is it?
> 
> that it is contained in. We've also added the 
> ConditionInPolicyRepository and
> If it is rule-specific, then it can't be reused, it is 
> specific just to a
> by a PolicyRepository. So we've submitted a formal change 
> request to the CIM
> because this is the only way we can ensure that the 
> containment isn't broken.
> Q (Yoram): Shouldn't the subject and target associations be 
> associated to a
> A (John): We've pulled from the QoS schema the concept of a 
> policyRepository
> directory itself to update references to those objects. We've 
> extended the
> a set of variables and/or constants (so that you don't have 
> to find and
> A (Yoram): We're close, but we still think that we need 
> additional consistency
> Q (Ed): So you think you've already identified what needs to 
> be moved into the
> core model?
> A (Yoram): Yes.
> 
> A (Yoram): We'll look at this and report back to the list.
> 
> for security. However, have a concern over atoms  if we don't 
> constrain them to
> networking functions, then they aren't as usable.  Wants 
> support for masked
> well-known ports, but these are done through IANA. So 
> shouldn't the schema
> reflect this?
> A (Yoram): But this shouldn't be part of the schema per se, 
> right? If you want
> to use IANA's values, then the user could add those.
> aren't reusable, correct?
> application-specific. We haven't embedded it into this schema 
> directly, because
> capabilities of devices. We've tried to map this explicitly 
> to the conceptual
> Q (Ron): Isn't filter the same class as in Yoram's draft.
> Q (Chris): Don't these drafts conflict?
> problem. Roles are defined on a policy level, and can't be 
> used to specify both
> to provide a context for setting this attribute). 
> Furthermore, we can't use
> Note that if we incorporate things like "use queue 3" in a 
> policy, this only
> built for. In particular, this policy doesn't work well for 
> systems that only
> A (John): They don't. Remember, this is a general information 
> model, not a data
> The sense is that we're getting very close to stability in 
> the policy core