One document matched: draft-ietf-policy-framework-pfdl-00.txt

Internet Engineering Task Force                         John Strassner
INTERNET DRAFT                                       Stephen Schleimer
17 November 1998                                         Cisco Systems 

                  Policy Framework Definition Language                
                 draft-ietf-policy-framework-pfdl-00.txt

Status of Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
Directories on ftp.ietf.org (US East Coast), nic.nordu.net 
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Abstract

Recently, the IETF has developed protocols that classify packets in
order to treat certain classes or flows of packets in a particular
way compared to other classes or flows of packets. The successful
wide-scale deployment of these protocols depends on the ability to
administer and distribute consistent policy information to different
types of network devices as well as hosts and servers that participate
in policy decision making, administration, distribution and control.
There is a clear need to develop a scalable framework for policy
administration and distribution that will enable interoperability
among multiple devices and device types that must work together to
achieve a consistent implementation of policy.
This document defines a language, called the Policy Framework 
Definition Language (PFDL), that maps requirements for services to be 
provided by the network as defined in a business specification (e.g., 
an SLA) to a common vendor- and device-independent intermediate form. 
This enables policy information and specifications to be shared among 
the heterogeneous components that comprise the policy framework, and 
allows multiple vendors to use multiple devices to implement that 
framework. The PFDL is the common 'currency' that is exchanged between 
these heterogeneous components to enable them all to perform their 
function in providing, securing, distributing, and administering 
policy. The PFDL becomes the way to ensure that multiple vendors 
interpret the policy the same way while enabling vendors to provide 
value-added services.





Strassner and Schleimer  Expires 5 March 1999               [Page 1]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

Definition of Key Word Usage

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  and "MAY" in this document
are to be interpreted as described in RFC 2119 [TERMS]. These words
will be capitalized to ensure that their intent in this context is 
easily discernible.

Table of Contents

Status of this memo
Abstract

1.  Introduction

2.  Difference Between the PFDL and Other Languages

3.  The Structure of Policies in the PFDL
3.1  Policy Component Hierarchy
3.1.1  The ComplexPolicy class
3.1.2  The SimplePolicy class
3.1.3  The PolicyRule class
3.1.4  The PolicyCondition class hierarchy
3.1.5  The PolicyAction class
3.2  Policy Conflict Detection
3.2.1  Types of Policy Conflicts
3.2.2  Intra-Policy Conflicts
3.2.3  Inter-Policy Conflicts
3.3  Service and Usage Policies
3.3.1  Service Policies
3.3.2  Usage Policies
3.4 Collective Aspects of Policy
3.4.1 Roles
3.4.2 Groups

4.  The Grammar of the PFDL
<lots of additional sections here>

5.  Examples of Using the PFDL

6.  Security Considerations

7.  Acknowledgements

8.  References

9.  Author's Addresses

APPENDICES
Appendix A: PFDL Syntax in BNF



Strassner and Schleimer  Expires 5 March 1999               [Page 2]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

1.  Introduction and Motivation

A policy is a named object that represents an aggregation of Policy 
Rules. The policy describes the overall business function(s) to be 
accomplished, while the set of policy rules defines how those business 
functions will be met. A policy rule defines a sequence of actions to 
be initiated when a corresponding set of conditions is satisfied. It 
should be noted that a condition may be negated (e.g., NOT (user IN 
GoldSLAGroup) ). Therefore, this policy condition is satisfied when the 
specified user is NOT a member of the GoldSLAGroup.

Policies are the link between a high-level business specification of 
desired services and low-level device configurations that provide those 
services. The Policy Framework Working Group will define a secure 
framework for policy administration, representation and distribution 
for multiple devices and device types. This includes devices whose 
primary job is to enforce the policy (e.g., a network element) as well 
as other devices that have one or more of the following roles: policy 
storage, distribution, decision-making, conflict detection, conflict 
resolution, administration, and management.

