One document matched: draft-ietf-policy-core-schema-00.txt
Internet Engineering Task Force John Strassner
INTERNET DRAFT Cisco Systems
17 November 1998 Ed Ellesson
IBM
Policy Framework Core Information Model
draft-ietf-policy-core-schema-00.txt
Status of this 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).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document defines an object-oriented information model for
representing policies. This model defines structural information
of objects that comprise and control policy (the 'schema', or
class inheritance hierarchy) as well as information that describes
how different objects are related to other objects (the relationship
hierarchy).
The information model described in this document consists of five very
general classes: policyGroup, policyRule, policyValidityPeriod,
policyCondition, and policyAction. While structural information is
represented very well in LDAP schemas, relationships between objects
are not. This document also defines how to map more abstract concepts,
such as relationships, into LDAP schemas. One mechanism to do this
mapping is to use auxiliary classes. This document defines one such
class, the policyRuleContainmentAuxClass.
While these classes are general, they are not abstract: they can all
be instantiated. Policy solutions for specific areas, such as
DiffServ and IPSec, may use the policyGroup, policyRule,
policyValidityPeriod, and policyRuleContainmentAuxClass classes
directly, while creating their own subclasses derived from
policyCondition and policyAction.
This memo does not specify a standard for the Internet community.
Policy Framework WG Expires May 1999 [Page 1]
Internet Draft Core Policy Information Model November 1998
Table of Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.0 Modeling Policies . . . . . . . . . . . . . . . . . . . . . 4
2.1 Policy Scope . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.0 Overview of the Schema . . . . . . . . . . . . . . . . . . . 5
3.1 Relationships . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Associations . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Aggregations . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Key Relationships of the Policy Framework Core Information Model 7
4.0 Inheritance Hierarchy . . . . . . . . . . . . . . . . . . . 9
5.0 Class Definitions . . . . . . . . . . . . . . . . . . . . . 9
5.1 Naming Attributes in the Core Schema . . . . . . . . . . . . 9
5.2 The Class policyGroup . . . . . . . . . . . . . . . . . . . 9
5.2.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . 10
5.2.2 The Attribute policyGroupName . . . . . . . . . . . . . . 10
5.2.3 The Attribute policyGroupsContainedSet . . . . . . . . . . 11
5.3 The Class policyRuleContainmentAuxClass . . . . . . . . . . 11
5.3.1 The Attribute policyRulesContainedSet . . . . . . . . . . . 12
5.4 The Class policyRule . . . . . . . . . . . . . . . . . . . . 12
5.4.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . 13
5.4.2 The Attribute policyRuleName. . . . . . . . . . . . . . . . 13
5.4.3 The Attribute policyEnabled . . . . . . . . . . . . . . . . 13
5.4.4 The Attribute policyValidityPeriodRef . . . . . . . . . . . 14
5.4.5 The Attribute policyConditionList . . . . . . . . . . . . . 14
5.4.6 The Attribute policyActionList. . . . . . . . . . . . . . . 15
5.4.7 The Attribute policyRulePriority. . . . . . . . . . . . . . 15
5.4.8 The Attribute policyErrorCode . . . . . . . . . . . . . . . 16
5.4.9 The Attribute policyErrorDescription . . . . . . . . . . . 16
5.4.10 The Attribute policyKeywords . . . . . . . . . . . . . . . 17
5.4.11 The Attribute policyModality . . . . . . . . . . . . . . . 17
5.4.12 The Attribute policyType . . . . . . . . . . . . . . . . 17
5.4.13 The Attribute policyUsage . . . . . . . . . . . . . . . . 18
5.5 The Class policyValidityPeriod . . . . . . . . . . . . . . . . 18
5.5.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . . 19
5.5.2 PolicyValidityPeriodName . . . . . . . . . . . . . . . . . 19
5.5.3 The Attribute policyValidityPeriodTime. . . . . . . . . . . 20
5.5.4 The Attribute policyValidityMonthMask . . . . . . . . . . . 20
5.5.5 The Attribute policyValidityDayOfMonthMask. . . . . . . . . 21
5.5.6 The Attribute policyValidityDayOfWeekMask . . . . . . . . . 21
5.5.7 The Attribute policyValidityTimeOfDayRange. . . . . . . . . 22
5.6 The Class policyCondition . . . . . . . . . . . . . . . . . . 23
5.6.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . . 23
5.6.2 policyConditionName . . . . . . . . . . . . . . . . . . . . 23
5.6.3 The Attribute policyConstraintData . . . . . . . . . . . . . 23
5.6.4 The Attribute policyConstraintEncoding . . . . . . . . . . . 24
5.7 The Class policyAction. . . . . . . . . . . . . . . . . . . . . 24
5.7.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . . 25
5.7.2 The Attribute policyActionName . . . . . . . . . . . . . . . 25
5.7.3 The Attribute policyActionData . . . . . . . . . . . . . . . 25
5.7.4 The Attribute policyActionEncoding . . . . . . . . . . . . . 25
6.0 Extending the Core Schema . . . . . . . . . . . . . . . . . . 26
6.1 Subclassing policyCondition and policyAction. . . . . . . . . 26
6.2 Subclassing policyRule . . . . . . . . . . . . . . . . . . . 26
6.2.1 Refining the Semantics of policyRule . . . . . . . . . . . 26
6.2.2 Optimizing the computation of a policyRule . . . . . . . . . 26
6.3 Using policyConstraintEncoding and policyActionEncoding . . . 27
7.0 Security Considerations . . . . . . . . . . . . . . . . . . . 27
Policy Framework WG Expires May 1999 [Page 2]
Internet Draft Core Policy Information Model November 1998
8.0 Intellectual Property . . . . . . . . . . . . . . . . . . . . 27
9.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10.0 References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
12.0 Full Copyright Statement . . . . . . . . . . . . . . . . . . 29
1.0 Introduction
This document is a submission to the Policy Framework Working Group. It
defines a schema containing six core classes for representing policies:
policyGroup, policyRuleContainmentAuxClass, policyRule,
policyValidityPeriod, policyCondition, and policyAction. This schema
is intended for realization in a directory that uses LDAP as its access
protocol; however, it is also intended to be extensible, such that
other types of policy repositories, such as relational databases, can
use this information.
These six classes are sufficiently generic to allow them to represent
policies related to anything. Their initial application will be for
representing policies related to QoS (DiffServ and IntServ) and to
IPSec. Policy models for specific areas such as these may extend the
core schema in several ways. The preferred way is as follows:
o Use the policyGroup, policyRule, policyValidityPeriod, and
policyRuleContainmentAuxClass classes directly, and create their
own subclasses derived from policyCondition and policyAction.
Policy Framework WG Expires May 1999 [Page 3]
Internet Draft Core Policy Information Model November 1998
Discussion of extension techniques follow in 6.0, "Extending the
Core Schema" on page 26.
This document fits into the overall framework for representing,
deploying, and managing policies being developed by the Policy
Framework Working Group. The initial work to define this framework is
In reference [1]. More specifically, this document builds on the core
policy classes first introduced in references [2] and [3]. It also
draws on the work done for the Directory-enabled Networks (DEN)
specification, reference [4]. Work on the DEN specification itself has
been completed. Further work to standardize the models contained in it
will be the responsibility of the Desktop Management Task Force (DMTF).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference [5].
2.0 Modeling Policies
The classes comprising the Policy Framework Core Information Model
Class Hierarchy are intended to serve as an extensible class hierarchy
(through specialization) for defining policy objects that enable
application developers, network administrators, and policy
administrators to represent policies of different types.
The simplest way to think of a policy-controlled network is to first
model the network as a state machine and then use policy to control
which state a policy-controlled device should be in or is allowed to
be in at any given time. Given this approach, policy is applied using
a set of policy rules. Each policy rule consists of a set of conditions
and a set of actions. Policy rules may be nested.
The set of conditions specifies when the policy is applicable. The set
of conditions is implemented as a set of condition lists - each of the
condition lists is ORed. Each condition list can have a set of
conditions that are ANDed.
If all of the conditions are satisfied, then a set of actions that
either maintain the current state of the object or transition the
object to a new state may be executed. Actions can be prioritized,
but this release of the draft does not specify conditional handling
of the actions to be executed. This would be a relatively simple
extension of the grammar; however, if this feature is implemented,
then policies immediately become much more complex.
Policy Framework WG Expires May 1999 [Page 4]
Internet Draft Core Policy Information Model November 1998
Policies can be classified into two categories: simple and complex.
Complex policies are policies that are comprised of simpler policies,
and consist of a complex set of conditions and actions. Hierarchical
policies are another example of complex policies. In general, complex
policies model intricate interactions between objects that have complex
interdependencies. Examples of this include a sophisticated user logon
policy that sets up application access, security, and reconfigures
network connections based on a combination of user identity, network
location, logon method and time of day. Simple policies are those that
can be expressed in a simple statement. They can be represented
effectively in schemas or MIBs. Examples of this are VLAN assignments,
simple YES/NO QoS requests, and IP address allocations. A specific
design goal of this language is to support simple and complex policies.
Policies can be further classified into two categories: service
policies and usage policies. Service policies describe services
available in the network. Usage policies describe which policies will
use which services when the policies are satisfied. 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. 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.
2.1 Policy Scope
Policies represent business goals and objectives. A translation must be
made between these goals and objectives and their realization in the
network. An example of this could be a Service Level Agreement (SLA).
The Policy Framework Definition Language is specifically designed to
model this translation.
This translation is not domain-specific. That is, it applies equally to
differentiated services quality of service (QoS) as it does to signaled
QoS. Furthermore, it is envisioned that the definition of policy in
this draft is generic in nature and is suitable for non-QoS networking
applications (e.g., DHCP and IPSEC) as well as non-networking
applications (e.g., backup policies, auditing access, etc.).
3.0 Overview of the Schema
The following diagram provides an overview of the six classes that
comprise the core schema, and their relationships to each other.
Policy Framework WG Expires May 1999 [Page 5]
Internet Draft Core Policy Information Model November 1998
**************
* *
0..n V * ContainedPolicyGroups
+-------------+ *
| policyGroup |******
| | 0..n
+-------------+
0..n *
* ***********
1..n V * * ContainedPolicyRules
+----------\/-+ *
| |******* +----------------------+
| policyRule |*************>| policyValidityPeriod |
| | +----------------------+
| |
| | ContainedPolicyConditions (ANDed)
| |*************************
| | *
| | 0..n * 0..n
| | +---------\/-----------+
| | | policyCondition |
| | +----------------------+
| |
| | ContainedPolicyActions (ORed)
| |*************************
| | *
| | 0..n * 0..n
| | +---------\/-----------+
| | | policyAction |
+-------------+ +----------------------+
+-------------------------------+
| policyRuleContainmentAuxClass |
+-------------------------------+
3.1 Relationships
Relationships are a central feature of information models. A
Relationship represents a physical or conceptual connection between
objects. CIM and DEN define two types of relationships, called
associations and aggregations.
3.2 Associations
An association is a class that contains two or more references, where
each reference identifies another class. An association is defined
using a class. Associations can be defined between classes without
effecting any of the related classes. That is, addition of an
Association does not effect the interface of the related Classes.
Policy Framework WG Expires May 1999 [Page 6]
Internet Draft Core Policy Information Model November 1998
3.3 Aggregations
An aggregation is a strong form of an association. An aggregation is
usually used to represent a "whole-part" relationship. This type of
relationship defines the containment relationship between a system and
the components that make up the system. Aggregation often implies, but
does not require, that the aggregated objects have mutual dependencies.
3.4 Key Relationships of the Policy Framework Core Information Model
The following relationships are shown in the preceding figure:
o The ContainedPolicyGroups relation enables policyGroups to be
nested. This is critical for scalability and manageability, as it
enables complex policies to be constructed from multiple simpler
policies for administrative convenience. For example, a policyGroup
representing policies for the US might have nested within it policy
groups for the Eastern and Western US.
For LDAP schemata, the ContainedPolicyGroup relation is mapped to
the policyGroupsContainedSet attribute (note that other data stores
may define a different mapping). This attribute enables a
policyGroup to identify another policyGroup as its parent.
o The ContainedPolicyRules relation is similar to the
ContainedPolicyGroups relation, except that its purpose is to
enable multiple policyRules to be nested.
o A policy group may aggregate one or more policy rules, and a policy
rule may be aggregated by one or more policy groups. Grouping of
policy rules into policy groups is again for administrative
convenience; a policy rule may also be used by itself, without
belonging to a policy group.
o A policy rule may also be aggregated by an instance of any class to
which the policyRuleContainmentAuxClass class has been attached.
Once again, this is for administrative convenience. If the
directory entry to which the policyRuleContainmentAuxClass has been
attached is a policy group, then the pointer in the
policyRuleContainmentAuxClass realizes the relationship discussed
above between the group and a policy rule; a separate attribute is
not needed in the policyGroup class.
o A condition of a policy rule may specify one or more policy
validity periods. This can be used for several purposes. Two
important conditions include representing time as a part of the
condition (e.g., use this policy in the morning and a different
policy in the afternoon) and to enable scheduled activation and
deactivation of the policy rule. A policy validity period may be
aggregated by multiple policy rules. A rule that does not point to
a policy validity period is, from the point of view of scheduling,
always active. It may, however, be inactive for other reasons.
Policy Framework WG Expires May 1999 [Page 7]
Internet Draft Core Policy Information Model November 1998
o A policy rule may aggregate one or more policy conditions. Any
conditions aggregated by a policy rule are evaluated and AND-ed
together to determine whether to perform the actions associated
with the policy rule. The pointer supports an ordering among the
conditions pointed to, indicating the order in which the conditions
SHOULD be evaluated. This allows the policy administrator to
optimize processing at the policy decision point by recommending
that it evaluate first the condition most likely to evaluate to
FALSE. One of the ordering values for the pointer is 0, indicating
that the policy enforcement point is given no guidance on when to
evaluate the associated condition.
An instance of policyRule itself (as opposed to an instance of a
subclass of policyRule) always points to at least one policy
condition. A subclass of policyRule, however, may implicitly
include one or more conditions within itself, in which case it need
not point to any policy conditions at all outside itself. See 6.0,
"Extending the Core Schema" on page 22 for further discussion of
this point.
o A policy rule may point to one or more policy actions. The pointer
supports an ordering among the actions pointed to, indicating the
order in which the actions SHOULD be performed. A subclass of
policyRule may "upgrade" this SHOULD to a SHALL, i.e., indicate
that if the actions cannot be performed in the specified order,
then they SHALL not be performed at all. One of the ordering
values for the pointer is 0, indicating that the policy enforcement
point may perform the action at any point in the identified
sequence of actions.
An instance of policyRule itself (as opposed to an instance of a
subclass of policyRule) always points to at least one policy
action. A subclass of policyRule, however, may implicitly include
one or more actions within itself, in which case it need not point
to any policy actions at all outside itself. See 6.0, "Extending
the Core Schema" on page 22 for further discussion of this point.
Policy Framework WG Expires May 1999 [Page 8]
Internet Draft Core Policy Schema November 1998
4.0 Inheritance Hierarchy
The six classes defined in this document are all derived directly from
the abstract class "top":
top
|
+---policyGroup
|
+---policyRuleContainmentAuxClass
|
+---policyRule
|
+---policyValidityPeriod
|
+---policyCondition
|
+---policyAction
5.0 Class Definitions
The classes described below contain certain optimizations in
anticipation of being used specifically for a directory that uses LDAP
as its access protocol. One example of this is the use of auxiliary
classes, and another is the mapping of relationships into a pair of
attributes, one each in the source and destination class. Other data
stores that are not directories might need to implement this
relationship differently.
5.1 Naming Attributes in the Core Schema
Instances in a directory are identified by distinguished names (DNs),
which provide the same type of hierarchical organization that a file
system provides in a computer system. A distinguished name is a
sequence of relative distinguished names (RDNs), where an RDN provides
a unique identifier for an instance within the context of its immediate
superior in the same way that a filename provides a unique identifier
for a file within the context of the folder in which it resides.
To preserve maximum naming flexibility for policy administrators, each
of the classes defined in this schema has its own naming attribute.
Since the naming attributes are different, the policy administrator is
guaranteed that there will be no name collisions between instances of
different classes, even if the same VALUE is assigned to the instances'
respective naming attributes.
5.2 The Class policyGroup
This class serves as a container for a related set of policy rules. A
policy group may also contain other policy groups. Loops, including
the degenerate case of a policy group that contains itself, are not
allowed when policy groups contain other policy groups.
Policy Framework WG Expires May 1999 [Page 9]
Internet Draft Core Policy Schema November 1998
When a policy group contains policy rules, it does so in exactly the
same way that any other class would: via the policyRulesContainedSet
attribute in the auxiliary class policyRuleContainmentAuxClass (note:
this is a specific optimization for directories using LDAP as their
access protocol). The class definition is as follows:
NAME policyGroup
DESCRIPTION A container for a group of related policy rules
DERIVED FROM top
TYPE structural
AUXILIARY CLASSES policyRuleContainmentAuxClass
POSSIBLE SUPERIORS container, organization,
organizationalUnit, policyGroup
OID <to be assigned>
MUST cn, policyGroupName
MAY policyGroupsContainedSet
5.2.1 The attribute cn
The cn, or common name, attribute is an X.500 attribute. It stands for
CommonName. It specifies a (possibly ambiguous) name by which the
object is commonly known. This name is used in a limited scope (such as
an organization). It conforms to the naming conventions of the country
or culture with which it is associated. CN is used universally in DEN
as the naming attribute for a class.
NAME cn
DESCRIPTION naming attribute of this class
SYNTAX DirectoryString
OID 2.4.5.3
EQUALITY caseExactMatch
SINGLE-VALUED
5.2.2 The Attribute policyGroupName
This attribute provides a user-friendly name for a policy group, and is
normally what will be displayed to the end-user as the name of this
class. It is defined as follows:
NAME policyGroupName
DESCRIPTION The user-friendly name of this policy group.
SYNTAX IA5String
OID <to be assigned>
EQUALITY caseExactIA5Match
SINGLE-VALUED
Policy Framework WG Expires May 1999 [Page 10]
Internet Draft Core Policy Schema November 1998
5.2.3 The Attribute policyGroupsContainedSet
This attribute provides an unordered set of DN pointers to zero or more
other policy groups. The attribute definition is as follows:
NAME policyGroupsContainedSet
DESCRIPTION Distinguished names of other policy groups
subsumed under this policy group. There is
no order implied among the members of the set.
SYNTAX DN
OID <to be assigned>
EQUALITY distinguishedNameMatch
MULTI-VALUED
5.3 The Class policyRuleContainmentAuxClass
This auxiliary class provides a single, multi-valued attribute that
points to a set of policy rules. By attaching this attribute to
instances of various other classes, a policy administrator has a
flexible way of providing an entry point into the directory that allows
a client to locate and retrieve the policy rules relevant to it.
A policy administrator might have several different pointers to a
Policy rule in the overall directory structure. For example, there
might be pointers to all policy rules for traffic originating in a
particular subnet from a directory entry that represents that subnet.
At the same time, there might be pointers to all policy rules related
to DiffServ from an instance of policyGroup explicitly introduced as a
container for DiffServ-related policy rules. The
policyRuleContainmentAuxClass is the mechanism that makes it possible
for the policy administrator to define all these pointers.
Note that the cn attribute does NOT need to be defined for this class.
This is because an auxiliary class is used as a means to collect
common attributes and treat them as properties of an object. A good
analogy is a #include file, except that since an auxiliary class is a
class, all the benefits of a class (e.g., subclassing and inheritance)
can be applied to an auxiliary class.
The class definition is as follows:
NAME policyRuleContainmentAuxClass
DESCRIPTION An auxiliary class used to bind policy rules to
an appropriate container object.
DERIVED FROM top
TYPE auxiliary
AUXILIARY CLASSES none
POSSIBLE SUPERIORS container, organization,
organizationalUnit, policyRule
OID <to be assigned>
MUST policyRulesContainedSet
Policy Framework WG Expires May 1999 [Page 11]
Internet Draft Core Policy Schema November 1998
5.3.1 The Attribute policyRulesContainedSet
This attribute provides an unordered set of DN pointers to one or more
policy rules associated with the instance of a structural class to
which this attribute has been appended. The attribute definition is:
NAME policyRulesContainedSet
DESCRIPTION Distinguished names of policy rules associated in
some way with the instance to which this attribute
has been appended. No order is implied.
SYNTAX DN
OID <to be assigned>
EQUALITY distinguishedNameMatch
MULTI-VALUED
5.4 The Class policyRule
This class represents the "If Condition then Action" semantics
associated with a policy. A policyRule aggregates sets of policy
conditions and policy actions. The conditions that are AND-ed
together are identified by DN pointers and/or by specific attributes
introduced in subclasses of policyRule. The actions to be performed if
all of the conditions in the policyRule evaluate to TRUE are identified
by DN pointers and/or by specific attributes introduced in subclasses
of policyRule.
This class also contains several attributes designed to help directory
clients locate the policy rules applicable to them.
The class definition is as follows:
NAME policyRule
DESCRIPTION The class is the central class for representing
the "If Condition then Action" semantics
associated with a policy rule.
DERIVED FROM top
TYPE structural
AUXILIARY CLASSES none
POSSIBLE SUPERIORS policyGroup
OID <to be assigned>
MUST cn
policyRuleName
policyEnabled
MAY policyValidityPeriodRef
policyConditionList
policyActionList
policyRulePriority
policyErrorCode
policyErrorDescription
policyKeywords
policyModality
policyType
policyUsage
Policy Framework WG Expires May 1999 [Page 12]
Internet Draft Core Policy Schema November 1998
5.4.1 The Attribute cn
This is the exact same definition as in Section 5.2.1. It is repeated
here because the PolicyGroup and PolicyRule classes are siblings, and
both require a naming attribute.
5.4.2 The Attribute policyRuleName
This attribute provides a user-friendly name for a policy rule. The
attribute definition is as follows:
NAME policyRuleName
DESCRIPTION The user-friendly name of this policy rule.
SYNTAX IA5String
OID <to be assigned>
EQUALITY caseExactIA5Match
SINGLE-VALUED
5.4.3 The Attribute policyRuleEnabled
This flag indicates whether a policy rule is currently enabled, from an
ADMINISTRATIVE point of view. Its purpose is to allow a policy
administrator to enable or disable a policy rule without having to add
it to, or remove it from, the directory.
The attribute definition is as follows:
NAME policyRuleEnabled
DESCRIPTION A flag indicating whether this policy rule is enabled
from an administrative point of view.
SYNTAX Boolean
OID <to be assigned>
EQUALITY booleanMatch
SINGLE-VALUED
5.4.4 The Attribute policyValidityPeriodRef
This attribute points to an object representing the policy validity
period for this policy rule.
The attribute definition is as follows:
Policy Framework WG Expires May 1999 [Page 13]
Internet Draft Core Policy Schema November 1998
NAME policyValidityPeriodRef
DESCRIPTION A DN pointer to an instance of policyValidityPeriod
representing either the scheduled periods of activity
and inactivity for this policy rule, or possible times
when this rule could be activated.
SYNTAX DN
OID <to be assigned>
EQUALITY distinguishedNameMatch
SINGLE-VALUED
5.4.5 The Attribute policyConditionList
This attribute provides an ORDERED list of DN pointers that identify a
set of policy conditions associated with this policy rule. Order is
used to indicate which the conditions MUST be evaluated by the policy
decision point in which sequence. The purpose of providing an order
is to cause conditions more likely to evaluate to FALSE to be tested
early in the process. This speeds the condition examination process,
since once a single FALSE condition has been found, the remaining
conditions do not need to be evaluated.
Since the order of the values returned by a multi-valued attribute is
indeterminate, the order must be encoded within the attribute values
themselves. To accomplish this, the values of this attribute are of
the form "n:DN", where 'n' indicates the order, the colon (':') serves
as a separator, and "DN" is a distinguished name encoded in the usual
way. Values of 'n' that indicate order are character substrings that
represent positive decimal integers: "1", "2", "45", etc.
The special value "0" indicates "no order". When n = "0", the policy
decision point is given no guidance on when to evaluate the associated
condition. When n = a positive integer, then the larger the value, the
lower the order of execution. Any condition that has n not equal to 0
is evaluated before any condition that has n equal to 0. All conditions
whose n is equal to 0 MAY be evaluated in ANY order, as long as all
conditions whose n is not equal to 0 have been evaluated first. Note
that n may not be a negative number.
If two or more identical non-zero values are included, the policy
decision point is being told to evaluate the conditions associated with
the repeated value in any order it chooses, but at the point where that
number falls in the overall sequence of conditions.
For example, suppose a policy decision point found the following three
values in the policyConditionList for a policy rule:
2:DN-1
0:DN-2
1:DN-3
0:DN-4
Policy Framework WG Expires May 1999 [Page 14]
Internet Draft Core Policy Schema November 1998
These values tell the policy decision point to evaluate the condition
named by DN-3 before it evaluates the one named by DN-1, and to
evaluate either the one named by DN-2 or the one named by DN-4 in any
order, so long as they are evaluated after DN-1 and DN-3 have been
evaluated.
The attribute definition is as follows:
NAME policyConditionList
DESCRIPTION An ordered list of DN pointers indicating a
recommended order for evaluating policy conditions.
SYNTAX OctetString
OID <to be assigned>
EQUALITY caseOctetStringOrderingMatch
MULTI-VALUED
FORMAT n:DN
5.4.6 The Attribute policyActionList
This attribute provides an ORDERED list of DN pointers to a set of
policy actions associated with this policy rule. The order indicates
the order in which the actions MUST be performed by the policy
decision point. If a policy decision point cannot perform the actions
in the indicated order, then an error condition must be raised.
Subclasses of policyRule may, however, override this rule. This may be
done by, for example, stating that if a policy decision point cannot
perform the actions in the indicated order, then it must not perform
them at all.
The ordering of the actions has the same semantics as the ordering of
the conditions in the policyConditionList attribute.
The attribute definition is as follows:
NAME policyActionList
DESCRIPTION An ordered list of DN pointers indicating the
order in which policy actions SHOULD be performed.
SYNTAX OctetString
OID <to be assigned>
EQUALITY caseOctetStringOrderingMatch
MULTI-VALUED
FORMAT n:DN
5.4.7 The Attribute policyRulePriority
This attribute provides a positive integer for prioritizing policy
Rules relative to each other. For policy rules that have this
attribute, smaller integer values indicate higher priority. Since one
purpose of this attribute is to allow specific, ad hoc policy rules to
override established policy rules temporarily, an instance that has
this attribute has a higher priority than all instances that lacks it.
Policy Framework WG Expires May 1999 [Page 15]
Internet Draft Core Policy Schema November 1998
Prioritization among policy rules is important only when policy rules
involve both conditions that can be satisfied simultaneously and
actions that are incompatible. For example, one policy rule might
specify that all Telnet traffic is to be placed on the medium-priority
queue, while a second policy rule specifies that all traffic from a
particular IP address is to be placed on the high-priority queue. If
Telnet traffic can flow from or to the IP address whose traffic is to
be placed on the high-priority queue, then these two rules conflict. A
policy decision point can determine which queue should be used for
Telnet traffic from this particular IP address based on which of the
two (conflicting) policy rules has the higher priority.
The attribute definition is as follows:
NAME policyRulePriority
DESCRIPTION A positive integer for prioritizing this policy rule
relative to other policy rules in the directory. A
smaller value indicates a higher priority.
SYNTAX INTEGER
OID <to be assigned>
EQUALITY integerMatch
SINGLE-VALUED
5.4.8 The Attribute policyErrorCode
This attribute is used in conjunction with the policyErrorDescription
attribute to provide an indication of an error in executing a policy.
The policyErrorCode attribute provides a generalized error code
indicating a policy failure.
The attribute definition is as follows:
NAME policyErrorCode
DESCRIPTION A generalized error code used to indicate that this
policy rule failed to evaluate or execute properly.
SYNTAX INTEGER
OID <to be assigned>
EQUALITY integerMatch
SINGLE-VALUED
5.4.9 The Attribute policyErrorDescription
This attribute is used in conjunction with the policyErrorCode
attribute to provide an indication of an error in executing a policy.
The policyErrorDescription attribute provides a detailed description
of the specific type of policy failure encountered.
The attribute definition is as follows:
Policy Framework WG Expires May 1999 [Page 16]
Internet Draft Core Policy Schema November 1998
NAME policyErrorDescription
DESCRIPTION A detailed description of the error that occurred
When this policy rule failed to evaluate or execute
properly.
SYNTAX IA5String
OID <to be assigned>
EQUALITY caseExactIA5Match
SINGLE-VALUED
5.4.10 The Attribute policyKeywords
This attribute provides a set of one or more ad hoc keywords that a
policy administrator may define to assist directory clients in locating
the policy rules applicable to them. Values for this attribute are
installation dependent, and thus are not specified in any schema
document.
The attribute definition is as follows:
NAME policyKeywords
DESCRIPTION A set of ad hoc keywords to assist directory clients
in locating the policy rules applicable to them.
SYNTAX IA5String
OID <to be assigned>
EQUALITY caseExactIA5Match
MULTI-VALUED
5.4.11 The Attribute policyModality
This attribute specifies whether the action(s) specified in this policy
rule should be applied if the condition(s) is satisfied (value = 0) or
not satisfied (value = 1).
The attribute definition is as follows:
NAME policyModality
DESCRIPTION Specifies whether the actions of this policy rule
should be executed if the conditions are satisfied
(value = 0) or not satisfied (value = 1).
SYNTAX INTEGER
OID <to be assigned>
EQUALITY integerMatch
SINGLE-VALUED
5.4.12 The Attribute policyType
This attribute is used to specify the type of policy that this policy
rule is. This can be used for classification (service policy or usage
policy) or categorization (the type of service or usage policy that
this policy is).
Policy Framework WG Expires May 1999 [Page 17]
Internet Draft Core Policy Schema November 1998
The attribute definition is as follows:
NAME policyType
DESCRIPTION Defines the type of policy that this policy is. This
is used to help classify and categorize policies.
SYNTAX INTEGER
OID <to be assigned>
EQUALITY integerMatch
SINGLE-VALUED
5.4.13 The Attribute policyUsage
This attribute is used to provide guidelines on how this policy should
be used.
The attribute definition is as follows:
NAME policyUsage
DESCRIPTION This attribute is used to provide guidelines on how
this policy should be used.
SYNTAX DirectoryString
OID <to be assigned>
EQUALITY caseIgnoreMatch
SINGLE-VALUED
5.5 The Class policyValidityPeriod
This class provides a means of representing the time periods during
which a policy rule is valid, i.e., active. At all times that fall
outside these time periods, the policy rule has no effect. A policy
rule is treated as valid at all times if it does not specify a
policyValidityPeriod (i.e., if it has a null policyValidityPeriodRef
attribute).
Instances of this class may have up to five attributes identifying time
periods at different levels. The values of all the attributes present
in an instance are AND-ed together to determine the validity period(s)
for the instance. For example, an instance with an overall validity
range of January 1, 1999 through December 31, 1999; a month mask of
"001100000000" (March and April); a day-of-the-week mask of "0000100"
(Fridays); and a time of day range of 8 AM through 4 PM would represent
the following validity periods:
Friday, March 5, 1999, from 8 AM through 4 PM;
Friday, March 12, 1999, from 8 AM through 4 PM;
Friday, March 19, 1999, from 8 AM through 4 PM;
Friday, March 26, 1999, from 8 AM through 4 PM;
Friday, April 3, 1999, from 8 AM through 4 PM;
Friday, April 10, 1999, from 8 AM through 4 PM;
Friday, April 17, 1999, from 8 AM through 4 PM;
Friday, April 24, 1999, from 8 AM through 4 PM.
Policy Framework WG Expires May 1999 [Page 18]
Internet Draft Core Policy Schema November 1998
Attributes not present in an instance of policyValidityPeriod are
implicitly treated as having the "always enabled" value. Thus, in the
example above, the day-of-the-month mask is not present, and so the
validity period for the instance implicitly includes a day-of-the-month
mask containing 31 1's. If we apply this "missing attribute" rule to
its fullest, we see that there is a second way to indicate that a
policy rule is always enabled: have it point to an instance of
policyValidityPeriod whose only attribute is policyValidityPeriodName.
The class definition is as follows:
NAME policyValidityPeriod
DESCRIPTION A class that provides the capability of
enabling / disabling a policy rule according
to a pre-determined schedule.
DERIVED FROM top
TYPE structural
AUXILIARY CLASSES none
POSSIBLE SUPERIORS
OID <to be assigned>
MUST cn
policyValidityPeriodName
MAY policyValidityPeriodTime
policyValidityMonthMask
policyValidityDayOfMonthMask
policyValidityDayOfWeekMask
policyValidityTimeOfDayRange
5.5.1 The Attribute cn
This is the exact same definition as in Section 5.2.1. It is repeated
here because the PolicyGroup and PolicyRule classes are siblings, and
both require a naming attribute.
5.5.2 The Attribute policyValidityPeriodName
This attribute provides a user-friendly name for a policy validity
period. The attribute definition is as follows:
NAME policyValidityPeriodName
DESCRIPTION The user-friendly name of this entry.
SYNTAX IA5String
OID <to be assigned>
EQUALITY caseExactIA5Match
SINGLE-VALUED
Policy Framework WG Expires May 1999 [Page 19]
Internet Draft Core Policy Schema November 1998
5.5.3 The Attribute policyValidityPeriodTime
This attribute identifies an overall range of calendar dates / times
over which a policy rule is valid. It is formatted as a string
containing two dates / times, separated by a colon (':'), optionally
followed by a second colon and a value indicating offset from UTC. The
first date indicates the beginning of the range, while the second date
indicates the end. Thus the second date / time must be later than the
first. Dates are expressed as substrings of the form "yyyymmddhhmmss".
The UTC offset indicator is either a 'Z', indicating UTC, or a
Substring of the form
'+' or '-' direction from UTC: '+' = east, '-' = west
hh hours from UTC (00..13)
mm minutes from UTC (00..59)
If the time zone indicator is omitted, the time is interpreted as the
local time at the policy decision point.
Examples:
19990101080000:19990131120000
January 1, 1999, 8 AM through January 31, 1999, noon (local time)
19990101080000:19990131120000:Z
January 1, 1999, 8 AM through January 31, 1999, noon (UTC)
19990101080000:19990131120000:-0500
January 1, 1999, 8 AM through January 31, 1999, noon (US EST)
The attribute definition is as follows:
NAME policyValidityPeriodTime
DESCRIPTION The range of calendar dates on which a
policy rule is valid.
SYNTAX Printable String
OID <to be assigned>
EQUALITY caseIgnoreMatch
SINGLE-VALUED
FORMAT yyyymmddhhmmss:yyyymmddhhmmss[:<UTC offset>]
5.5.4 The Attribute policyValidityMonthMask
This attribute identifies the months of the year in which a policy rule
is valid. It is formatted as a string containing 12 ASCII '0's and
'1's, where the '1's identify the months (beginning with January) in
which the policy rule is valid. The value "000010010000", for example,
indicates that a policy rule is valid only in the months May and
August.
The attribute definition is as follows:
Policy Framework WG Expires May 1999 [Page 20]
Internet Draft Core Policy Schema November 1998
NAME policyValidityMonthMask
DESCRIPTION A mask identifying the months of the year in
which a policy rule is valid.
SYNTAX Printable String
OID <to be assigned>
EQUALITY caseIgnoreMatch
SINGLE-VALUED
FORMAT A string of 12 ASCII '0's and '1's.
5.5.5 The Attribute policyValidityDayOfMonthMask
This attribute identifies the days of the month on which a policy rule
is valid. It is formatted as a string containing 31 ASCII '0's and
'1's, where the '1's identify the days of the month (beginning with day
1 and going up through day 31) on which the policy rule is valid. The
value "1110000000000000000000000000000", for example, indicates that a
policy rule is valid only on the first three days of each month. For
months with fewer than 31 days, the digits corresponding to days that
the months do not have are ignored.
The attribute definition is as follows:
NAME policyValidityDayOfMonthMask
DESCRIPTION A mask identifying the days of the month
on which a policy rule is valid.
SYNTAX Printable String
OID <to be assigned>
EQUALITY caseIgnoreMatch
SINGLE-VALUED
FORMAT A string of 31 ASCII '0's and '1's.
5.5.6 The Attribute policyValidityDayOfWeekMask
This attribute identifies the days of the week on which a policy rule
Is valid. It is formatted as a string containing 7 ASCII '0's and
'1's, where the '1's identify the days of the week (beginning with
Monday and going up through Sunday) on which the policy rule is valid.
The value "1111100", for example, indicates that a policy rule is valid
Monday through Friday.
The attribute definition is as follows:
NAME policyValidityDayOfWeekMask
DESCRIPTION A mask identifying the days of the week
on which a policy rule is valid.
SYNTAX Printable String
OID <to be assigned>
EQUALITY caseIgnoreMatch
SINGLE-VALUED
FORMAT A string of 7 ASCII '0's and '1's.
Policy Framework WG Expires May 1999 [Page 21]
Internet Draft Core Policy Schema November 1998
5.5.7 The Attribute policyValidityTimeOfDayRange
This attribute identifies a range of times over which a policy rule is
valid. It is formatted as a string containing two times, separated by
a colon (':'), optionally followed by a second colon and a value
indicating offset from UTC. The first time indicates the beginning of
the range, while the second time indicates the end. Times are
expressed as substrings of the form "hhmmss".
The second substring always identifies a later time than the first
substring. To allow for ranges that span midnight, however, the value
of the second string may be smaller than the value of the first
substring. Thus "080000:210000" identifies the range from 8 AM until 9
PM, while "210000:080000" identifies the range from 9 PM until 8 AM of
the following day.
When a range spans midnight, it by definition includes parts of two
successive days. When one of these days is selected by the
intersection of the policyValidityMonthMask,
policyValidityDayOfMonthMask, and policyValidityDayOfWeekMask, but the
other day is not, then the policy is active only during the portion of
the range that falls on the selected day. For example, if the range
extends from 9 PM until 8 AM, and the day of week mask selects Monday
and Tuesday, then the policy is active during the following three intervals:
From midnight Sunday until 8 AM Monday; From 9 PM Monday until 8 AM
Tuesday; From 9 PM Tuesday until 11:59:59 Tuesday.
The UTC offset indicator is either a 'Z', indicating UTC, or a
Substring of the form
'+' or '-' direction from UTC: '+' = east, '-' = west
hh hours from UTC (00..13)
mm minutes from UTC (00..59)
If the time zone indicator is omitted, the time is interpreted as the
local time at the policy decision point. See the examples of the
different kinds of UTC offsets under the policyValidityPeriodTime
attribute.
The attribute definition is as follows:
NAME policyValidityTimeOfDayRange
DESCRIPTION The range of times at which a policy rule
is valid. If the second time is earlier
than the first, then the interval spans
midnight.
SYNTAX Printable String
OID <to be assigned>
EQUALITY caseIgnoreMatch
SINGLE-VALUED
FORMAT hhmmss:hhmmss[:<UTC offset>]
Policy Framework WG Expires May 1999 [Page 22]
Internet Draft Core Policy Schema November 1998
5.6 The Class policyCondition
The class definition is as follows:
NAME policyCondition
DESCRIPTION A class representing a condition to be
evaluated in conjunction with a policy
rule.
DERIVED FROM top
TYPE structural
AUXILIARY CLASSES none
POSSIBLE SUPERIORS policyRule
OID <to be assigned>
MUST cn
policyConditionName
policyConstraintData
policyConstraintEncoding
5.6.1 The Attribute cn
This is the exact same definition as in Section 5.2.1. It is repeated
here because the PolicyGroup and PolicyRule classes are siblings, and
both require a naming attribute.
5.6.2 The Attribute policyConditionName
This attribute provides a user-friendly name for a policy condition.
The attribute definition is as follows:
NAME policyConditionName
DESCRIPTION The user-friendly name of this policy condition.
SYNTAX IA5String
OID <to be assigned>
EQUALITY caseExactIA5Match
SINGLE-VALUED
5.6.3 The Attribute policyConstraintData
This attribute provides an escape mechanism for representing policy
constraints that have not been modeled with specific attributes. The
format of the OctetString is left unspecified in this definition. It
is determined by the OID value stored in the attribute
policyConstraintEncoding. Since policyConstraintEncoding is
single-valued, all the values of policyConstraintData share the same
format and semantics.
A policy decision point can readily determine whether it supports the
values stored in an instance of policyConstraintData, by checking the
OID value from policyConstraintEncoding against the set of OIDs it
recognizes. The action for the policy decision point to take in case
it does not recognize the format of this data could itself be modeled
as a policy rule, governing the behavior of the policy decision point
itself.
Policy Framework WG Expires May 1999 [Page 23]
Internet Draft Core Policy Schema November 1998
The attribute definition is as follows:
NAME policyContraintData
DESCRIPTION Escape mechanism for representing constraints
that have not been modeled as specific attributes.
The format of the values is identified by the
OID stored in the attribute policyConstraintEncoding.
SYNTAX OctetString
OID <to be assigned>
EQUALITY octetStringMatch
MULTI-VALUED
5.6.4 The Attribute policyConstraintEncoding
This attribute identifies the encoding and semantics of the values of
policyConstraintData in this instance. The value of this attribute is
a single OID.
The attribute definition is as follows:
NAME policyContraintEncoding
DESCRIPTION An OID identifying the format and semantics for
this instance's policyConstraintData attribute.
SYNTAX OID
OID <to be assigned>
EQUALITY objectIdentifierMatch
SINGLE-VALUED
5.7 The Class policyAction
The class definition is as follows:
NAME policyAction
DESCRIPTION A class representing an action to be performed
as a result of a policy rule.
DERIVED FROM top
TYPE structural
AUXILIARY CLASSES none
POSSIBLE SUPERIORS policyRule
OID <to be assigned>
MUST cn
policyActionName
policyActionData
policyActionEncoding
Policy Framework WG Expires May 1999 [Page 24]
Internet Draft Core Policy Schema November 1998
5.7.1 The Attribute cn
This is the exact same definition as in Section 5.2.1. It is repeated
here because the PolicyGroup and PolicyRule classes are siblings, and
both require a naming attribute.
5.7.2 The Attribute policyActionName
This attribute provides a user-friendly name for a policy action. The
attribute definition is as follows:
NAME policyActionName
DESCRIPTION The user-friendly name of this policy action.
SYNTAX IA5String
OID <to be assigned>
EQUALITY caseExactIA5Match
SINGLE-VALUED
5.7.3 The Attribute policyActionData
This attribute provides an escape mechanism for representing policy
actions that have not been modeled with specific attributes. The
format of the OctetString is left unspecified in this definition. It
is determined by the OID value stored in the attribute
policyActionEncoding. Since policyActionEncoding is single-valued, all
the values of policyActionData share the same format and semantics.
A policy decision point can readily determine whether it supports the
values stored in an instance of policyActionData, by checking the OID
value from policyActionEncoding against the set of OIDs it recognizes.
The action for the policy decision point to take in case it does not
recognize the format of this data could itself be modeled as a policy
rule, governing the behavior of the policy decision point itself.
The attribute definition is as follows:
NAME policyActionData
DESCRIPTION Escape mechanism for representing actions
that have not been modeled as specific attributes.
The format of the values is identified by the
OID stored in the attribute policyActionEncoding.
SYNTAX OctetString
OID <to be assigned>
EQUALITY octetStringMatch
MULTI-VALUED
5.7.4 The Attribute policyActionEncoding
This attribute identifies the encoding and semantics of the values of
policyActionData in this instance. The value of this attribute is a
single OID.
Policy Framework WG Expires May 1999 [Page 25]
Internet Draft Core Policy Schema November 1998
The attribute definition is as follows:
NAME policyActionEncoding
DESCRIPTION An OID identifying the format and semantics for
this instance's policyActionData attribute.
SYNTAX OID
OID <to be assigned>
EQUALITY objectIdentifierMatch
SINGLE-VALUED
6.0 Extending the Core Schema
6.1 Subclassing policyCondition and policyAction
The simplest way of extending the core schema is to use the first four
classes as they are, and simply subclass policyCondition and
policyAction. An instance of policyRule ties everything together, with
its very simple, invariant semantics:
If the policyRule is active, then evaluate, possibly in a specified
order, all conditions pointed to by policyConditionList. If all
conditions evaluate to TRUE, then perform, possibly in a specified
order, all actions pointed to by policyActionList.
With this approach a new schema specifies the conditions it needs in
subclasses of policyCondition (or, better still, reuses conditions that
have already been specified in subclasses of policyCondition), and it
specifies (or reuses) the actions it needs in subclasses of
policyAction.
6.2 Subclassing policyRule
There are two possible ways to subclass policyRule, as described below.
6.2.1 Refining the Semantics of policyRule
This approach refines the structural and possibly behavioral semantics
of what it means to be a policy rule. For example, additional
attributes and relationships could be defined in a subclass of
policyRule. These attributes and relationships could provide extra
meaning for how to interpret the set of conditions and actions that a
policyRule aggregates.
6.2.2 Optimizing the computation of a policyRule
All preceding mechanisms for extending the core schema will work in all
cases, but they comes at a price: in order to fully understand a
policy rule, a client must retrieve at least three objects: a policy
rule, at least one policy condition, and at least one policy action. A
future version of this specification will define how to optimize the
evaluation of a policy rule.
Policy Framework WG Expires May 1999 [Page 26]
Internet Draft Core Policy Schema November 1998
6.3 Using policyConstraintEncoding and policyActionEncoding
As discussed in 5.6, "The Class policyCondition" on page 23, the
attributes policyConstraint and policyConstraintEncoding are included
in policyCondition to provide an escape mechanism for representing
"exceptional" policy conditions. The attributes policyAction and
policyActionEncoding play the same role with respect to actions. This
enables interoperability between different vendors. For example,
imagine a network comprised of access devices from vendor A, edge and
core devices from vendor B, and a policy server from vendor C. It is
desirable for the policy server to be able to configure and manage all
of the devices from vendors A and B. Unfortunately, these devices will
in general have little in common (e.g., different mechanisms, different
ways for controlling those mechanisms, different operating systems,
etc.). The escape conditions provide a way for vendor-specific commands
to be encoded as OctetStrings so that they can be commonly managed by
a single device.
7.0 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. The schema defined
in this document MUST not compromise either of these goals.
8.0 Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementers or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
Policy Framework WG Expires May 1999 [Page 27]
Internet Draft Core Policy Schema November 1998
9.0 Acknowledgments
This document is closely aligned with the work being done in the
Desktop Management Task Force (DMTF) Service Level Agreements and
Networks working groups. As noted, the core schema described here was
initially defined in references [2] and [3]. We would especially like
to thank Bob Moore, Lee Rafalow, Andrea Westerinen, and David Jones
for their helpful comments.
10.0 References
[1] Strassner, J., and E. Ellesson, "Terminology for describing
network policy and services", Internet-Draft work in progress,
August 1998.
[2] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan,
"An LDAP Schema for Configuration and Administration of IPSec
based Virtual Private Networks (VPNs)", Internet-Draft work in
progress, October 1998
[3] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, D.
Verma, G. Powers, R. Yavatkar, "Schema for Differentiated Services
and Integrated Services in Networks", Internet-Draft work in
progress, October 1998
[4] Judd, S., and J. Strassner, "Directory-enabled Networks",
version 3.0c5 (August 1998).
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF
Standards Process", BCP 11, RFC 2028, October 1996.
11.0 Authors' Addresses
John Strassner
Bldg 1
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: +1-408-527-1069
Fax: +1-408-527-1722
E-mail: johns@cisco.com
Ed Ellesson
JDGA/501
IBM Corporation
4205 S. Miami Blvd.
Research Triangle Park, NC 27709
Phone: +1-919-254-4115
Fax: +1-919-254-6243
E-mail: ellesson@raleigh.ibm.com
Policy Framework WG Expires May 1999 [Page 28]
Internet Draft Core Policy Schema November 1998
12.0 Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Policy Framework WG Expires May 1999 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-23 20:16:40 |