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]
