Internet Draft Hugh Mahon Expiration: May 2001 Hewlett-Packard File: draft-mahon-policy-mgmt-00.txt Yoram Bernet Microsoft Shai Herzog IP Highway November 9, 2000 Managing a Policy Management System Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 made obsolete 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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document contains information about uses of a policy manage- ment system, considerations for administrators, and general information about issues for policy based management. Internet Draft Policy Management November 2000 This document is one of several documents describing multiple aspects of policy management. For more documents relating to policy management see the Web page for the IETF Policy Framework Working Group under the IETF home page (http://www.ietf.org/). This document is the result of discussions, e-mail, and other communications within the Policy Framework Working Group and among individuals. Table of Contents 1. Introduction ......................................... 2 2. General Policy Management Issues ..................... 2 2.1 Provisioned vs. Signaled QoS Mechanisms ............. 2 2.2 Policy assignment ................................... 4 2.2.1 Policy applicability .............................. 6 2.3 Policy Operation .................................... 6 2.3.1 Policy Size ....................................... 7 2.3.2 Policy Capability ................................. 8 2.4 Policy Conflicts .................................... 9 2.4.1 Conflict Between Two Rules Within a Policy ........ 9 2.4.2 Conflicts Between Actions Within a Rule ........... 10 2.4.3 Conflict (Inconsistency) Between Policies ......... 10 2.5 Time aspects of policy .............................. 11 3. Security Considerations .............................. 12 4. Intellectual Property ................................ 13 5. References ........................................... 13 6. Acknowledgements ..................................... 14 7. Author Information ................................... 14 8. Full Copyright Statement ............................. 15 1. Introduction 2. General Policy Management Issues There are many areas that need to be covered to develop policy based management. This document is 2.1. Provisioned vs. Signaled QoS Mechanisms There are two mechanisms by which resources may be allo- cated: provisioned (or pre-defined, or pro-active) and sig- naled (or on-demand, or reactive). Each has their strengths and weaknesses. With provisioned mechanisms, traffic treatment (such as CAR, priority, shaping, etc.) can be specified as well as Mahon,Bernet,Herzog Expires May 2001 [Page 2] Internet Draft Policy Management November 2000 the characteristics of the traffic to receive that treat- ment (i.e., packet header information such as source and destination IP address, IP port numbers, etc.). An admin- istrator would observe traffic patterns on the network, compare that with the desired state (based on business or operational needs), and then craft policies which allocate resources accordingly. Such mechanisms may work quite well for traffic such as HTTP, telnet, or FTP, which are toler- ant of variance in flow quality (jitter, packet re-order- ing, etc.), but still can benefit from having greater throughput provided by the above mentioned QoS mechanisms. The stength of signaling, simply put, is that it enables parts of the network to offer high quality guarantees, and to simultaneously be used efficiently. Without signaling, it is necessary either to compromise the quality of the guarantees, or to over-provision parts of the network. In certain parts of the network, over-provisioning may be a viable option. However, in other parts it may not. If the network administrator is to have the flexibility to not over-provision those parts of the network which would be prohibitively expensive to over-provision *and* to support high quality guarantees through them, then end to end sig- naling must be availble to be used for policy based admis- sion control decisions. Signaling mechanisms can provide information beyond the QoS needs of the traffic for which it is signaling. User information (not available in packet headers), and applica- tion identification (which would be hidden by IPSec, or unavailable if well-known or registered ports aren't used) can be provided, thus allowing higher quality information about the traffic than may be available otherwise. Since network administrators manage in temrs of users and applications, and network devices classify in terms of IP addresses and ports, any mechanism which improves the bind- ing of users/applications to IP addresses and ports (or laternate classification criteria in the case of IPSec), improve the manageability of the network. But the greatest value of the signal is that by traversing the same path in the network as the traffic for which it is signaling, it can communicate the specific QoS needs for the connection. If the needs cannot be met anywhere along the path, an explicit notification is provided, effectively a 'busy signal', notifying the application that it will not get the desired QoS. The signal, then, acts as a horizontal communication mecha- nism assuring resource allocation along the path of a con- nection, coordinating the QoS mechanisms to ensure expected treatement for the traffic. In contrast, provisioned Mahon,Bernet,Herzog Expires May 2001 [Page 3] Internet Draft Policy Management November 2000 mechanisms will act as individual points to provide pre- specified levels of QoS, unaware of what other devices are doing. Why, then, wouldn't signaling be used for all traffic for which better than best effort QoS is desired? The signal- ing does incur a cost in additional network traffic, set up time, and processing on the devices and end systems involved. Such overhead makes sense for connections that will last for a minute or more, or where variance in QoS can produce dramatically undesirable results. VoIP fits both criteria. Traffic whose connections are short-lived (e.g., HTTP), or can tolerate variable QoS within limits (e.g., telnet, FTP), may not warrant such overhead. A common need for both signaled and provisioned QoS mecha- nisms, though, is policy. It is with policies that the administrator would specify how much resource is to be allocated to any particular use, whether it is to allow a certain amount of bandwidth to be used for all VoIP traf- fic, or limit how much bandwidth a single connection can use (for example to prevent a single user from allocating the entire VoIP bandwidth to send high quality audio to a friend). Related to the provisioned vs. signaled models is the use of outsourcing vs. pre-configuration. Signaling lends itself to outsourcing of policy based decisions better than provisioned because of the granularity provided by the sig- nal (one or a few signals for a connection that lasts a long time versus classifying each packet). This, however, doesn't mean that to use RSVP a device must use an external PDP. It could use a local PDP (in the device) if it has sufficient processing capability. Conversely, a device that uses provisioned QoS mechanisms may outsource a deci- sion when it recognizes a new flow, and then cache the packet header information to provide policy specified QoS for the rest of the flow. 2.2. Policy Assignment Policies must be associated with a manageable entity, which in this document are called Policy Targets. For example, a router has multiple interfaces on it, and each interface is an ingress point to a network (LAN, WAN, backbone, etc.). Many such devices have the ability to affect the Quality of Service of traffic going out through these interfaces (as opposed to coming in through an interface). It is these interfaces, which are the control points, which are the targets of QoS policies. Mahon,Bernet,Herzog Expires May 2001 [Page 4] Internet Draft Policy Management November 2000 +---+ +----+ | |Client A | |Server 1 | |\ /| | +---+ \ +---------+ / +----+ \ |Network | / Dept +----|element |-----+ Corporate WAN / Int1| |Int2 \ / +---------+ \ +---+/ \+----+ | | | | | |Server 2 | |Client B +---+ +----+ Figure 1. Policy assignment example. Figure 1 represents a simple schematic of two networks con- nected by a network element (e.g., a router). In this example, the network element does not have the ability to control traffic entering on an interface, but can control (via queues, marking, etc.) the traffic going out through an interface. One network is a Departmental LAN, and the other is a Cor- porate WAN. The network element connecting these two net- works has two interfaces, Int1 and Int2. The traffic going in to the Dept. LAN will be regulated at Int1, while the traffic going to the Corporate WAN will be regulated at Int2. To control traffic going from the Dept. LAN to the Corp. WAN, a policy would be deployed to Int2, whether it is traffic which is returning to Client B from Server 2 or is traffic from Client A to Server 1. Conversely, traffic entering the Dept. LAN is controlled by Int1, whether the traffic is a request to Server 2 or a response to Client A. The distinction between the interfaces, and the policies targeted to each is important for many reasons. For exam- ple, if the manager of the Dept. LAN wanted to set higher priority for Web usage of users of the Dept. LAN than Web usage from outside of the Dept. LAN (i.e., to the Web servers on the Dept. LAN from the rest of the company), then the policies affecting the traffic must be structured in one of two ways: 1. The policies deployed to Int1 are different than poli- cies deployed to Int2 and the conditions can refer to traffic type only (e.g., source and destination IP Port numbers). Mahon,Bernet,Herzog Expires May 2001 [Page 5] Internet Draft Policy Management November 2000 2. The policies deployed to Int1 and Int2 are the same, and the conditions refer not only to the traffic types, but to the source or destination addresses or subnets. Either approach is valid. The advantage to #1 is that the policy will be smaller, and should require less memory and processing on the network element to implement (the number of 'ifs' that must be processed to implement the policy would be smaller). Of course, the same policy can be deployed anywhere else in the network if the same kinds of behaviors are desired at one or more specific points in the network. And because specific addresses or subnets are not used, the policy is easily reused (if only traffic type is the characteristic). The disadvantage of #2 is that it would be larger, since it is specifying the behavior for flowing out both interfaces, and thus would cause policy which would be used only on Int2 (in this example) to be installed on Int1, and vice- versa. The advantage of this approach is that the adminis- trator may install this same policy anywhere in the network and it will yield the same behavior, reducing the number of policies the administrator would need to author and track. 2.2.1. Policy applicability It is important to point out that while this document often refers to policy applying to a 'device', policy is applicable to other logical entities as well. A network stack within a general computer system (i.e., host com- puter), an application running on a host computer, a firewall application running on a host computer, etc. Thus, in the QoS example of policies, policy may be applied to any physical or logical entity which gener- ates, handles, or otherwise impacts the flow of network traffic. 2.3. Policy Operation There are many considerations regarding policy when it is used to configure a device (as opposed to the decision out- sourcing mode described by the COPS RSVP PDP/PEP interac- tion). How large are policies, what are the implications of expan- sion, and even how well could policy map to a specific device can enter into the usage of policy when specific devices (instead of 'typical') are considered. This dis- cussion is not intended to prescribe a 'least common denom- inator' model for policy, but to describe how policy may be Mahon,Bernet,Herzog Expires May 2001 [Page 6] Internet Draft Policy Management November 2000 used with devices with limited capabilities. 2.3.1. Policy Size Policy to express a certain set of behaviors may take different sizes. The number of Policy Rules contained within a given Policy, the number of conditions, etc., all depend on the requirements placed on the Administra- tor. While the intent of policy is to reduce device specific considerations visible to the administrator it will be difficult to eliminate all device considerations. This is not unlike the fact that a PC user today must be cog- nizant of whether or not a given application will work on a PC equipped with a given amount of RAM. Discussions with Network Administrators have revealed that many do not wish to use more than a handful (4 or 5) of classes of network traffic. This may result in only 4 or 5 rules within a policy. Of course, how those classes are defined may vary. Below are some examples of how classes of traffic may be identified: 1. destIPsubnet == 192.168.32.0/255.255.248.0 && destIPport == 80 2. srcIPport = 25 3. srcIPsubnet == 192.168.32.0/255.255.248.0 && dayOfWeek == _MTWRF_ The following is a sample policy rule specifying traffic of a given type (HTTP) going between two machines: if ((srcIPaddr == 192.168.2.4) && (destIPaddr == 192.168.72.12) && (destIPport == 80)) then priority=6 else if ((destIPaddr == 192.168.2.4) && (srcIPaddr == 192.168.72.12) && (srcIPport == 80)) then priority=6 endif The translation of the above rules would be fairly sim- ple. Some devices can handle many rules such as those above, while other devices can only handle relatively few (e.g., 16 or less). Mahon,Bernet,Herzog Expires May 2001 [Page 7] Internet Draft Policy Management November 2000 Sizing of policy can also affect performance. For exam- ple, a router could experience greater latency in for- warding a packet if too many rules (or rules containing many condition lists) were configured on the device. On the other hand, a firewall configured with security pol- icy may have no problem handling a hundred or more rules describing what traffic is to be allowed through the firewall. The size of policy on the Policy Target, therefore, is a combination of the complexity of the number of Policy Rules and the actions and conditions expressed in the policy as well as the capabilities of the device itself relative to the ability of the policy to be expressed in the configuration commands of the device. The same pol- icy may consume less memory on one device than on another because of differences in the configuration capabilities of the two devices. 2.3.2. Policy Capability If a device has the ability to control traffic and can exert that control by basing the behavior on things such as information in the packet header, it is a candidate for use with QoS policies. (The criteria for whether or not something can be used with policy is dependent on what capability, functionality, or behavior the policy types involved are abstracting.) Not all devices have the same capabilities. While a policy type may be able to be mapped to a function on a device, that device may not offer all of the conditions (means for classification) that other devices with simi- lar functions offer. For example, a policy for specify- ing Committed Rate may use the value of the IP Prece- dence field to classify traffic. A particular router may not be able to handle this feature. If a policy with IP Precedence in a rule condition is targeted for a device which cannot use IP Precedence, the UI should notify the user and prevent deployment. At a minimum, if the UI is not equipped for this, the Policy Consumer should return a status message that the policy was not implementable on the Policy Target (if there was no work-around by using some other feature of the target). In another variation on the capabilities of a device, not all devices can handle multiple conditions which together identify traffic. (This may not apply to time conditions.) If a Rule within a Policy contains multi- ple conditions, and the Target is on a device which can- not handle such a Rule, the Administrator should receive a message indicating an error in the Policy. Mahon,Bernet,Herzog Expires May 2001 [Page 8] Internet Draft Policy Management November 2000 Some devices are simply limited in the number of rules, or the total number of conditions within rules, that can be evaluated. In such a case the Policy Consumer (or some element higher in the system) should provide feed- back of this limitation. 2.4. Policy Conflicts There are two types of policy conflicts that could exist: 1. conflicts between two rules within a policy 2. conflicts between actions within a rule 2.4.1. Conflict Between Two Rules Within a Policy Within a Policy Group are one or more Policy Rules. As defined in [INFOMODEL] these Policy Rules contain Policy Actions and Policy Conditions. Within a single Policy, it is possible to have more than one Policy Rule which will evaluate 'true' for one cir- cumstance. The oft cited example is as follows: Rule 1 if (srcIPaddr == 192.168.2.3) Priority=5 Rule 2 if (srcIPsubnet == 192.168.1.0/255.255.248.0) Priority=3 ... In the above example, both Rule 1 and Rule 2 would eval- uate true if the source IP address were 192.168.2.3. If a configuration were to be entered into an existing device (e.g., a router) to implement this behavior there would be a forced ordering of evaluation, so that the first match would be the action implemented. The Policy Framework WG currently defines in the Core Information Model a priority value associated with the Policy Rule. This priority is used by the administrator to set which Policy Rule is to have a higher priority, so that if more than one Policy Rule can evaluate as true, which Policy Rule has precedence. Unfortunately there is no uniqueness to the priority value, so that it is still possible to have multiple rules which could evaluate true and there is no way for the system to determine which has higher priority. Mahon,Bernet,Herzog Expires May 2001 [Page 9] Internet Draft Policy Management November 2000 The problem with the priority approach is that since priority values need not be unique for a given set of rules, different systems may choose different rules to apply given the same input, which would lead to incon- sistent QoS for traffic matching the multiple Policy Rules. Rule evaluation must be deterministic, such that the same policy, encountering the same input conditions, renders the same results wherever the policy is installed. Rule evaluation must be clearly determinable in order for the administrator to properly specify and understand how the policy (containing multiple rules) will operate in the managed environment. Without such determinism, policy will not meet the needs of those interested in using it. 2.4.2. Conflicts Between Actions Within a Rule If a rule contains multiple actions, it is possible that the actions (or the results of the actions) will con- flict with each other. An example of this is that one action sets one type of queueing on a device, and the other action sets another type of queueing, which for that particular device are incompatible. For each type of device such conflict may be detectable, but in a gen- eral case may not be. 2.4.3. Conflict (Inconsistency) Between Policies When multiple policies are deployed throughout the net- work it is possible that the behavior specified in one location will not be the same as behavior specified in another location. +----------+ +----------+ |Net Elem A| |Net Elem B| LAN Alpha | | LAN Beta | | LAN Gamma +--------+Int1 Int2+----------+Int3 Int4+---------- | | | | | +--+-----+ | | | | |User PC | +----------+ +----------+ | | +--------+ Figure 2. In Figure 2 there are two network elements, A and B, which are connected together serially, and traffic may pass from LAN Alpha through LAN Beta to LAN Gamma. If a user on LAN Alpha expects to have the same QoS when com- municating with systems on LAN Beta and LAN Gamma, then the subset of policy (i.e., rules) pertaining to the Mahon,Bernet,Herzog Expires May 2001 [Page 10] Internet Draft Policy Management November 2000 user's traffic (based on address, traffic type, or other characteristic) deployed on the interfaces of network elements A and B must agree. If all of the LANs are being maintained by one IT department, and the user has contracted for 200 kbps for traffic to systems on LAN Gamma, then the policies deployed on interfaces 1, 2, 3, and 4 must all support at least that much throughput for the user. For instance, if policy deployed to Int2 and Int4 allow 200kbps for traffic coming from the user's machine, and policy deployed to Int1 and Int3 only allowed 150kbps of traffic to the user's PC, then the policies deployed to Int1 and Int3 could be in conflict with the policies deployed to Int2 and Int4. For policy management such a conflict should be detected before the user complains about lower than expected per- formance. The means for such detection would need to be in policy system at a point where the policies are visible. That is, Int1 cannot determine that its policies are in con- flict with Int2 unless it has visibility into the poli- cies for Int2. Network Element A cannot determine that the policies for it are in conflict with the policies for NE B unless it can see the policies for NE B. There are many reasons that make it undesirable for all policy managed entities to see the policy for all other policy managed entities on the network. It makes sense, then, for the function to determine con- flict between policies to be implemented in the policy system before policies are deployed to their targets (or the Policy Consumers for those targets). Determining conflicts such as those described above may not be possible with policy information alone. It may be necessary to have a higher level, or different, set of information which describes the actual service that is to be delivered. Because inter-policy conflict is such an unknown, it recommended that inter-policy conflict not be a require- ment for (early) policy management systems. A standard for policy management systems should, however, allow for the the use of conflict detection functions, or at a minimum not preclude their use. 2.5. Time Aspects of Policy With the policyTimePeriodCondition (and the PolicyRuleVa- lidityPeriod condition as part of the Policy Rule) it is Mahon,Bernet,Herzog Expires May 2001 [Page 11] Internet Draft Policy Management November 2000 possible to have behaviors related to time. This leads to interesting possibilities for policy. With time-based policies Administrators may establish poli- cies to limit certain kinds of traffic to provide enough bandwidth for the nightly backup. Some customers may only want to pay for better QoS during business hours. Policy can be put in place to allow an Accounting Department to have better QoS for accessing corporate financial informa- tion during the last three days of the month. All of these would be possible without the manual intervention of the Administrator at the time the policies are to go into or out of effect. To take advantage of time-based policies, most existing devices (which do not have time- or date-based configura- tion capabilities) would need a Policy Consumer implemented separately from the device. New managed elements may be developed with time and date keeping functions on them, or Policy Targets may reside on a host system which has those functions. It is also possible that the Policy Management Application would change policy stored in the Policy Repository based on time. This would have the advantage of removing the need for time keeping on the Policy Target (or Policy Con- sumer), but it would mean that Policy data is not as static as currently expected. It also would cause a lag in deployment of Policy to the Target since more components are involved (the Policy Management Application, the Repos- itory if indirect delivery is involved, and the Policy Con- sumer). This could be solved, but a solution would make the entire system more expensive. Another affect of time-based policy is on the status of the policy deployment. Depending on the implementation of the Policy Consumer and the conflict detection mechanisms in the system (if any exist) there may be a problem with the policy information that is not visible until portions of the policy with time conditions become 'active'. In other words, portions of the policy (rules, or condition lists in a rule) with time conditions become 'active' when the time or date match values in the policyTimePeriodCondition. These rules or condition lists may contain information which brings the rule into conflict with one or more other rules. Or even worse, the time based rule may contain con- ditions which are not supported by the Policy Target. 3. Security Considerations The security requirements for policy management are addressed in more detail in other drafts relating to policy. A short Mahon,Bernet,Herzog Expires May 2001 [Page 12] Internet Draft Policy Management November 2000 list of the requirements for security related to policy includes: - authentication of server and client - provisions for ensuring integrity of policy information - security of the policy repository - encryption of policy information (especially for policy related to security) 4. 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 tech- nology 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 iden- tify 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 Sec- retariat. The IETF invites any interested party to bring to its atten- tion 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 infor- mation to the IETF Executive Director. 5. References [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [TERMINOLOGY] J. Strassner, E. Ellesson, "Terminology for describing network policy and services", Internet Draft draft-strassner-policy- terms-01.txt, February 1999. [INFOMODEL] B. Moore, E. Ellesson, J. Strassner, "Policy Framework Core Information Model", Internet Mahon,Bernet,Herzog Expires May 2001 [Page 13] Internet Draft Policy Management November 2000 Draft draft-ietf-policy-core-info- model-03.txt, January 2000. [POLFRAME] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, J. Wheeler, "Policy Framework", Internet Draft draft-ietf-policy-framework-00.txt, September 1999. [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Pol- icy Service) Protocol", RFC 2748, January 2000. 6. Acknowledgements Special thanks to Mark Stevens, Bob Moore, Andrea Westerinen, Avri Doria, Cheh Goh, Ken Owens, Rick Roeling, and Brian O'Keefe for input and feedback during the development of this draft. Thanks also go to Ed Ellesson and Bert Wijnan for their guidance on what should be discussed in this document. 7. Author Information Hugh Mahon Hewlett-Packard Co. 3404 East Harmony Road, MS A2 Fort Collins, CO 80528-9599 Phone: +1 970 898 2487 EMail: hugh_mahon@hp.com Yoram Bernet Microsoft 1 Microsoft Way Redmond, WA 98052 USA phone: +1 206 936 9568 email: yoramb@microsoft.com Shai Herzog IPHighway Parker Plaza, 16th Floor 400 Kelby St. Fort-Lee NJ 07024 201.585.0800 herzog@iphighway.com Mahon,Bernet,Herzog Expires May 2001 [Page 14] Internet Draft Policy Management November 2000 8. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and fur- nished to others, and derivative works that comment on or oth- erwise explain it or assist in its implementation may be pre- pared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copy- right 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 copy- right 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." Mahon,Bernet,Herzog Expires May 2001 [Page 15] Internet Draft Policy Management November 2000 1. Introduction ......................................... 2 2. General Policy Management Issues ..................... 2 2.1 Provisioned vs. Signaled QoS Mechanisms ............. 2 2.2 Policy assignment ................................... 4 2.2.1 Policy applicability .............................. 6 2.3 Policy Operation .................................... 6 2.3.1 Policy Size ....................................... 7 2.3.2 Policy Capability ................................. 8 2.4 Policy Conflicts .................................... 9 2.4.1 Conflict Between Two Rules Within a Policy ........ 9 2.4.2 Conflicts Between Actions Within a Rule ........... 10 2.4.3 Conflict (Inconsistency) Between Policies ......... 10 2.5 Time aspects of policy .............................. 11 3. Security Considerations .............................. 12 4. Intellectual Property ................................ 13 5. References ........................................... 13 6. Acknowledgements ..................................... 14 7. Author Information ................................... 14 8. Full Copyright Statement ............................. 15 Mahon,Bernet,Herzog Expires May 2001 [Page 16]