Network Working Group G. Waters INTERNET-DRAFT J. Wheeler Nortel Networks A. Westerinen Microsoft L. Rafalow R. Moore IBM February 1999 Policy Framework Architecture Friday, February 26, 1999, 4:28 PM 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 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 view the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document articulates the requirements and basic components of a policy-based management architecture. It focuses on the storage and retrieval of policy rules from a directory-based repository, for use in the management of network devices. The architecture is described in terms of its functional components and operational characteristics. It is intended to be device and vendor independent, interoperable and scalable. There are three basic sections of this draft, addressing: o the motivation for policy-based management that briefly describes the requirements for a policy framework architecture; Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 1] Internet Draft Policy Framework Architecture February 1999 o a reference model that defines a first-level functional decomposition and captures the key concepts in defining policy tools, policy rules, the use of a repository and schema, and the mechanisms underlying the definition, storage and retrieval of policies; and o an architecture that describes each of the functional components, and includes a narrative about how the architecture will execute. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 2] Internet Draft Policy Framework Architecture February 1999 Table of Contents 1. Introduction......................................................4 2. Terminology.......................................................5 3. Reference Model...................................................6 3.1. The Model....................................................6 3.2. Policy Prescription..........................................7 3.3. Policy Rules.................................................8 3.4. Policy Mechanisms............................................8 4. Architecture......................................................9 4.1. Functional Components of the Policy Architecture............10 4.1.1. Policy Editor.............................................10 4.1.2. Rule Translation..........................................10 4.1.3. Rule Validation...........................................11 4.1.4. Rule Storage and Retrieval................................12 4.1.5. Policy Trigger and Rule Location..........................12 4.1.6. State and Resource Validation.............................12 4.1.7. Device Adapter and Execution of Policy Actions............13 4.2. Interfacing with Components Outside the Policy Architecture.14 4.2.1. Network Manager...........................................14 4.2.2. AAA Service...............................................14 5. Policy Conflicts.................................................14 6. Interoperability.................................................15 7. Future: Inter-Network and Inter-Domain Communication.............16 8. Intellectual Property............................................16 9. Acknowledgements.................................................16 10. Security Considerations.........................................17 11. References......................................................17 12. Editors' Addresses..............................................17 13. Full Copyright Statement........................................18 1. Introduction Policy-based management involves the use of administratively prescribed rules that specify actions in response to defined criteria. Rules may be general and abstract, requiring interpretation by the policy framework, or very specific. They are condition/action pairs. Several components are critical to the definition of a policy architecture: 1. The ability to define and update policy rules. 2. The ability to store and retrieve rules. 3. The ability to decipher the conditional criteria of a rule. 4. The ability to take the specified actions of a rule, if the conditional criteria are met. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 3] Internet Draft Policy Framework Architecture February 1999 At the center of this architecture is the policy rule. Its format and storage are critical to a policy based management framework and addressed by the policy schema. The retrieval and execution of the policy rules can take many forms. No single implementation is generically correct. However, all implementations of a policy-based management architecture must address several key components. These are: 1. Interface to define and update rules - Either graphical or command line/script. 2. Repository to retain and retrieve rules. 3. Decision point to assess the conditional criteria of a rule. 4. Enforcement point to execute the actions of a rule, when the conditions evaluate to "true". Implementations may choose to add policy execution feedback (for example, to assess the effectiveness of an action in maintaining or changing state). However, this feature is not addressed in this memo. Several other concepts must also be understood and addressed in a policy architecture. These are the scope to which policy rules extend, rule conflict detection and resolution, and how interoperability is achieved. Each of these concepts is addressed in this draft. 2. Terminology The following terms are derived from those previously defined in the Internet Drafts, "Terminology for describing network policy and services" (draft-strassner-policy-terms-00.txt) [TERMS] and "A Framework for Policy-based Admission Control" (draft-ietf-rap- framework-01.txt) [RAPFRAME]. The concepts are summarized here, and made more specific, to establish the terminology used throughout the remainder of this document. Policy Conflict: Occurs when the conditions of two or more policies can be simultaneously satisfied, but the actions of at least one of the policies can not be simultaneously executed. Policy Consistency Checking: An analysis of policies to determine their consistency or possible inconsistency with each other. When an inconsistency is discovered, a policy discrepancy is reported. Policy Decision: The abstraction of evaluating the applicability of policy rules, compiling the applicable rules into a form that can be handled by the devices, and activating the compiled rules in the devices. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 4] Internet Draft Policy Framework Architecture February 1999 Policy Decision Point (PDP): The point where policy decisions are made. Policy Enforcement: The action of placing the network (or a part of the network) in a desired policy state using a set of actions specified in a policy rule. Policy Enforcement Point (PEP): The point where the policy decisions are actually enforced. Policy Rule: A specification of a sequence of actions to be initiated when a specified set of conditions is satisfied. A policy rule takes the form, IF THEN . Service Level Agreement (SLA): A service contract between a service consumer (customer) and a service provider or a bilateral agreement between service providers that specifies the expected operational characteristics of their relationship. The details of the operational characteristics are defined in terms of Service Level Objectives (SLOs). The SLA documents the agreed levels and parameters of services provided. Service Level Objective (SLO): Partitions an SLA into individual objectives that can be mapped into policies that can be executed. The SLOs define metrics to enforce, police, and/or monitor the SLA. 3. Reference Model 3.1. The Model This section describes a Basic Reference Model (BRM), a first-level functional decomposition for the policy framework, and describes the role of functional components in the model. The policy architecture (see section 4) will build upon this reference model and provide function and architecture details. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 5] Internet Draft Policy Framework Architecture February 1999 Policy prescriptions | V +--------------------+ | Policy | | Management Tool | +---------+----------+ | | <--- Repository Access Protocol | (e.g., LDAP) +---------+----------+ | Policy Repository | | (Directory Server, | <-- Policy rules | Database, etc. ) | +---------+----------+ | | <--- Repository Access Protocol | (e.g., LDAP) +---------+----------+ | Policy Decision | | Point (PDP) | +---------+----------+ | | <--- Policy Protocol for policy mechanisms | +---------+----------+ | Policy Enforcement | | Point (PEP) | +--------------------+ Figure 1. Reference Model Overview This reference model permits the implementation of three different abstractions of policies using the functional components shown in Figure 1 above. The policy framework does not require that all functional components be implemented nor does it specify implementation packaging of functional components. o The administrators' view of policy is an abstraction of general configuration and operational characteristics of the resources in a policy domain and of service-level objectives (SLOs) on these resources. SLOs are frequently derived from contractual service- level agreements (SLA) and may be probabilistic in nature. The Policy Management Tool may provide significant value-add in the level of abstraction and degree of sophistication of the GUI presentation and the mapping to and from the lower-level policy rule representation. o The policy rules, as stored in the policy repository using defined schemata, provide a deterministic set of policies for managing resources in the policy domain. These policy rules are produced by Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 6] Internet Draft Policy Framework Architecture February 1999 the Policy Management Tools and consumed by the Policy Decision Points (PDP). Policy rules are network device-independent. o The policy mechanisms are policy discipline-specific and may be implementation-specific. They are used for configuring the necessary logic in the respective network components, the Policy Enforcement Points (PEP), used to ultimately deliver the services as prescribed at the administrative interface of the Policy Management Tool. 3.2. Policy Prescription The administrative user of the Policy Management Tool functional component specifies abstract policies that have meaning to the administrator and, indirectly, the end user for whom the policy is prescribed. Although specific enough to implement service level objectives via the Policy Management Tools' abstraction of the policy rules and mechanisms, these administratively specified policy prescriptions are not generally specific enough to allow for direct mapping to network equipment configurations for deployment. It would be unusual for an administrator to specify policy for a specific traffic filter, amount of bandwidth, or for specific end-to-end latency from an application or user. The administrator will typically prescribe policies applying to end users, applications, and network devices within a policy domain. Policy domain boundaries may be defined in the context of business, administrative, geographical, and political constraints. For end-to- end service and service-level prescriptions, coordination between policy domains may be specified in either formal or informal service level agreements. The Policy Management Tool also provides the mapping of the prescribed policies to a set of policy rules. Policy Management Tools should implement consistency checking of the policy rules to verify that the policy rules are deterministic prior to placing them into the Policy Repository (see section 5). As stated previously, it is not necessary to employ all three functional components. The output of the Policy Management Tool may be to a legacy network management product, providing cross-table definitions to existing LAN and WAN Network Management services, ultimately providing input for device reconfiguration or filter/policy creation and implementation in network devices. It is also possible to implement the policy rules and policy mechanism layers without implementing a Policy Management Tool component. In fact, the central purpose of this architecture framework is to enable interoperable implementations of Policy Decision Points using common schema in a Policy Repository. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 7] Internet Draft Policy Framework Architecture February 1999 3.3. Policy Rules As previously noted, the Policy Management Tool functional component produces the policy rules and the Policy Decision Point components are consumers of the policy rules. The policy rules specify the logic used to deliver the prescribed service and service-levels. The PDP components interpret and may further validate the policy rules and then map these rules to the underlying policy mechanisms. Generally, policy rules are of the form: if then . The expression may be a compound expression and it may be related to entities such as hosts, applications, protocols, users, etc. The may be a set of actions that specify services to grant or deny or other parameters to be input to the provision of some service. Although other policy repositories are permitted in this framework, LDAP is specifically referenced in this architecture as the access protocol and schemata used to store the policy rules. In LDAP, then, the policy rules are represented as a set of object entries that include, among others, object classes for policy rules, for policy conditions and for policy actions. For LDAP implementations, PDPs may detect changes in policy rules by periodic polling, or preferably by use of the (currently draft) LDAP event notification mechanisms. Other notification mechanisms may also be defined but are outside the scope of this working group. 3.4. Policy Mechanisms Policy Mechanisms are defined as the underlying methods, protocols, and tools used to perform the actual implementation of the policy rules in the specific network devices. The PDP evaluates the policy rules and generates appropriate instructions for the Policy Enforcement Points (PEP) for which it provides the higher-level abstraction translation service. These policy discipline-specific and, perhaps, device-specific instructions may, for example, specify the traffic shaping parameters for a QOS policy or the address filters for a firewall policy. It is not in the scope of this architecture framework to specify actual mechanisms, but to provide a common interface through policy rule abstraction for access to the actual mechanisms. 4. Architecture The policy architecture is composed of the four functional entities, shown in Figure 2. Some of these components have previously appeared in IETF drafts in different shapes and forms, as a Policy Server [IPSEC] [DIAMETER] and as bandwidth brokers. It is important to separate out the functional components and describe the relationships between them. That is the purpose of this section and Figure 2. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 8] Internet Draft Policy Framework Architecture February 1999 Note: This is an architecture of policy functions and, as such, it does not describe any implementation details such as distribution, platform, or language. Policy prescriptions | V +--------------------+ | Policy | Functions: Policy Editor | Management Tool | Rule Translation +---------+----------+ Rule Validation | | <--- Repository Access Protocol | (e.g., LDAP) +---------+----------+ | Policy Repository | | (Directory Server, | Functions: Storage and Retrieval | Database, etc. ) | of Rules +---------+----------+ | | <--- Repository Access Protocol | (e.g., LDAP) +---------+----------+ | Policy Decision | Functions: Policy Trigger and | Point (PDP) | rule locator. +---------+----------+ Device Adapter | State and Resource Validation | | <--- Policy Protocol for policy mechanisms | +---------+----------+ | Policy Enforcement | Function: Execution of specified Actions | Point (PEP) | Device State and Resource +--------------------+ Validation Figure 2. Policy Architecture Functional Definition 4.1. Functional Components of the Policy Architecture The Policy Management Tool is composed of policy editing, rules translation and validation functions. The Policy Decision Point is composed of trigger detection and handling, rule location and applicability analysis, network and resource-specific rule validation and device adaptation functions. Policy Enforcement Points are responsible for execution of actions, and may perform device-specific condition checking and validation. Each of these functions are reviewed in the following sections. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 9] Internet Draft Policy Framework Architecture February 1999 4.1.1. Policy Editor The Policy Editor is a mechanism for entering, viewing and editing policy rules in the Policy Repository. Network and policy administrators would use Policy Management Tools. It could be implemented as a drag-and-drop GUI, be a simple Web-based form, and/or support a command line or scripting interface. Policy prescriptions and rules may be of several forms. Probabilistic prescriptions may be of the form: "with 99% probability, provide sub- second response-time for department D using application A." Other general specifications may be of the form: "I want 100Mb/s of premium traffic going from point A to point B" or "I want a video conference between the sales team managers". Alternately, more specific rules may be defined, such as "For NetworkDevice1 and 3, configure drop queues as follows ..." or "From source=10.56.43.x to destination=10.56.66.x, perform Premium Service". There is wide latitude in the level of abstraction and function of the policy editor UI. Once a policy rule has been entered into the Editor and before it is stored in the repository, simple validation should be performed. This is described in 4.1.3. The Policy Editor should provide feedback to the administrator of the validation results. At the simplest level, this could result in a "Valid/Invalid Policy" message. However, it is not beyond the scope of the interface to indicate the erroneous rule conditions or actions, or display the pre-existing policy rules that are in conflict. Further rule definition or update would then be the responsibility of the administrator. 4.1.2. Rule Translation Translation of general policy prescriptions or SLOs into specific, actionable policy rules is performed by the Rule Translator function. Mapping a policy prescription with its associated parameters to the specific policy rules and formats pertaining to that service is accomplished in this component. It is expected that QoS, DHCP, IPSec and other policy rules (schema and semantics) will be defined. Using QoS as a example, the Rule Translator would take general policy prescriptions related to the specification of "normal" or "premium" service, and translate these to the specific format defined for QoS policy. As another example, the following policy prescription could be defined, "Premium Traffic between Point A and Point B". This could be translated into the following policy rules: o source = 10.24.195.x, dest = 10.101.227.x, any protocol, perform Premium Service action o source = 10.101.227.x, dest =10.24.195.x, any protocol, perform Premium Service action Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 10] Internet Draft Policy Framework Architecture February 1999 where the Premium Service action is to mark packets with DS byte 2. (In this example, the network has been configured to treat packets with a DS byte 2 as premium service packets.) 4.1.3. Rule Validation The Rule Validation performs checking of a policy prescription and/or rule, and returns the results of this checking. Two kinds of conflicts should be detected: o Syntactic, semantic, or logical issues in the rule definition. For example, a rule may be defined stating that "Premium traffic at 50 Mb/s should run between 10.23.24.56 and 10.23.24.56". This is syntactically valid but semantically wrong since it specifies the same source and destination address. o Static conflicts with currently existing rules. For example, an administrator may define two rules stating that "A maximum of 10 video conference channels are allowed on NetworkA", and that "8 video conference lines are dedicated to Finance on Tuesdays from 9- 10am". If a third rule provisioning 3 video conference lines for Legal every day at 9-10am were to be added to the rule set, a conflict should be detected. The administrator is attempting to provision for 11 video channels (versus the maximum of 10 channels allowed). Not all policy conflicts can be detected by the Rule Validation function. Rules may be "time based" (specifying an effective validity period in the future) or based on dynamic state information. These rules may indeed conflict with others. But, these conflicts may only be detected at the time that the rule becomes valid and enforcement actions are attempted. As mentioned above, the validation performed in this component is off- line validation. On-line validation occurs within the State and Resource Validation component, discussed in 4.1.6. 4.1.4. Rule Storage and Retrieval Once a rule has been translated and verified, its storage in the repository is required. Utilization of policy rules to maintain or change system/device state requires retrieval of these rules from the repository. In addition, the repository is accessed during the rule validation process discussed above. It is assumed that standard LDAPv3 mechanisms are used to accomplish these tasks. This assumption is discussed further in Section 6, below. 4.1.5. Policy Trigger and Rule Location Triggers to evaluate one or more policy rules include events, polling, and system/component requests. The detection of an event, the receipt and processing of a request, or the monitoring of a polling interval Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 11] Internet Draft Policy Framework Architecture February 1999 are the functions of the Policy Trigger function. Using the data or parameters in the trigger, this function locates applicable rules in the policy repository. The State and Resource Validation function (Section 4.1.6) actually performs the policy condition evaluation. Event triggers could be time of day, repository update, receipt of an SNMP trap, notification of user logon, etc. Requests could be a query from a PEP* component for a policy decision. The Policy Trigger and Rule Locator: o Receive the query o Locate rules which match the parameters in the query o Invoke the State and Resource Validation to evaluate the "matched" rule conditions (e.g., authenticating with AAA Service and/or checking resource settings) o Send a decision back to the initiator of the query, perhaps in a device-specific format as specified by the Device Adapter (4.1.7). 4.1.6. State and Resource Validation Evaluation of policy conditions may involve multiple components (e.g.: the policy server and the device). When evaluation applies to a single device this function may be co-located with the PEP. The Validation components gather, (optionally) store, and monitor network state and resource information. Upon a request to evaluate a policy rule's condition set, the Validation function uses this information and returns a determination of True or False. Often, authentication and authorization checking are required of the Validation components. Examples include checking the current time of day against the authorized times that a user or application can access certain resources, or checking against the level of service that a user or application can request. State and resource validation is also concerned with the current availability of network resources. If requested resources are available, then the actions of a policy rule may be executed. Current resource availability is dynamic and depends on how resources are currently provisioned in the network and what resources are presently in use by, or reserved for, other traffic. The state of the network and its individual resources may be obtained by applying measurement, estimation, protocol-specific query, or other ------------------------ * The device may detect an event related to its operation and send that event to the Policy Interpreter. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 12] Internet Draft Policy Framework Architecture February 1999 techniques. In addition, standard management interfaces, like SNMP, will be utilized. Regardless of how the information is obtained, state and resource data can be (optionally) locally stored/cached by the Validation components for quick retrieval and processing. 4.1.7. Device Adapter and Execution of Policy Actions The Device Adapter function takes the canonical representation of policy rules (as stored in the Policy Repository) and maps them into device-specific mechanisms. The device adaptation allows different protocols (e.g., COPS, Telnet/CLI, SNMP, network manager proprietary interface) to be used to communicate with the network systems and devices. It is the responsibility of the Device Adapter component to determine which network devices are affected by a policy rule, and then to make decisions based on the actual network devices' capabilities. Decisions that need to be made include the: o Protocol for communication to the network element o Device-specific mechanism that must be employed to implement and execute the rule action. For example, a traffic filter and a policer instance could be installed on an edge device. The Device Adapter is informed of changes in the Repository/Data Store or in the managed environment by the Policy Trigger and Rule Locator functions. In attempting to apply policy actions, the Device Adapter may determine that a run-time conflict exists at one or more network elements. Although these conflicts occur, the handling and determination of run-time conflicts and other errors are beyond the scope of this document. They are implementation-specific issues. 4.2. Interfacing with Components Outside the Policy Architecture 4.2.1. Network Manager Existing network management applications can play an integral role in a comprehensive policy architecture. The Network Manager can be used to configure network elements based on the definition of policy rules. It can be used by the Policy Interpreter to install a device-specific mechanism on a network element to implement a rule. A network monitoring application provided by the Network Manager could be used for independent policy validation. The Network Manager would also be useful for accessing the network topology. For example, the PDP could use the Manager to determine which network devices are edge devices (for DiffServ QoS policy management), their types, and their capabilities. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 13] Internet Draft Policy Framework Architecture February 1999 4.2.2. AAA Service The AAA (Authorization, Authentication, and Accounting) Service could be used by several of the components within the policy system. For example, it could be used by the PDP to determine if a dynamic request for service is allowed. Or, it could be used by the Rule Validation to ensure that the administrator submitting a policy prescription has the necessary privileges. 5. Policy Conflicts A policy conflict occurs when two or more actions are expected to execute at the same time but are inconsistent with each other. For example, unless identified with appropriate precedence rules, a policy rule specifying that "all engineers get bronze service" is in conflict with another rule defining that "the lead engineer gets gold service". The actions may be linked to one or more policies. A conflict may be determined before execution of the policy is attempted. This function is represented in the policy architecture as the "Rule Validation" (section 4.1.3). For example, the conflict may be detected at the time the policy is entered into the Policy Repository or when the policy is loaded by the PDP. A conflict may also be determined when the policy decision is made at the PDP. An example of when this type of conflict can occur is when one policy server loads a policy into a device and a second policy server attempts to load a conflicting policy. Conflict detection is an important aspect of a policy architecture. However, various mechanisms and degrees of sophistication exist to support this functionality. A generic algorithm is not defined in this document. Regarding conflict resolution, again, various mechanisms and degrees of sophistication exist in implementations. The policy schema does specify a rule priority attribute to aid in conflict resolution [SCHEMA]. Beyond the support of conflict resolution that is specified in the schema, conflict resolution is a local implementation issue and is not a part of this architecture. Note that it is not a conflict when the resources required to execute an action are not available. This is an execution error. 6. Interoperability The architecture defined by this memo defines two types of entities that access the data repository: the administrative tools and the policy decision points. Both of these entities require interoperability with the data repository on at least two levels. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 14] Internet Draft Policy Framework Architecture February 1999 The first level of interoperability is on the data schema level. The entities require knowledge of the structure, syntax, and semantics of the data in order to be interoperable. Failure to fully comply with any of the data definitions will cause an entity to produce incorrect results. The second level of interoperability is on the data access level. Initially, the policy framework chooses LDAPv3 (or higher) as the protocol to access the repository. Assuming a compliant LDAPv3 implementation, data access should be interoperable. However, the current LDAP standards are not fully sufficient to ensure data repository interoperability. Two deficiencies have been identified that hinder interoperability. These are: o Change notification: the ability to notify data access entities when data changes and how the data changed; and, o Transactional integrity: the ability of the repository to ensure that a set of related operations are completed as a set. Interoperability problems will occur if implementations choose to use proprietary change notification mechanisms or implement notification in a non-consistent fashion. Lack of transactional integrity will result in interoperability problems since implementations may update objects in different orders. This could cause data repository corruption. This architecture is dependent on other IETF Working Groups'efforts to define and standardize missing LDAP features. 7. Future: Inter-Network and Inter-Domain Communication The inter-domain communication interface of a policy management system is concerned with communication with other policy systems in adjacent domains. This communication may be across enterprise-carrier or carrier-carrier boundaries. The primary purpose of inter-domain exchanges is to negotiate SLAs with adjacent networks to establish policy services within the adjacent network. Ideally, the adjacent network should have sufficient SLAs in place with its downstream neighbor to support the requested service end-to-end. Adjusting provisioning at domain boundaries entails re-negotiation of SLAs with adjacent domains. Linking provisioning with policy management in the future makes it possible to manage how provisioning is performed, an area of importance to managing policy in a carrier environment. The area of inter-domain communication for policy service requests is an ongoing research topic. Protocol requirements, message contents, Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 15] Internet Draft Policy Framework Architecture February 1999 etc. are still under study within several IETF working groups including DiffServ, Policy, and AAA working groups. 8. 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. 9. Acknowledgements TBD. 10. Security Considerations Security and denial of service considerations are not explicitly considered in this memo. However, the implementation of 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. 11. References [DIAMETER] Pan, P., Schulzrinne, H., Calhoun, P., "DIAMETER: Policy and Accounting Extension for SIP", Internet Draft, , November 1998. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 16] Internet Draft Policy Framework Architecture February 1999 [IPSEC] Sanchez, L.A., Condell, M.N., "Security Policy System", Internet Draft, , November 1998. [RAPFRAME] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy-based Admission Control", Internet Draft, < draft-ietf- rap-framework-01.txt>, May 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [SCHEMA] Strassner, J., Ellesson, E., "Policy Framework Core Information Model", Internet Draft, , February 1999. [TERMS] J. Strassner, E. Ellesson, "Terminology for describing network policy and services", Internet Draft, , August 1998. 12. Editors' Addresses Lee Rafalow IBM Corporation, JDGA/501 4205 S. Miami Blvd. Research Triangle Park, NC 27709 Phone: +1 919-254-4455 Email: rafalow@us.ibm.com Robert Moore IBM Corporation, BRQA/502 4205 S. Miami Blvd. Research Triangle Park, NC 27709 Phone: +1 919-254-4436 Email: remoore@us.ibm.com Glenn Waters Nortel Networks 310-875 Carling Avenue, Ottawa, Ontario K1S 5P1 Canada Phone: +1 613-798-4925 Email: gww@nortelnetworks.com Andrea Westerinen Microsoft Corporation One Microsoft Way Redmond, WA 98052 Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 17] Internet Draft Policy Framework Architecture February 1999 Phone: +1 425-705-2553 Email: andreawe@microsoft.com Jeff Wheeler Nortel Networks 14508 134th St. KPN Gig Harbor, WA 98329 Phone: +1 425-637-2953 Email: jwheeler@baynetworks.com 13. Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 18]