A framework that is comprised of heterogeneous components requires a 
common definition of policy. Furthermore, policy MUST be able to be 
represented and managed in an unambiguous, interoperable manner within 
a single network administrator's domain. Here, interoperability means 
providing a vendor- and device-independent specification of what the 
device configuration must do in order to provide the desired services.
The Policy Framework Definition Language (PFDL) quantifies this link as 
a formal grammar. The purpose of the language is to translate from a 
business specification, such as those found in a Service Level 
Agreement, to a common vendor- and device-independent intermediate 
form. This enables policy information and specifications to be shared 
among the heterogeneous components that comprise the policy framework, 
and allows multiple vendors to use multiple devices to implement that 
framework. The PFDL is the common "currency" that is exchanged between 
these heterogeneous components to enable them all to perform their 
function in providing, securing, distributing, and administering 
policy. The PFDL becomes the way to ensure that multiple vendors 
interpret the policy the same way while enabling vendors to provide 
value-added services.

The PFDL will first address the needs of expressing QoS policies for 
the Differentiated Services, Integrated Services, RAP, and ISSLL 
Working Groups. The design will be iterated as necessary while the 
Policy Framework itself matures, and then further iterated to ensure 
that the needs of detailed schemata are fulfilled.
This draft represents the initial design of the PFDL.

2.  Difference Between the PFDL and Other Languages
< to be supplied >



Strassner and Schleimer  Expires 5 March 1999               [Page 3]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

3.  The Structure of Policies in the PFDL

In addition to the requirements listed in Section 1 above, the Policy 
Framework architecture must be scalable, interoperable and reusable. 
Here, scalability refers to the ability to build reusable arbitrarily 
complex policies from a set of simple ones. Interoperability means that 
the PFDL must be expressed in a way that enables essential information 
to be communicated between different vendors' policy management systems
and the devices of different vendors that are controlled by the policy 
management systems of different vendors. Specifically, a policy 
management system should be able to be constructed from multiple
vendors, and it should be able to convey policy information to multiple
vendors' devices.

This requires a canonical definition of the structure of a policy. 
Reusability means that each component of a policy should be reusable by 
other policies.

3.1  Policy Component Hierarchy

The design of the PFDL is based on satisfying the Policy Information 
Model being designed in the DMTF [PLYMDL]. The class and relationship 
hierarchies of the Policy Information Model help define the structure 
of the PFDL grammar. Accordingly, this section will provide a brief 
overview of the components that define a policy in the Policy 
Information Model that require specific constructs to be defined in the 
PFDL.

3.1.1  The ComplexPolicy class

A ComplexPolicy can contain one or more SimplePolicies. This enables 
reusability at the policy level. For example, when a user logs on to 
the network, many different policies must be combined. Some of the 
different policies that could be assigned to a user include:
   - Security policies to enable proper access to network resources, as
     well as possible accounting and auditing functions
   - A DHCP lease policy that allocates an IP Address depending on who
     the user is, what services the user is contracted for (which in
     turn can depend on the role of the user), how the user is
     logging in (e.g., Ethernet vs. PPP), and other factors
   - QoS policies that get activated when the user logs on as well as
     other QoS policies that get activated on demand

A ComplexPolicy is modeled as an aggregation of SimplePolicies. This 
represents reusability at the highest (policy) level. The PFDL MUST be 
able to express the aggregation of simple policies into a more complex 
policy. Both of these concepts must be able to be identified as named 
elements.





Strassner and Schleimer  Expires 5 March 1999               [Page 4]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

3.1.2  The SimplePolicy class

A SimplePolicy can contain one or more PolicyRules. Each SimplePolicy 
(a.k.a., a PolicyRule class) contains a SET of PolicyConditions and a 
SET of PolicyActions.

The reason for this is that a PolicyRule is itself domain-specific. 
There are PolicyRules that define security mechanisms (e.g., 
authentication methods and ACL settings), QoS mechanisms (e.g., PHBs 
that will manage traffic), and other mechanisms for other related 
services. Each of these has its own definitions that are specific to 
its domain of knowledge, requiring a set of domain-specific conditions 
and actions. However, at a more abstract level, certain policies need
one or more of these policy rules to be aggregated in order to provide 
the service(s) requested by a client.

