IETF-47 Policy Framework WG Minutes Day One, Policy Framework WG Minutes recorded by John Strassner The agenda was discussed. No changes were made. For your reference, the agenda was: 1st Session, 1300-1500 Mon, 27 March Agenda Bashing - Ed (5) Status Update - Ed/John (15) PCIM - WG Last Call Results - Bob (15) PCIM - Final Draft Review - Bob (25) file: draft-ietf-policy-core-info-model-04.txt PCS (Policy Core Schema) Review - Bob (10) file: draft-ietf-policy-core-schema-06.txt Polterm Requirements Doc - Fran (15) file: draft-reichmeyer-polterm-terminology-00.txt Policy Framework Status - Mark (15) file: draft-ietf-policy-framework-00.txt Policy Monitoring - Bob/Ken (15) (postponed to Wed.) no draft, just general thoughts; draft is pending Wrapup - Ed (5) 2nd Session, 1300-1500 Wed, 29 March Policy Monitoring - Bob/Ken (10) (resched) no draft, just thoughts QoS Policy Extensions - John to give an intro (5) QoS Policy Info Model (new draft) - John (22) file: draft-ietf-policy-qos-info-model-00.txt QoS Policy Schema (revision) - John (20) file: draft-ietf-policy-qos-schema-00.txt QoS PHB Specifications - John (5) file: draft-ietf-policy-qos-schema-00.txt QoS Device Info Model Update - Walter (22) file: draft-ietf-policy-qos-device-info-model-00.txt (will be available by 3/20/00, note name change) Requirements and Use Case - Hugh (23) file: draft-ietf-policy-req-02.txt Policy Scalability - Hugh (08) file: draft-owens-policy-scalability-00.txt Wrapup - Ed (5) (Note: due to a long discussion about whether and when a second working group last call should start, the Policy Monitoring draft was moved to the second session and the draft discussion in that session were compressed to accommodate the change) Status - John Strassner John gave a brief overview of the overall status. The bad news is that we’re behind our charter goals. The good news is that we’ve had a lot of activity this last round. Every draft listed above in the agenda is either a new draft or an update to an existing draft. The exceptions are the framework draft, which has been waiting for consensus to build in other affected working groups, and the core schema, which is waiting until the core information model gets out of working group last call. Q: Are we doing another call for the core information model? A: This ended up being a somewhat lengthy discussion. Here’s a summary. There are two outstanding issues in the core model. The first is representation of time, which Bob will talk about shortly. We have an answer, so this will be resolved. The second was clarification for roles, which we added. All other last call comments have been addressed in the document. Now, we want to strike a balance between doing the right thing (having another formal working group last call) and trying to get the document issues as soon as possible. The argument against having another working group last call is it will cause at least another week and a half delay (repository doesn’t open till April 7) and there really isn’t anything more to discuss. ;-) Argument for another working group last call is that is how the procedure should take place, and since this is for Proposed Standard, we shouldn’t take any short cuts. After further discussion, we decided to go the formal route and have a last call start as soon as the draft was placed in the repository. Q: And when is last call for core schema? A: The core schema will go to last call when the IETF Last call completes of the core information model. Q: Can’t we move this up a bit? A: Bert agreed. It was decided that we update and send into last call another revision of the core schema, approximately 2 weeks (sooner if possible) after the core information model completes its second last call. This would make it available roughly in mid-May. Core Info Model - Bob Moore File: draft-ietf-policy-core-info-model-04.txt Several editorial comments were raised, and addressed in the 04 version of this draft. One issue was raised, and resolution will be discussed below. This is the time issue, and will cause the version of the Policy Core Information Model (PCIM) to be revised to 05, and will be the main focus of attention for the second WG last call. The main issues talked about during the change from 03 to 04 in the first working group last call were: - declarative vs. procedural model (wording clarified) - discussion of roles (wording clarified) - new PolicyRoles property added to policyRule - UCS-2 encoding for CIM strings explained more fully - Changed encodings of PolicyTimePeriodCondition mask properties from strings to octet strings - Clarified encoding of OIDs for ConstraintEncoding and ActionEncoding properties - Expanded the names for several of the association classes and their reference properties - Updated Security Section - Updated Acknowledgments and References sections, along with minor editorial fixes We then had a discussion about roles in the meeting. There was concern voiced that the roles definition was still not as clear as it could be. For example, what happens, specifically, when it is desired to retrieve all policies that are defined for the role-combination BGP+RIP? It is assumed that this will cause all policies for BGP, all policies for RIP, and all policies that deal with both BGP and RIP to be downloaded to the PDP. However, this is not explicitly spelled out. There was a request for additional clarification to state explicitly that all of these policies get downloaded to the PDP. It is then up to the PDP to either filter only the BGP+RIP policies and send those policies to the PEP, or to ship additional policies to the PDP and have the PDP decide what to act on. This text will be added as part of the 05 draft. This action item is assigned to John. Time issue. The basic issue was that the semantics and syntax for the time-range properties in the policyTimePeriodCondition class should match those specified in RFC 2445 (iCalendar document). This RFC already has a convention for representing time intervals, and the suggestion was that we use that convention instead of our own. Proposed resolution: - when both ends of the time period are specified, use the convention in RFC 2445 - when there is an open ended time period (from some time before till or from now till forever), RFC 2445 doesn’t have this capability. So we’ll solve this by glueing together the specification of each end according to RFC 2445. - For timeOfDayMask property, change the representation to conform to RFC2445 by starting the time with a T and replacing our delimiter (a colon) with the RFC 2445 delimiter (a slash). As an example, we could have: Thhmmss/Thhmmss. So far, so good. However, once we started talking to the iCalendar people, we realized that there was yet another problem with the representation of time zones. This affects the ApplicableTimeZone property . We use a static offset from UTC time, as does almost everyone else. But this is wrong, because for example, countries that have daylight time change their offsets twice a year. We observe that we are just as good (or bad) as SNMP, LDAP, and many other protocols in this area, and therefore we should change when the other protocols change. Bert and Patrik Falstrom are investigating and will get back to us. The action item for updating the first two items with respect to time definition is assigned to Bob. Next steps. We need another two-week last call. After some discussion, we decided that we will wait to have a working group last call start Monday 10 April, since that is the first date that people may be able to get the document from the repository. John or Ed will ensure that the document is updated and posted to the repository as soon as it opens up (7 April). Core LDAP Schema - Bob Moore File: draft-ietf-policy-core-schema-06.txt We need to incorporate recent work done in the DMTF plus work that Ryan Moats has done in mapping information models to the LDAP schema. Then, we will be ready to issue another revision of this document. Q: what about definitions such as port and protocol? These objects have added semantics that should be captured in the Core information model and schema, instead of remaining in the QoS models. A: There are some problems associated with this, such as coordinating this work with other working groups that want to use these. Q: But there are a number of IETF-specific constants (for example, protocol and port) that are IP-specific. A: But moving this to the Core information model and schema means that other working groups, such as IPSP, must use it. Furthermore, it means that working groups that don’t need a concept of port or protocol would be saddled with it. A: IPSP wanted to differentiate between distribution and configuration of policies. So the current IPSP draft isn’t really tied into the Policy model; rather, it is trying to model lower- level information that can be controlled by higher-level policy (similar to the division in the QoS models in Policy). Bert thinks that if it is indeed general, then we should consider moving this information into the Core Info Model and Schema. This then raised a discussion as to (1) its feasibility and (2) its practicality. Feasibility is the actual mechanics of moving the information; practicality is when, and how that will affect the schedule. One additional possibility is to have a third document - information model proposed common concepts (and of course, a companion LDAP mapping document). This is the subject for further discussion on the list. The chairs recommend that we wait until the Policy QoS and Device QoS models are re- published, along with the IPSP model, to see if these are indeed general concepts. Action Item: Bob Moore to coordinate the updating of the Policy Core Schema draft. This should wait until the working group last call of the PCIM has finished, just to make sure that nothing changes. The goal will be to issue a new revision as close to two weeks from a successful working group last call close of the PCIM. Policy Terminology - Francis Reichmeyer File: draft-reichmeyer-polterm-terminology-00.txt Approach. Several working groups are working on policy networking terminology. The list includes (at least) RAP, Policy, DiffServ, and IPSP. Others are being added (e.g., MPLS). The result is a lot of policy terms and definitions, with some conflicts occurring. The focus of this document is to resolve those conflicts and to put these terms in one place. Goal: identify relevant common terms that all working groups can use. Non-goal: common policy architecture Q: Does this draft introduce new terms? A: No Approaches to Policy. This section talks about Policy, management and administration of policy, the notion of policy domains, and meta-policy. These latter two were new to some people. A policy domain is a collection of objects that have been explicitly grouped together so that they can share the same policies. There is an implied common administration that happens. Domains can be nested, in order to reflect hierarchical semantics. A meta-policy is a policy that defines how policies are constructed. Another way of thinking about this is that it defines how to build other policies. Policy Management Models. Three are defined: outsourcing, provisioning, and interactive (though there is a question as to whether this one is needed or not). An outsourced policy model directs certain components of the policy framework to rely upon other components of that same framework in order to perform policy-related decisions. A provisioned policy model implements policy by first configuring devices that will execute policy decisions prior to the events that will prompt those decisions. No real-time interaction is done here - this model consists of configuring a device so that it will do the right thing sometime later. An interactive policy model implements policy by installing policy expressions within appropriate components of the policy framework. This means that policies are complete, self-contained expressions, and that there are a set of rules that define the interaction between a process that requires policy decisions to be made and the constituent components of the policy framework that enforce those decisions through executing a set of actions. Q: Are these three terms reflective of work being done in an architecture, or is it something that was invented as part of this work? If it was invented, then we should not use it. (In other words, the purpose of this draft is to document terms, not invent new ones). A: Good feedback, the authors will discuss this again. A: The purpose of this document is to be a "living" document that grows as the working groups that are using it gain more experience and form tighter definitions of policy. Q: Outsourcing and provisioning reflect a COPS legacy, where interactive reflects a policy legacy. Policy is all about a condition-action pair, and controlling the interaction between a PDP and a PEP. A: Provisioning is pure configuration. Outsourcing is asking for help. Interactive is describing capabilities. The chairs appealed for volunteers to write up and comment on text. Shai to argue against interactive, and Walter to argue for interactive. Everyone else is free to join in the discussion. ;-) Abstraction and Scoping. Four key concepts are defined in this section: Administrator-defined, device-independent, device- dependent, and roles. Roles are used to help define scoping. Q: what about network-wide policies? A: not explicitly identified as such, but this term should be added to the next revision of the document. Q: Also, don’t like "administrator-defined". This should instead be bound to a specific scope, such as administrator for a network, etc. A: Authors to discuss and either incorporate or add additional clarifying text. Q: Are there multiple definitions of roles? In other words, is this definition synchronized with the definition in the PCIM? A: The intent is most assuredly to NOT have multiple definitions. Unfortunately, the definitions are not currently synchronized with the PCIM, but they will be in the next revision. Q: Concern that by defining the functions of a policy system, there is a strong chance of these terms conflicting with other documents. A: Good point. So if this document is a "passive" document (i.e., no new terms are defined), then if there needs to be a new term, the authors of this document should contact the appropriate architecture or framework document and get them updated. This last question led to a general discussion of which working group should own this document. It was offered that Policy owns this, and RAP agreed. Need to check with IPSP and DiffServ. (Editor’s note: subsequently, IPSP and DiffServ responded, saying it was OK. Thus, this document needs to be added to the Policy Framework working group charter. Action item: John/Ed to do this). Framework document - Mark Stevens File: draft-ietf-policy-framework-00.txt Document hasn’t received much attention, due to other pressing matters that this draft depends on. The authors are going to be revising this and hope to get a new revision out in April (May at the latest). Feedback is encouraged. Wrapup of First Day (Ed). 1. New version of PCIM (-05) will be completed by the end of this week (pending discussion of moving constants from QoS model to PCIM 2. Time period changes will also be incorporated by next week. 3. John to update roles section by next week. 4. Bert to check with Marcus on time zone handling. 5. Monitoring to be moved onto Wednesday session. 6. Which working group should own policy terminology? Tentatively Policy, but need to check with IPSP and DiffServ, and also need to ensure that it is a working document that incorporates needs of the other working group 7. Shai and Walter to suggest text describing use of interactive. Policy, Day Two Policy Monitoring - Bob Moore (No draft yet) Why monitoring (i.e., what are the requirements that we are trying to address)? Administrators need to know which policies (active and inactive) are present at a PDP, and whether these policies are meeting their objectives and being properly enforced. There needs to be a "core" policy MIB to tie all of the individual policy-related MIBs together. It is proposed that a new draft be written that addresses these issues. Note that the scope is monitoring only -- we have other mechanisms for configuring policies. The next question is what to monitor. There are two broad categories of items that need monitoring - the policy framework itself, and whether polices are acting correctly and being enforced or not. This is more complicated that it initially appears to be. There can be several protocols (e.g., a policy repository protocol, like LDAP, as well as policy protocols themselves (e.g., COPS and SNMP). In addition, there are issues with respect to instrumenting different domains (e.g., QoS and IPSec will have different needs). There are a set of nine possible instrumentation points envisioned. These divide into the ingress, inside and egress of the Policy repository and PDP (6), the ingress and inside of the PEP (2), and the policy-managed resource itself (1). All except this latter one use the policy framework. More specifically, they are: 1 - PM tool to repository 2 - inside the repository 3 - repository to PDP 4 - PDP to repository 5 - Instrumented inside the PDP 6 - PDP looking at PEP 7 - implemented at a policy-aware PEP, policy flows from the PEP to the PDP 8 - the MIB that instruments the function that is policy-controlled 9 - the PEP itself There are a set of MIBs that exist. The question is, how do we proceed to harmonize/rationalize these MIBS and relate them to the Policy Framework working group? This draft will help define this relationship. Policy QoS Information Model - John Strassner File: draft-ietf-policy-qos-info-model-00.txt This draft was built by abstracting the concepts in the QoS Policy schema. It is acknowledged that not all of the "LDAPisms" have been successfully purged from this document, and that it should be further generalized. This will happen in the next revision. The purpose of this draft is to extend the generic concepts of policies to a form that is more suitable for representing policies that control DiffServ and IntServ. It fits as the middle layer of policies, refining on generic concepts (for interoperability) and using specific mechanisms as defined in the QoS Device Information Model (to be discussed later). For example, it defines the concept of a policer. This is not a generic extension (e.g., DHCP doesn’t require one); it is a concept that is needed by DiffServ and IntServ. Status This draft is actually the third major revision - it is a 00 draft because it has just moved from the individual namespace to the working group namespace. The following changes were made during this revision: - Added a lot of detail to QoS actions (both DiffServ and IntServ) - Added functionality, yet simplified, repository usage - Added granularity to representing constants and variables - Added changes to match the latest version of the PCIM - Added examples - Minor editorial changes as suggested per working group comments There were also some extensions to the PCIM. The most important of these were to extend the decision process to allow rule nesting and rule-group interaction, and to support the concept of nested rules and sub-rules. Objectives of this draft. The specific goals of this draft is to extend the generic notion of policy, as expressed in the PCIM, to better represent the needs of DiffServ and IntServ. This takes several forms: - to refine the concepts of repositories, conditions and actions for expressing QoS policy rules - to ensure that a simple way is available to build hierarchical namespaces for administration and scoping of policy rules - to build a framework of classes that help ensure that devices of different capabilities interpret QoS mechanisms the same way - to provide for rule-specific as well as reusable policy rules, conditions and actions; and to be able to define at a high-, a device-independent, or a device-dependent level, DiffServ and IntServ policies. This draft can’t do the last two bullets by itself. But it can be one of the tools that, combined with other work, can accomplish these together. Policy Layers. As stated previously, this draft is one of several that work together to define a continuum of policies. A chart was displayed that provided three different abstractions. The highest was administrator-defined. This level is device-, technology- (e.g., DiffServ) and mechanism- (e.g., WFQ) independent. An example is: IF User is subscribed to Gold Service, THEN allow use of NetMeeting and provide premium data services The next lower layer is characterized by device- and mechanism-independent, but technology-specific, policy rules. These policies translate the higher-level administratively- defined policy rules to a form that can be more easily translated to a device. An example is: IF sourceIPAddress == 172.3.128.0/15, THEN mark voice with EF and mark data with AF The third layer is characterized by a device-independent, technology- and mechanism-dependent policy. This type of policy is used to do the following three types of configuration: - configure a component so it can be used to condition forwarded traffic - configure a component so that it can act on received traffic directly - trigger an action based on a network or a system event (e.g., link failure) These configuration actions take the form of performing a set of device-independent actions (e.g., configure a classifier, then configure a filter and bind it to the classifier, etc.). This draft serves as the integration point for binding high-level QoS policies to low-level QoS policies. The concept of reusable repositories was discussed. This is an extension of the repository concept that is present in the PCIM. Repositories in the QoS Policy model serve the following three purposes: - containers for reusable objects - maintenance mechanism for ensuring the integrity and proper updating of reusable objects - provide a hierarchical namespace and context for reusable objects The repository implementation has been simplified. The policyRepository class of the PCIM is used, and additional semantics are provided by subclassing the policyGroup class. Basically, the policyRepository class is used to define the root of the policy repository. The qosPolicyDomain class is used to define the roots of various administrative domains that reside in the policy repository. Within each qosPolicyDomain, one or more qosNamedPolicyContainers can be used to define policies that are specific to a particular group of objects. Several examples were given. One illustrated the above process, showing how policy rules could be grouped first by container, then by domain. Another illustrated the more granular decision-making process that the QoS Policy Schema supports. Several examples were also provided of showing how QoS policy rules could be constructed. QoS action extensions were then covered. DiffServ actions include classification, and then the ability to mark, police, and/or shape to a specified traffic profile. IntServ actions included controlling RSVP, as well as signaling and install actions. Note that it is expected that the QoS Device Information Model will supply the specific parameters that are controlled and manipulated by these actions. A good analogy is that the QoS Device Information Model represents the DiffServ and IntServ mechanisms of the device, while the QoS Policy Information Model shows how to configure and manage these mechanisms. There is one main open issue, which is whether to move the variables and constants that are defined in this draft up to the core information model or not. This will be taken to the list. John will revise this draft within 2-3 weeks. QoS Policy Schema - John Strassner File: draft-ietf-policy-qos-schema-00.txt This draft appears as a 00 draft because it has just moved from the individual namespace to the working group namespace. It has had 3 major iterations previously. It is acknowledged that another revision needs to be made. First, in separating out concepts that were generic that were used to build the QoS Policy Information Model, not all of the generic concepts have been extracted. Second, it needs to be revised to include a formal ABNF, and to synchronize again against the core information model (simple) and schema (a little bit more work). Status This draft has received a lot of previous attention. It was the original source for the concept of policy repositories, and contributed this and other concepts to the PCIM and Core Schema documents. This revision has had the following changes: - generalization and simplification of the containment model - generalization and simplification of the implementation of reusable object repositories - qosPolicyRule class removed, now using policyRule - QoS domains and policyGroups can be arbitrarily nested - Action classes for DiffServ and IntServ created - PHB modeling added as separate drafts - Variable binding definition and pre-defined constants revised and made more granular Discussion. Containment is now based on association classes. This hides the difference between attachment and reference. The reusable objects were generalized so that they could reside in any repository. The model was inverted, so that now multiple domains can reside in a repository, with multiple containers in each domain. This is a more flexible and efficient mapping. The qosPolicyRule class was removed. Instead, the policyRule class defined in the core model was used, and semantics were moved into the condition and action subclasses defined in this draft. An example was provided that illustrates how a QoS Domain could be instantiated. It stressed the use of DIT containment, and the ability to treat policyRule and qosNamedPolicyContainer objects as siblings. The policyRule priority attribute, along with the qosPolicyRuleMatchMethod attribute, were used to fine-tune the decision-making process that is represented in the QoS domain. A similar example was provided that illustrates the difference between using attachment and reference to form a QoS policy rule. The open action items are to incorporate some additional minor editorial comments, to finish the ABNF, and to decide on where variables and constants belong. John will revise this draft within 2-3 weeks. PHB Sets and Mapping - John Strassner Files: draft-ronc-domain-phb-set-specification-00.txt and draft-ronc-domain-phb-set-ldap-rep-00.txt We don’t really have time to go into any real detail on these, please read the drafts and comment. The purpose is to extend the core and QoS policy information models and associated schemata by representing a set of PHBs enforced on a QoS domain. This manages the scheduling and resource allocation that is shared between the set of PHBs that are enforced together on a QoS domain. Device QoS Information Model - Walter Weiss File: draft-ietf-policy-qos-device-info-model-00.txt This is a 00 draft, but represents a major restructuring and refinement of the previous draft. It focuses on creating data structures for configuring and managing QoS mechanisms that are "in" a device. The first slide talks about the same three levels of policy. Again, there is a continuum of policies that start by being defined administratively, then get translated to a device- and mechanism-independent form, and then get translated again into a device-independent but mechanism-dependent form. Mechanism-independent policies talk about ports and DSCP values. Mechanism-dependent policies talk about classifiers, markers, and other elements that affect the forwarding of traffic in the data path of a router. There is an important implication here. One of the problems of the mechanism-independent approach is that it can’t guarantee interoperability between different devices. That is, consider a single policy server. If it controls two different devices that each have different implementations of the same QoS mechanism (e.g., a dropper or queue), then these devices will interpret the policy differently UNLESS there is a common device information model. Similarly, mechanism-independent policies do not guarantee interoperability between policy servers. If you have multiple policy servers from different vendors, then you have a different set of problems: each policy server defines its own mapping to control devices, but you have no assurance that the policy servers are doing the same thing. How do we support the different types of mechanisms? Our approach is to use a class hierarchy. This provides a set of abstractions that each can model one or more concepts in detail. This makes the model inherently simpler, more accurate, and more extensible than building a single monolithic model that describes everything. The higher portion of the hierarchy talks about common information, and as you move down the hierarchy, you refine these higher concepts to model mechanism-specific or even device-specific policies. An example from the model that describes droppers was given, where a superclass represents information that is both device-independent and generic. Its immediate subclasses refine this to contain more specific information (RED vs. tail- drop characteristics). Note that this level is still device- independent. A further level can be defined, which subclasses the RED and tail-dropper classes to bind a specific vendor implementation to them. Class Associations are used to specify relationships between QoS mechanisms and services. These take several forms. One example is the construction of a generic QoS service from specific technologies, such as DiffServ or 802.1Q. Note that these technologies are modeled as sub-services that work together to implement a service. Another example is the definition of a TCB (traffic conditioning block) service. This service is made up of various sub-services, such as marking, classifying, metering, etc. A third example, nextTCBElement, is used to control the sequencing of various TCB sub-services. Note that associations are implementation-independent. They can be mapped to a row pointer if using a MIB, or a DN if using a directory. Another idea in the draft is to specify at run-time (or when the policy needs to be processed or interpreted) the characteristics of the device that are applicable, so that the best possible mapping can be done. Sometimes, you run into capacity problems (e.g., device can only support 50 filters) or specific technologies (does this device support DSCP marking?) or specific implementation (does this filter support bit masks and ranges?). These are called capabilities. Capabilities enable us to bind policy to device-specific characteristics. Examples were given that show how capabilities and constraints can be used to achieve a closer model of how the device is operating in the real world. QoS Model. The QoS Model has two parts - description of QoS services, and description of mechanisms in the device. QoSService is an instance of (for example) Gold Service, and its associations enable specific sub-services (e.g., classifiers and markers) to be used to provide this service. Three examples of different types of services were provided. A DiffServService binds DSCPs to TCBs in order to construct the DiffServ service. An 802.1P service binds priority values to TCBs in order to construct the service. Finally, Gold Service can be conceptualized as an instance of QoSService that could use services like the ones above to specify a customized QoS definition. This definition consists in reality of multiple services that are coordinated together (e.g., EF for voice, and AF for data). Q: Don’t see policies that govern admission control A: This is governed by the TCB components. Q: No, I mean explicit admission control (controlling interaction of devices to limit the number of conversations that can take place A: Nothing in the model precludes modeling this, but we need more work in this area Q: What about modeling voice? A: We support this, it’s actually similar to the Gold Service example. You’d create an instance of QoSService Q: how do we use this to configure devices, and how does it relate to the core model? A: the QoS Device info model defines attributes that you can use to configure mechanisms (e.g., RED droppers). The QoS Info model provides the structure that encapsulates this information. It’s up to you if you want to use policies to control this information or some other means. But the information is defined in both cases by the Device QoS Info Model. Note: this is not a completed model. So, it’s not that we can’t or don’t want to model certain policies, we just haven’t gotten there yet. Hugh - Policy Requirements Document (now 3 drafts) www.users.uswest.net/~hmahon/ is the common prefix. draft-ietf-policy-req-02.txt draft-mahon-policy-mgmt-00.txt draft-ietf-policy-use-00.txt Changes in Requirements draft. This was split into 3 drafts in response to feedback from the community. The first draft (draft-ietf-policy-req-02.txt) is just the requirements. Draft- mahon-policy-mgmt-00.txt and draft-mahon-policy-use-00.txt talk about how policies are managed and use cases, respectively. Also, tried to remove implementation information and in general tried to cut down the draft size. Content Changes. Discuss situation in which policy would actually be used (e.g., why are people interested in policy management). Three examples are VoIP, protect certain classes of traffic from other classes of traffic, and to guarantee transfer time. Usage cases. New usage cases are a variation of Olympic service in an ISP environment (customers connecting to an ISP, where the ISP is repsonsible for delivering different classes of service based on who the customer is). Second example is Olympic service in an intranet. This is similar to the first usage case, and both concentrate on how traffic is to be marked and how traffic is deployed. Major issues. Policy information is not the same as a description of service. Need for rapid notification of changes to policy. Despite the fact that policy is relatively static, it is a must that policy information be delivered quickly (e.g., security, fix a broken link, etc.). The point is that ven though policy doesn’t change very much, when it does change, it usually needs to be deployed quickly. Methods for identifying traffic other than port numbers and IP addresses is mandatory. Better, more complete information about the managed environment needs to be available in a standardized way. Security section of the document is changed to include authorization, as opposed to just authentication, as mandatory requirements. Next Steps Can continue to add more information, but is there a specific direction that people would like the drafts to go? One suggestion is to describe what need to be done by the administrator to manage QoS in the environment, and then describe the requirements to support those activities. Hugh thinks that the requirements and usage cases can help guide the next revision of the Policy Framework document in helping to continue to make the framework more robust and complete. Yoram adds that one specific requirement that has not been addressed in the framework are general signaling requirements. Policy Management Scalability - Hugh Mahon File: draft-owens-policy-scalability-00.txt Topics in this draft are why we’re concerned about scalability, what types of things we need to think about when build a policy management system, and what are the implications in managing the policy management database. Objectives Need to manage large numbers of nodes at which policy is deployed. But the problem is that nodes exist at numerous locations, across multiple domains (e.g., administrative domains within a company, etc. as well as different types of policies, and who can govern/use which policy). In addition, there is lots of information that needs to be combined to form a policy, as well as different types of information. Organization Need to conside type as well as locality of policies. Using a hierarchy of policies can significantly simplify the management domain. Considerations Topology can be used to restrict the number of resources, entities and/or people that need specific entries in the policy database by using hierarchies of policies and repositories to distribute the information Allocation Need to understand the frequency of access of the repository and its availability, and then design Conclusion Need to create a partitioning of data... Q: You mentioned partitioning, rules, secondary servers, and other similar things. This sounds like fundamental concerns for modeling as well as schema design. Seems like this should be folded back into the requirements draft (at least). Where do you see the work going? A: Good question. Problem is that there is a lot of things to consider. The question is how much of the discussion as to why these are requirements should go back into the requirements draft vs. staying outside. Comment: Seems like this crosses the info model draft as well as the framework Wrapup (Ed) Two things need to be added. One, the operational aspects of the device info model and the QoS info model need to be documented - this seems to belong in the framework doc. The other is how this info model interacts with CIM (for example).