For example, when a user logs on, the Policy Information Model can 
describe the binding between the user and the services that a network 
provides by aggregating a set of policy rules. This might consist of an 
overall Security Policy that governs how the user will be authenticated 
and what services the user is authorized to utilize based on a number 
of factors (time of day, method of login, etc.). There might be a set 
of QoS policies that get activated based on the user's SLA. There might 
be a DHCP Lease Policy that controls what dynamic IP address the user 
is assigned. There might be separate accounting and auditing policies 
that get triggered on an as-needed basis.

It is essential that these diverse policy rules get aggregated into a 
single consistent policy that can be associated with the user. The PFDL 
MUST be able to specify and support the aggregation of multiple policy 
rules into a single policy class. Furthermore, it must be able to treat 
policy rules and policy classes as discrete named objects.

The concepts of order and priority are also needed. For example, assume 
that a Policy is comprised of multiple PolicyRules, where one of the 
PolicyRules expresses security restrictions. If the conditions of the 
security policy rule are not satisfied, then it is irrelevant if the 
conditions of the other policy rules are satisfied - the actions of all 
policy rules will not be executed. Thus, the concept of rule ordering 
is needed. Visually:
  IF SecurityPolicyRule is satisfied THEN
     IF DHCPLeasePolicy is satisfied THEN
        Execute QoSPolicies
        Execute AuditingPolicies
     ENDIF
  ENDIF

Similarly, rule priority is a useful concept. For example, this 
provides one mechanism for resolving policy conflicts. Therefore, the 
PFDL MUST be able to express relational and logical operators, along 
with priority and ordering concepts.


Strassner and Schleimer  Expires 5 March 1999               [Page 5]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

3.1.3  The PolicyRule class

The PolicyRule class expresses a set of conditions that, when 
satisfied, triggers a set of actions to be performed. A set of 
conditions is used as part of a canonical template within each 
policy knowledge domain. That is, security, QoS, DHCP, IPSEC, and other 
policy knowledge domains will in general have their own specific 
templates that define a particular set of conditions and an associated 
actions that must be executed if those conditions are satisfied. A 
"canonical template" is prescribed for interoperability reasons. It is 
a fact that multiple vendors will be supplying multiple components as 
part of any general policy architecture. Therefore, a common 
communication methodology is needed. An extensible, canonical 
definition of what constitutes the conditions and actions of a given 
knowledge domain is offered as the solution to this interoperability 
requirement. Therefore, the PFDL MUST support modeling a set of 
conditions and a corresponding set of actions as an extensible 
template.

Note that in addition to the above, a set of actions could be executed 
if the set of conditions are not satisfied. However, this can be 
modeled as a separate policy rule. This is preferred to complicating 
the model and the resulting grammar. The PFDL MUST be able to model a 
policy rule as an extensible template. The template consists of a set 
of conditions that, when satisfied, triggers the execution of an 
associated set of actions.

3.1.4  The PolicyCondition class hierarchy

A policy condition, in the context of the Policy Framework Working 
Group, is defined as testing one or more aspects of users of the 
network and/or traffic flowing through the network, in order to see if 
either the correct policy state can be maintained, or if a newly 
desired policy state can be achieved.

A PolicyRule is comprised of one or more policy conditions. Each policy 
condition is represented by a PolicyConditionList. For simplicity, if 
there are multiple PolicyConditionLists within a given PolicyRule, this 
version of the PFDL requires that the PolicyConditionLists are 
logically ORed together.

A PolicyConditionList aggregates one or more PolicyConditionStatements. 
For simplicity, this version of this draft requires that each of the 
PolicyConditionStatements within a given PolicyConditionList are 
logically ANDed together.

A PolicyConditionStatement consists of two parts, called a 
PolicyConditionCategory and a PolicyConditionValue. A 
PolicyConditionStatement defines a relation between a 
PolicyConditionCategory and a PolicyConditionValue.



Strassner and Schleimer  Expires 5 March 1999               [Page 6]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

PolicyConditionCategories are predefined elements that are specific 
to a particular knowledge domain. They form the structure of the 
condition half of the policy rule template. For example, concepts like 
user, location, application type, and service are all categories of 
conditions that can be tested for a QoS policy, and hence are QoS 
PolicyConditionCategories.

PolicyConditionValues represent the value that a given 
PolicyConditionCategory can take. Some of the limits and other general 
parameters of a PolicyConditionValue are pre-defied (e.g., a valid 
network address must be entered), but only to enforce validation of a 
specific value to be tested. PolicyConditionValues are the means to 
represent user- and application-specific values of the category of 
elements that are to be tested as part of this policy rule.
The PFDL MUST support the representation and structuring of policy 
conditions as defined in this section.

3.1.5  The PolicyAction class hierarchy

The PolicyAction class is in reality a list of one or more policy 
action statements. These policy action statement may be executed either 
in any order (default case) or in a prescribed order, through the use 
of specially defined attributes.

A policy action, in the context of the Policy Framework Working Group, 
is defined as the changing of the configuration of one or more network 
elements in order to achieve a desired policy state. This (new) policy 
state provides one or more (new) behaviors.

A PolicyRule is comprised of one or more policy actions. Each policy 
action is represented by a PolicyActionList. In contrast with 
PolicyConditionLists, the PolicyActionLists are not by default ORed 
together. In fact, the default relationship between a set of 
PolicyActionLists is that they are all executed in ANY order. To 
accommodate special situations, facilities exist for imposing an 
ordering of the PolicyActionLists as well as conditional execution of 
one or more PolicyActionLists based on the outcome (e.g., success or 
failure) of a previously executed PolicyActionList.

A PolicyActionList aggregates one or more PolicyActionStatements. The 
PolicyActionStatements within a given PolicyActionList are by default 
executed in ANY order. However, facilities exist for imposing an 
ordering of the PolicyActionStatements within a given PolicyActionList 
as well as conditional execution of one or more PolicyActionStatements 
based on the outcome (e.g., success or failure) of a previously 
executed PolicyActionStatement.

A PolicyActionStatement is comprised of two parts, a 
PolicyActionCategory and a PolicyActionValue. A PolicyActionStatement 
defines a relation between a PolicyActionCategory and a 
PolicyActionValue. However, the PolicyActionValue is dependent on the 
type of PolicyActionCategory. Therefore, the PFDL combines these.

Strassner and Schleimer  Expires 5 March 1999               [Page 7]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

The PolicyActionCategory defines a canonical set of operations or 
treatments that can be given to traffic flowing into and out of a 
network element (e.g., deny, change code point, etc.) in a vendor- and 
device-independent manner. The PolicyActionValue specifies the type of 
mechanism to be used to provide the specified operation or treatment.
PolicyActionCategories are predefined elements that are specific to a 
particular knowledge domain. They form the structure of the action half 
of the policy rule template. For example, concepts like providing a 
specific service for a particular application or class of traffic are 
categories of actions that can be performed for a QoS policy, and hence 
are QoS PolicyActionCategories.

A PolicyActionValue represents the value that a given 
PolicyActionCategory can take. Some of the limits and other general 
parameters of a PolicyActionValue are pre-defied (e.g., a valid network 
address must be entered), but only to enforce validation of a specific 
action to be performed. PolicyActionValues are the means to represent 
user- and application-specific values of the category of services that 
are to be provided by a specified network element as part of this 
policy rule.

The PFDL MUST support the representation and structuring of policy 
actions as defined in this section.

3.2  Policy Conflict Detection

Policy conflict detection is crucial to the design of a scalable and 
deployable policy framework. The concept of policy detection is 
actually fairly straightforward. However, the implementation of policy 
conflict detection can be quite complicated in the general case. 
Therefore, this proposal explicitly limits the power and flexibility of 
the PFDL in order to ensure that conflict detection and resolution is 
both doable and implementable.

3.2.1  Types of Policy Conflicts

There are two fundamental types of policy conflicts: those caused by 
within a policy (either a SimplePolicy or a ComplexPolicy) and those 
that cause a conflicting action to be taken in the network. These are 
referred to as Intra- and Inter-Policy conflicts.

3.2.2  Intra-Policy Conflicts

An intra-policy conflict occurs when the conditions of two or more 
policies can be simultaneously satisfied, but the actions of at least 
one of the policies can not be simultaneously executed. This implies 
several things:
    - one or more policy rules of each of the policies is satisfied by
      the same request
    - each condition of each of the conflicting policy rules is
      satisfied by the same request


Strassner and Schleimer  Expires 5 March 1999               [Page 8]




INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

    - one or more actions specified by one policy conflict with one or
      more actions specified by the other policy

Intra-policy conflicts can be resolved in a number of different ways. 
The simplest is to change the conditions and/or actions of one of the 
policies so that it no longer conflicts with the other policies. 
However, if the policies must remain inherently conflicting, then there 
are a number of ways to resolve the conflict on an individual event 
basis, including the following:

    - apply a "match-first" criteria, wherein conflicts are resolved by
      matching the first policy that is found
    - apply a priority order criteria, wherein conflicts are resolved
      by finding all policy rules which match a given event and
      selecting only the rule with the highest priority
    - use additional metadata to determine which rule or rules should
      be applied. The difference between this and straight priority is
      that priority is inherently linear, whereas metadata enables non-
      linear solutions, such as branching, to be used.

The PFDL MUST support facilities to resolve conflicts.

3.2.3  Inter-Policy Conflicts

An inter-policy conflict is defined as two or more policies that, when 
applied to the network, result in conflicting configuration commands 
and/or mechanisms to be specified for one or more network devices. It 
is important to note that in this case, the two (or more) conflicting 
policies do not conflict when compared to each other, but do conflict 
when applied to a specific network device or devices. For example, two 
policies could specify conflicting configurations on a given interface, 
or specify that a certain number of queues be used in one network 
device and a different number of queues be used in another network 
device for the same traffic flow.

The PFDL must support constructs that enable such conflicts to be 
resolved.

3.3  Service and Usage Policies

There are two different types of policies. They are called Service 
Policies and Usage Policies. It is not mandatory for the PFDL to 
support explicit identification of whether a policy is categorized as a 
service or a usage policy - this is really more for the convenience of 
an associated UI and for the implementation of a Policy Server. 
However, the PFDL should not prevent the optional specification of 
whether a policy is categorized as a service or usage policy.




Strassner and Schleimer  Expires 5 March 1999               [Page 9]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

3.3.1  Service Policies

Service policies describe the creation of services in the network. They 
organize the facilities that the network provides into services that
may be used later to satisfy the requirements of users of the network.
For example, creating various QoS service classes (VoiceTransport,
VideoTransport, ..., BestEffort) is done using service policies. This
is accomplished, for example, by establishing the PHBs needed on 
backbone interfaces over which the traffic to be afforded the specific
service is to flow.

The application of a service policy results in the creation of one or
more named objects that represents network services that are available
for usage policies.

3.3.2  Usage Policies

Usage policies describe how to allocate the services created by Service
policies to requestors of services. Usage policies describe particular
mechanism(s) employed to either maintain the current state of the
object, or to transition an object from one state to a new state, in
order to utilize the specified services.

Usage policies associate services that are provided by the network to
clients of the network (e.g., users and applications). This can include
services provided indirectly (e.g., mark packets of this type with this
DS value) as well as directly (use this set of reservation parameters
for this class of traffic).

Usage policy actions are specifically limited to associating a service 
with a particular PolicyActionCategory. For example, all users in the 
QuarterEndFinance group are assigned Gold Service for the SAP 
application under the following conditions.

Put another way, service policies describe what the network is capable 
of providing, and usage policies describe how to configure the network 
in order to take advantage of one or more services that the network 
provides.

3.4 Collective Aspects of Policy

An essential attribute of policy is its collective nature.  That is,
policies are created in order to control many possibly heterogeneous
objects of the system that are under the control of a policy management
infrastructure. For example, when we create a particular PHB, we want
to be able to apply it to all the interfaces to which it is
appropriate.

Two mechanisms are provided for the collective aspects of policy: roles
and groups.



Strassner and Schleimer  Expires 5 March 1999               [Page 10]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

3.4.1 Roles

A role is a label. A role indicates a function that an interface or
device in the network serves. For example, an interface in the core of
the network connecting to another interface in the core of the network
provides "backbone" services (it aggregates a large number of flows; it
is very high speed; etc). We assign to this interface the role
"BackBone". When we create a policy appropriate to interfaces serving a
backbone role, we assign the role "BackBone" to that policy.

Another important use of roles is to explicitly differentiate the
functions provided by a device. Continuing the above example, an "Edge"
role could be defined that describes the various services provided by
interfaces at the edge of the network (e.g., filtering, traffic
shaping, rate limiting, etc.). These services together describe the
functionality of an edge interface, but also serve to differentiate it
from the functionality of a core interface.

Roles enable an administrator to group the interfaces of multiple
devices into common groups. This enables the administrator to apply the
same policy to each of these interfaces collectively, as opposed to
individually.

A role may be associated with, at most, a single Policy (where a single
Policy may be as complex as necessary.  Policies associated with a role
are specifically intended to apply to interfaces or devices that are
assigned the role.

An interface may be assigned multiple roles. When an interface is
assigned multiple roles, the policies designated by those roles are
intended to apply to that interface. Roles may be parameterized. This
is to enable the definition of more complex policies that define
configurations that contain values that depend on the combination of
type of interface, media being used, protocol being used, and other
factors. For example, a policy might be applied to all Frame Relay
interfaces. Depending on the actual network topology, the types of
congestion experienced in these interfaces might be different. The
parameterized policy offers a way to group these Frame Relay interfaces
together (to simplify administration) while providing an inherent
flexibility to accommodate the particular semantics of interfaces that
are identified by this role.

For example, some kind of conditional expression associated with a Role
which partitions the space of interfaces.  Those interfaces included by
the conditional would take the role; those interfaces not included by
the conditional would not take the role.

When there are several roles assigned to an interface, inter-policy
conflicts may occur.  They are resolved as described in section 3.2.2.




Strassner and Schleimer  Expires 5 March 1999               [Page 11]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

3.4.2 Groups

Grouping is a fundamental concept of aggregation. In most systems, a
group is a named object that contains individual objects as well as
possibly additional (sub-)groups of objects. The key point here is that
group membership is statically determined.

Unfortunately, networks are inherently dynamic in nature. This means
that the ability to "group" objects whose membership is determined
dynamically (e.g., a s a function of the state of the system) is
required. We will call this a "Dynamic Group". The most important
characteristic of a Dynamic Group is that its membership is determined
dynamically when a reference to the Dynamic Group is evaluated.

Dynamic Group objects can therefore represent either individual objects
or other groupings of objects.  For example, a Dynamic Group ranging
over users may be used to limit which users on a certain set of
interfaces have a certain kind of QoS assigned to packets they
generate.

A Dynamic Group is only used as a value part of a condition of a
policy. If a PolicyConditionValue uses a grouping construct, then that
policy is satisfied if the object specified in the 
PolicyConditionCategory satisfies the relationship specified in the
policy between the object in the PolicyConditionCatgegory and the
membership of the Dynamic Group specified in the PolicyConditionValue.
For example, suppose that a logon is in progress. Further suppose that
a policy tests for users who are engineers belonging to a group that is
to receive Gold QoS. Then, at the instant of the testing of the
condition, the set of user objects that the Dynamic Group specifies
(people that are entitled to receive Gold QoS) is determined.
If the object representing the user logging in is in the set specified
by the Dynamic Group, then this condition of the policy is satisfied.

The objects of a Dynamic Group are always determined by the range of
objects that the PolicyConditionCategory can specify.  For example,
there are several ways in which the type <user_category> can specify
the objects that it contains. These same methods can be used by other
types of PolicyConditionCategories, but the different semantics of each
type of PolicyConditionCategory result in different memberships being
built for PolicyConditionCategory.

There are several ways in which a Dynamic Group can specify the objects
It designates: by characterization, by enumeration, or by a combination
of the two. A Dynamic Group uses characterization in order to be able
to explicitly define acceptable values for the attributes of the
object. For example, suppose that a <user_category> object has the
attributes name, job title, and supervisor.  A group, LucasEngineers,
might be characterized as follows:




Strassner and Schleimer  Expires 5 March 1999               [Page 12]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

  Group over <user_category> named LucasEngineers:
     Job Title = "engineer",
     Supervisor = "Luca".  

Then, a condition might be written as follows:

	<user_category> IN LucasEngineers

This condition would be satisfied in the user designated by the
object being tested in the <user_category> above had a supervisor
attribute named "Luca" and job title attribute named "engineer".

A Dynamic Group may also specify the objects that are its members using
enumeration.  That is, the individual objects that the Dynamic Group is
to specify may simply be explicitly listed. For example, a Dynamic
Group of type <user_category> can refer to the objects it contains,
(e.g., LucasEngineers) by explicitly listing its members as opposed to
characterizing attributes or behaviors of those objects. If the
membership of the LucasEngineers Dynamic Group was explicitly defined,
it might look as follows:

    {<Cal>, <Tom>, <Steve>, <Edwin>}

where each of the bracketed entities refers to a user object.

Finally, a group may specify the object it designates by both
characterization and enumeration. The above examples could easily be
combined to yield such a group.

4.  The Grammar of the PFDL

<This section will be finalized shortly>

5.  Examples of Using the PFDL

<This section will be finalized shortly>

6.  Security Considerations

Security and denial of service considerations are not explicitly
considered in this memo, as they are appropriate for the underlying
policy architecture. However, the policy architecture must be secure
as far as the following aspects are concerned. First, the mechanisms
proposed under the framework must minimize theft and denial of service
threats. Second, it must be ensured that the entities (such as PEPs and
PDPs) involved in policy control can verify each other's identity and
establish necessary trust before communicating.

7.  Acknowledegments

Many thanks to the useful discussions and suggestions from the Internet
Community at large but especially to <to be supplied>.

Strassner and Schleimer  Expires 5 March 1999               [Page 13]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

8.  References

 [TERMS]    S. Bradner, "Key words for use in RFCs to Indicate
            Requirement Levels", Internet RFC 2119, March 1997.

<more to be supplied>

9.  Authors' Addresses

John Strassner
    Cisco Systems
    170 West Tasman Drive, Building 1
    San Jose, CA 95134
    Phone:  +1-408-527-1069
    Fax:    +1-408-527-1722
    E-mail:  johns@cisco.com
 
Stephen Schleimer
    Cisco Systems
    170 West Tasman Drive, Building D
    San Jose, CA 95134
    Phone:  +1-408-527-3291
    Fax:    +1-408-???-????
    E-mail:  sschlmr@cisco.com





























Strassner and Schleimer  Expires 5 March 1999               [Page 14]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

Appendix A: BNF of the PFDL

<PFDL_Program>
	::=	[<policy_definition>]+

<policy_definition>
	::=	[<policy_rule>]+
	|	<role_identifier> ':' [<policy_rule>]+

<policy_rule>
	::=	'IF'   <policy_condition_OR_list>
		'THEN' <policy_action_priority_list>

<policy_condition_OR_list>	/* still have to put in priority */
	::=	<policy_condition_AND_list ['OR' <policy_condition_AND_list>]*

<policy_condition_AND_list>
	::=	<policy_condition_statement> 
        ['AND' <policy_condition_statement>]*

<policy_condition_statement>
	::=	<policy_condition_expr>
	|	'NOT' <policy_condition_expr>

<policy_condition_expr>
	::=	<user_category_statement>
	|	<application_category_statement>
	|	<device_category_statement>
	|	<interface_category_statement>
	|	<protocol_category_statement>
	|	<address_category_statement>
	|	<traffic_category_statement>
	|	<SLA_category_statement>
	|	<time_category_statement>

<user_category_statement>
	::=	USER_CATEGORY_REFERENCE <rel_op>
		<user_category_value>

/* the values for <user_category_value> are all either email addresses
   or a Distinguished Name */
<user_category_value>	/* the following are all DNs */
	::=	<user_name>
	|	<user_group_name>
	|	<organizational_unit_name>		/* "division" */
	|	<organization_name>

<application_category_statement>
	::=	APPLICATION_CATEGORY_REFERENCE <rel_op>
		<application_category_value>



Strassner and Schleimer  Expires 5 March 1999               [Page 15]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

<application_category_value>
	::=	<application_name>
	|	'SOURCE:' <application_port_number>
	|	'DESTINATION:' <application_port_number>

<device_category_statement>
	::=	DEVICE_CATEGORY_REFERENCE <rel_op>
		<device_category_value>

<device_category>
	::=	<device_name>
	|	<address_spec>
	|	<role_identifier>

<interface_category_statement>
	::=	INTERFACE_CATEGORY_REFERENCE <rel_op>
		<interface_category_value>

<interface_category_value>
	::=	<role_identifier>

<protocol_category_statement>
	::=	PROTOCOL_CATEGORY_REFERENCE <rel_op>
		<protocol_category_value>

<protocol_category_value>
	::=	<protocol_name> [<protocol_options>]*
	|	<protocol_number> [<protocol_options>]*

<address_category_statement>
	::=	ADDRESS_CATEGORY_REFERENCE <rel_op>
		<address_category_value>

<address_category_value>
	::=	'SOURCE:' <address_spec>
	|	'DESTINATION:' <address_spec>
	|	'BOTH:' <address_spec> <address_spec>

<traffic_category_statement>
	::=	TRAFFIC_CATEGORY_REFERENCE <rel_op>
		<traffic_category_value>

<traffic_category_value>
	::=	<ingress_DSV>
	|	<ingress_ToS_byte_value>
	|	<ingress_802.1_value>
	|	<ingress_ATM_QoS>
	|	<ingress_FR_QoS>

<SLA_category_statement>
	::=	SLA_CATEGORY_REFERENCE <rel_op>
		<sla_category_value>

Strassner and Schleimer  Expires 5 March 1999               [Page 16]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

<SLA_category_value>
	::=	'SLA NAME:' SLA_VALUE [<SLA_name_options>]*

<time_category_statement>
	::=	TIME_CATEGORY_REFERENCE <rel_op>
		<time_category_value>

<time_category_value>
	::=	<absolute_time_category_value>
	|	<relative_time_category_value>

<absolute_time_category_value>
	::=	<valid_time_period> 
	|	<valid_time_period> <time_period_mask>

<relational_operator>
	::=	'IN'
	|	'NOT IN'
	|	'EQUALS'
	|	'NOT EQUALS'
	|	'GREATER THAN'
	|	'GREATER THAN OR EQUAL TO'
	|	'LESS THAN'
	|	'LESS THAN OR EQUAL TO'

<policy_action_priority_list>
	::=	[<policy_action_statement>]+

<policy_action_statement>
	::=	<policy_action_category> [<apply_spec>] [<seq_num>]

<policy_action_category>
	::=	'PERMIT' <permit_deny_category>
	|	'DENY' <permit_deny_category>
	|	'REMARK PACKET' <remark_spec>
	|	'START USING' <service_policy>
	|	'STOP USING' <service_policy>
	|	'Table Definition' <table_def>

<table_def>
	::=	'{' <table_type> <table_shape> <table_content> "}"

<table_type>
	::=	'RED_THRESHOLDS'
	|	'TAIL_DROP'
	|	...

<table_shape>
	::=	'{' <table_dimensions> <table_axis_sizes> '}'

<table_dimensions>
	::=	INTEGER

Strassner and Schleimer  Expires 5 March 1999               [Page 17]


INTERNET DRAFT    draft-ietf-policy-framework-pfdl-00.txt   17 Nov 98

<table_axis_sizes>
	::=	'{' INTEGER* '}'

<table_content>
	::=	'{' <table_row>* '}'

<table_row>
	::=	'{' <table_column_entry>* '}'
	|	<row_index> '{' <table_column_entry>* '}'

<table_column_entry>
	::=	INTEGER
	|	<column_index> ':' INTEGER

<row_index>
	::=	INTEGER

<column_index>
	::=	INTEGER


































Strassner and Schleimer  Expires 5 March 1999               [Page 18]