Meeting Minutes for the Policy Framework Working Group, 46th IETF Minutes recorded by John Strassner SUMMARY: Work is proceeding on the core and QoS information model and LDAP schema mapping documents. The core information model is almost ready for last call, but consensus is that before a formal last call is done, more progress needs to be made on the use case/requirements and framework documents. The QoS model is filling out, being comprised of extensions to the core policy model coupled with a modeling of the QoS capabilities of devices. Two new drafts were introduced. A document combining use cases and requirements was issued. The framework document was rewritten. Progress has been delayed both because of the overall complexity of the problem as well as the need to work more closely with other groups. This is a critical part of the process, and the drafts in QoS, framework and requirements reflect an increased amount of working with other groups. DETAILED MEETING MINUTES Policy, Day One (Monday, 8 November) Status of where we are at as a working group - Ed Ellesson/John Strassner We are not only building a general policy model, but also concerned with building out a detailed QoS model. As an example of the former, we are working with members of IPSP and DHC. The latter is exemplified in the two QoS models, one subclassing the policy model and one subclassing the network model (representing the capabilities of devices). The following summarizes our progress against the dates in our charter: Mar 99 WG Last Call for FYI RFC typo left from last charter revision, should be removed Aug 99 WG last call on Policy terminology draft (Informational Track) being replaced by terminology in new Framework draft, plus revisions to terminology in other applicable working group documents. We've made some good progress, particularly with Security, in coming up with common terminology. We will continue working actively with other affected working groups (notably, DiffServ, RAP, and IPSP). Aug 99 Submit Internet Draft on Use case definition (Informational Track) This was combined with a Requirements draft, updated, and revised Oct 22. The second submission expanded the scope to work with other working groups. This second revision is on schedule to be updated in late December, with a last call anticipated in late Jan 00. Sep 99 WG last call on Core information model draft (Standards Track) Put on hold until we've revised the requirements and framework drafts (see below) Oct 99 WG Last Call on Use case definition (Informational Track) Estimated at Jan 00, updated version due December Dec 99 WG Last Call on Framework draft (Informational Track) A completely new version of the framework draft was resubmitted in September. The framework draft is really somewhat dependent on the terminology and requirements drafts. However, it is proceeding by working directly with other working groups. New revision by January at the latest. Estimated last call in Feb 00. Mar 00 WG Last Call on QoS Schema draft(s) (Standards Track) Policy QoS schema draft (Snir, et. al.) revised, Device QoS draft (Weiss, et. al.) in process. Note that there are two drafts here. The first refines the core policy information model to explicitly represent policies for provisioned and signaled QoS. The latter isn't part of the core policy information model at all. Rather, it refines the network model, and represents the QoS capabilities of a device. These two drafts then fit together to describe a QoS policy (more later). They both appear to be on schedule The Core Model is in very good shape, but should in our opinion be held up until we have settled on a common definition of terminology, requirements and framework. The schema draft has been tracking the core model. It is proceeding a bit more slowly, since it is tied to a specific implementation (e.g., using a directory), whereas the core model is a specification without regard to specific implementation. Policy Requirements Update and Discussion Hugh Mahon The draft starts out with an explanation of why policy is needed. The basic motivation is to provide an abstracted, or simplified, management interface that can be centralized to ease the administrative burden. Another driving factor is that of automation. Network devices, as well as networks, are becoming increasingly complicated in order to handle the increased demands of them. So any automation of common management and configuration tasks is much needed. This can take the form of fewer (e.g., more abstract) interfaces, or it can take the form of representing common functions in common policies, or any number of additional forms. The conclusion is that representing information in policies is key to achieving these goals. New terms, such as policy consumer and policy target, were introduced to reconcile the different uses of common terms across different working groups. Please go to the policy terminology BOF for discussion and hopefully resolution of a common definition of these terms. Policy Conflicts. Conflicts can occur between rules within a policy, as well as actions within a rule. This is discussed in detail in the draft; please continue to discuss this on the mailing list. In the first version of the draft, there was a discussion of policy conflict between multiple locations in the network. This was pulled out in the latest version of the draft, but feedback has been received indicating that it should be put back in. Please comment on the list if you think it should or not. Usage Cases. Several different ones are provided. Please read these carefully and comment on the list. Security issues: authentication is a MUST for all policies, and encryption of policy information is a MUST for at least for Security Policies. In addition, there is concern about protecting the flow of policy information between different components that make up the policy system. Requirements: - Policy information is the key to policy management - Some definitions exist (e.g., data model and schema) exist, but more need to be defined Need to better define conflict detection and resolution features. Issues raised on the mailing list: One-to-one relationship between policy and target. The basic issue is that if you have more than one relationship between two entities, and multiple administrators, then all of the information must be visible to each administrator. Relationship between policy target and policy consumer. The draft says that there is one policy consumer for any particular policy target. If there is more than one policy consumer, then there must be some coordination between the policy consumers. Q (Avri): doesn't this disallow notions like redundancy and load-sharing? A (Hugh): You certainly can, and should, support notions like fail-over. However, the intent is that only one manager is in force at any one time. Q (Avri): But these consumers may be talking over different interfaces. In order to say that we have a distributed management interface this seems to be a risk. A (Hugh): We could document this do you have a counter-proposal? A: (Yoram): the focus of the draft is to present a simplified set of requirements to gain implementation experience. Not sure that this is appropriate right now. Q (Fran): Does target mean a single physical device? A (Hugh): A target is a type of function that can be managed. The granularity is whatever is appropriate to be managed a router interface or an entire device could both be targets. Q (Joel): Some of the other WGs have had similar problems w.r.t. redundancy. But if we don't describe this, then we are likely to encounter interoperability problems with multiple clients. Don't think we should solve the problem now, but we should reserve these as topics of future discussion. A (Hugh): OK Q (Joel): Can we handle fail-over in the same way as load-balancing? A (Yoram): We shouldn't restrict this from the protocol. Q (Nitsan with John): Concerned over the satisfiability and feasibility of a policy, and ensuring that these two terms are differentiated. A (Hugh): Will try to incorporate this. Note that there is also a 1 to N relationship between a policy consumer and multiple policy targets. Another issue is the ability to provide guarantees with or without signaling. Q (David B): This is true only if every device in the path understands the signaling protocol that is being used. A (Yoram): but the only devices that need to signal are those that are experiencing congestion or are potential congestion points need to signal. Q (David B): agreed, but is worried about what happens if you try and generalize this. Not sure that we can define a general service-oriented model. What's missing in this version of the draft? Better statement of requirements at the end of the document. What else do we need to add to improve the document? Please provide input. Q (John Sch): there are an awful lot of framework concepts, such as how to deploy policy. Are these appropriate for this draft, or should they be split into a separate draft? Q (Bob): needs some discussion on how to think of policies. For example, is it sufficient to think of policies as entities that are downloaded and then acted on intact, or do they have to be programmable (w.r.t. RAP and Active Networks) Q (Russ): Security section is much improved, but still needs work. Must define what is needed w.r.t. integrity. Especially true if this is going to be used in a multi-management environment each input must be authenticated, and the integrity of its transmission must be established. Also must talk about securing the communication between different components of the overall system. Q (Russ) Put another way, unless there is a way to give the input and output points reasonable assurance that the policy submitted to the system was delivered and deployed without alteration, and that the network is actually using the policy, then we've failed. Chair's note: with respect to protocols, it would be a Good Thing if we specified different requirements on the protocols that are used w.r.t. their security capabilities and implications. Q (Russ): We need to make a decision as a working group on the need for mechanism(s) to control the application of policy from the input to the PEP. The problem is that different components of the system may be protected, but Russ is concerned that the overall integrity of the system is protected. Note also that we need appropriate reporting mechanisms to provide feedback for monitoring purposes. Policy Framework Draft Update and Discussion Mark Stevens In August, the principal authors of the existing draft decided to divide it into two drafts: a combination overview and framework (this draft), and a requirements draft (Hugh's draft). This division enabled the new drafts to defined new terms for use across different working groups, as well as to reconcile existing definitions (e.g., what, exactly, is a PDP). Slide 5. Testing two variables in a policy condition, a and b. The test is if (a > 5) and (b = 8). Note that a is more easily discerned external to the element, whereas b is more easily discerned internal to the element. The point is that there isn't an external decision point, but there is still a need to evaluate this policy. Thus, we have different types of decision-makers the PDP, which depends on receiving external data in order to make a decision, and another (called "translating") decision-maker, which really accepts different input and makes its own decisions. The problem is that the latter doesn't include a PDP per se, and has confused people. Therefore, we came up with a new term policy consumer to describe both cases. This will be discussed on Friday in the POLTERM BOF. Q (Shai): This seems to be too complex. Doesn't want new terminology, doesn't think that these differences need to be explicitly documented into a set of new terms. A (John): The definition of a PDP is just way too broad. Saying that a the difference between a PDP and a PEP is that the former makes a decision and the latter executes a decision doesn't make sense. Anything that executes something is making a decision by definition. Q: so the problem is that the name "policy decision point" was changed to "policy consumer" over concern of the name decision? Any enforcement point will always make a decision. Q: and note that any target will always consume… A (Chairs): This is a good discussion, but it should be deferred to POLTERM. The name does have important semantics that we can't afford to ignore, and we must get right. Q (Shai): Forget about names for now. At the bottom of the food chain is an entity that sees packets, and can affect their handling and treatment. Now, the question is, what is above that? It seems that there should be an entity operating at a higher-level, which can give the lowest-level box some help. There is also a policy repository. We also have a GUI component. So maybe what the proper distinction is, is that we don't say "I see a policy decision", but rather "I see a packet". Q (John): not all policies are packet-based. Q: Note that target is a potentially bad word to use, since it has the connotation of an end-user, and we're talking about network elements. Q: We also need to identify the translation of policy data, since it may be stored in a form different than that required by the target. Q: Problem is that it is focused on the distribution, not the functional, aspects of the policy system. Thus, it doesn't describe what information should be supplied to the target, what translation needs to be there, and most importantly, doesn't focus on the fact that a target is a resource manager. Q (Audrey): One of the things that bothered her was the notion of policy distribution, and the fact that sometimes we talked about an active repository that notified its PEPs/targets of new data, and other times we talked about a passive repository that didn't do this. Which is it? Architectural picture from the Framework draft. Andrea points out that there was a loss of architectural elements that was identified in both of the competing drafts as a result of the merging in Minneapolis. This will be fixed in the next revision. Policy, Day Two (Tuesday, November 9) Core Information Model Update and Discussion Bob Moore Slide 2, focusing on policyRule, policyCondition, policyAction, and policyRepository One change made is the addition of the PolicyRuleInSystem association. This is defined to be a weak relationship. This means that it is scoped by the System that it is contained in. We've also added the ConditionInPolicyRepository and ActionInPolicyRepository associations. The PolicyRepository is an area that is used to store reusable policy objects, such as conditions and actions. This will be discussed more in the talk by Yoram Snir. A PolicyCondition and a PolicyAction can be either rule-specific or reusable. If it is rule-specific, then it can't be reused, it is specific just to a single PolicyRule. In this case, the PolicyCondition (or PolicyAction) would be attached directly to a PolicyRule class. If the PolicyCondition or PolicyAction is reusable, then it is stored in the PolicyRepository and referenced in a class using a DN pointer. Note that if the PolicyCondition (PolicyAction) is reusable, then it may be used in multiple PolicyRules, not just in a single PolicyRule. This implies that the existing naming scheme in CIM needs to be enhanced. In CIM, weak relationships are used to scope a class. But this mechanism only allows entities to be named by one superior. In LDAP, we have the concept of possible superiors, which we use in the policy model to describe PolicyCondition (PolicyAction) classes being scoped either by a PolicyRule, or by a PolicyRepository. So we've submitted a formal change request to the CIM specification to enhance its naming. Also new is the concept of resource manager. The slide shows a subject (a user sitting outside a firewall), a target (a host sitting inside the firewall), a resource manager (the firewall), and an application of policy, that enables some set of users to get through the firewall, while blocking others. This is a general model (e.g., it could represent a user trying to get access to a file system). This is an enhancement of the old jurisdiction model, and also an enhancement of the concept of roles as it applies to policy. The concept of a role can e thought of as something that enables the PDP/policy consumer to retrieve policies that specifically apply to the PEPs/policy targets that are under control of the retrieved policy. Subject and target are therefore manifested as something that are defined by PolicyConditions in our model and relationships between the PolicyCondition and entities in the System (subclasses of ManagedElement). Also new is the ResourceManager. This is modeled through the ResourceManagerCollection class, and a set of 3 associations (ResourceManagerCollectionPolicyRule, ResourceManagerManagedResource and ResourceManagerPolicyRule) and an aggregation (MemberResourceManager). The aggregation models the resource managers for the resources that are to be controlled (since these are modeled as instances of a Service class). (No comments) LDAP Core Schema Update and Discussion Bob Moore First chart shows the overall inheritance model of the LDAP Core Policy Schema. There are 17 classes that comprise this schema. Most of this has been around for a while, and is very stable. The second chart shows the various DN pointers that are used throughout the schema. Of these, the policyRuleConditionAssociation and the policyRuleActionAssociations are new. This is in response to changing the definition of policyCondition and policyAction into aux classes, so that they can be used either as rule-specific or reusable building blocks. The next slide illustrates the DIT containment defined in this draft. The far left (policyRepository) is used to contain reusable policy objects, while the center (policyRule) is used to build rule-specific classes. The next slide summarizes what can be contained by what class. The policyElement aux class is new it can be attached to anything. Its purpose is to identify a class that is not part of the policy schema as being related to policy. This enables classes outside of the policy schema to be identified to the PDP/policy consumer so that they can be included in the policy-based management of the system. For a rule-specific condition (action), there is the policyRuleConditionAssociation (policyRuleActionAssociation) that is attached to the policyConditionAuxClass (policyActionAuxClass). The condition or action itself is via aux attachment, and is DIT contained under the policyRule. For reusable conditions (actions), the condition (action) is contained in the policyRepository. It has two structural classes (policyConditionInstance and policyActionInstance) that are contained in the policyRepository, which are used to attach reusable conditions and actions to, respectively. The policyRuleConditionAssociation (policyRuleActionAssociation) classes have DN pointers to the instances (policyConditionInstance, policyActionInstance) to which the reusable conditions and actions are attached. Note that the DIT containment for the reusable conditions and actions is in the policyRepository, not in the policyRule. Q (Yoram): DN Pointer slide. There should be a DN pointer between policyRule and policyRuleConditionAssociation (and also policyRuleActionAssociation) because this is the only way we can ensure that the containment isn't broken. A (Bob): not sure, should discuss it later Q (Yoram): Shouldn't the subject and target associations be associated to a policyRule instead of a specific policyCondition? A (Bob): But reusability is at the condition and action level, not at the rule level. In addition, this allows a more normalized model. Q (David B): What else can we move up from the QoS models to the core model? Concern is whether other users of other domains will invent incompatible ways of representing the same thing. A (John): We've pulled from the QoS schema the concept of a policyRepository and invented the concept of a resourceManager to solve some problems implied by the QoS schema. Perhaps additional things should be pulled up, but we should first re-examine the new work on QoS schemata and then revisit this question (either here or on the list). Policy QoS Schema Discussion and Update Yoram Snir This schema is derived entirely from the core schema, and extends it in ways necessary for representing provisioned and signaled QoS. We introduced the notion of policy repositories (repositories within the repository) and reusable objects, which have been moved into the core schema since they are generally applicable to all policy systems. Policy repositories identify a section of the DIT to be used as a storage area within the DIT. This is important, because it enables reuse and solves some LDAP problems. It does this by requiring entities that want to reuse objects in the policy repository to reference them via DN pointers. This enables these (reusable) objects to be stored once in the directory (avoiding nasty instance tracking and updating issues) and the directory itself to update references to those objects. We've extended the definition of conditions and actions to accommodate QoS-specific actions. Slide 4 shows a sample containment hierarchy, which illustrates how policy can be scoped at different levels of a system. Containers are usually based on auxiliary classes, which enables them to be attached to any portion of the DIT so that entries may be added at that particular containment level. The qosPolicyDomains container represents the root of the policy repository. It contains a number of containers, each an instance of the qosPolicyDomain class, that model the different scopes (e.g., areas of administrative domain) of a system. This lets different administrative (or other) scoping of policy rules to be applied to different portions of a system. Each qosPolicyDomain container contains an ordered list of QoS policy rule groups, which are implemented as instances of the qosPolicyNamedContainer class. The auxiliary class PolicyGroupContainmentAuxClass is used to associate these qosNamedPolicyContainer objects to a specific qosPolicyDomain. Next slide is an example of the policy hierarchical namespace. We see a Domains instance, which is the root of a set of commonly administered policies. Immediately below this is an instance of the qosPolicyDomain class, called QPM Administrated Domain, which is an area of the DIT that is used to contain policy rules for the QPM system. Policy rules for other systems are contained in sibling containers to this container. The QPM Administrated Domain container contains an instance of the qosNamedPolicyContainer, called My Application, which in turn contains a set of policy rules. This structure enables these policy rules to be commonly administered and reused. Next slide is an example for how rules are processed. Two strategies are defined: first-match and match-all. We also use rule priority to disambiguate the rules. The example shows three sets of policy rules (XA and YA, XB and YB, and XC and YC) which each have the same priorities (2, 3, and 4, respectively). However, they are scoped by Group X and Group Y, which have priorities 6 and 9, respectively. So, we can disambiguate all of these using first the group priority and then the rule priority. Next is an example of a QoSPolicyRule. What we have is a complex condition followed by two actions (marking and policing). The slide shows that the order of execution is determined not by the order of the listing of the rules, but rather by comparing first the relative order of the priorities of the policyGroup, and then the relative priorities of each of the policyRules within a particular policyGroup. Slide 8 shows the structure of a QoS policy rule. In this example, there is a DN pointer to a set of policyCondition objects. There are also two DN pointers to two different actions (a marker and a policer), with the policer having special attributes attached via an instance of the DiffServPolicer class. Slide 9 shows how a QoS policy rule is built by attaching appropriate aux classes, and slide 10 shows an example of a complex condition. Slide 12 shows graphically how a simple condition can be built thru referencing variable and constant objects, while slide 13 shows the exact same simple condition built as a reusable condition using aux classes. Slides 14 and 15 define the use of variables and constants in this draft. Variables and constants are also extensible, and support constraints on the variables and constants as well as predefined variables and operators. We currently support three defined types (number, string, and IP address) and can add more as required. Slide 16 defines specific QoS Actions that were defined in order to support ordering, and then specialized to support DiffServ and IntServ specific actions. Slide 17 describes the goals in building reusable objects. Reusable objects are used for several purposes: sharing objects between policy rules, encapsulating a set of variables and/or constants (so that you don't have to find and maintain multiple instances of the same abstraction, like the value of a web server port) and data integrity. Slide 18 defines the goals for building reusable object-repositories. These repositories provide a hierarchical namespace within a DIT that maps to applying different administrative scoping to objects comprising the policy system. Slide 19 shows the repository structure. It has a list of containers, each of which has a list of reusable objects. A sample set of repositories is shown in slide 20. This is described in detail in the draft. Future work is shown in slide 21. Currently, the QoS schema is not synchronized with the latest version of the core schema, which will happen shortly. We need to add the ABNF representation, and formalize this into a repository-independent informaiton model. We need to extend the definition of PHB support, and to extend the use of operators. Q (Ed): When do you think that the core model will meet your needs. A (Yoram): We're close, but we still think that we need additional consistency mechanisms as part of the core model. We also think that the atoms (e.g., variables and constants) should be moved up into the core model. Q (Ed): So you think you've already identified what needs to be moved into the core model? A (Yoram): Yes. Q (David B): Question is not if we can extend the core model, since this draft has already done that. Question is rather what additional concepts from the QoS model make sense to be moved into Core. For example, look at the decision strategy approach in the QoS model. He has constrained the basic generic structure of groups, for example, to be able to disambiguate which rules fire in groups. A (Yoram): We'll look at this and report back to the list. Q (John Sch): Thinks that most of the machinery in this draft can also be used for security. However, have a concern over atoms if we don't constrain them to networking functions, then they aren't as usable. Wants support for masked variables, and this should also be moved into the core model. Mentioned well-known ports, but these are done through IANA. So shouldn't the schema reflect this? A (Yoram): But this shouldn't be part of the schema per se, right? If you want to use IANA's values, then the user could add those. Q: problem is that an integer is not sufficient to represent the semantics of things we are interested in. For example, both DSCPs and a port number can be integers, but the semantics are different. Also, there are symbolic names (IANA calls them KEYWORDS) assigned to these. The core schema should have a mechanism A (John) : John Schnizlein gets this action, to work with John, Bob and Ed to determine if this should be added to the core schema Q: on the containment hierarchy and scope slide, the conditions and actions aren't reusable, correct? A (Yoram and John): Correct, conditions and actions here are rule-specific. The qosNamedPolicyContainer object, which is an instance of policyGroup, is used to group together related policyRules for (for example) administrative purposes. Q (Yoram B): Presented a draft yesterday in RAP that associate string names with application names and IDs. This mechanism should be combined with the mechanisms here. If done right, this enables us to identify different uses of the web port (e.g., identifying HTTP traffic is not enough). We should support this in the core and QoS models. A (Yoram S): We do this, but as an extension. Q (David D): What do you mean by constraints? A (Yoram): We have provided a mechanism to add constraints that are application-specific. We haven't embedded it into this schema directly, because it is application-specific. Q (Yoram B): How closely does this map to the MIB and the conceptual model A (Yoram S): This is a higher-level abstraction of that. A (John): Walter (next presenter) will be talking about the lower-level QoS draft, which models the QoS capabilities of devices. This draft is directly related to both the conceptual model and the MIB. Device QoS Model Description and Update Walter Weiss Slide 2. This draft is complementary to the draft just presented. Whereas the previous draft described extending policy structure by subclassing the policy core model, this draft refines the network model to represent the QoS capabilities of devices. We've tried to map this explicitly to the conceptual mode, and are in the progress of mapping this to the DiffServ MIB. This also sets the stage for differentiating between modeling the state vs. the configuration of a device, and for incorporating roles. Slide 3 is a simplified overview of the QoS Model. The red classes are those that are new; the black classes represent the existing network model classes that this draft refines. Slide 4 describes the concept of a QoS Service. This includes not just the separation of configuration vs. state, but more importantly the representation of the capabilities of the device vs. any constraints that may be applied that prohibit or otherwise restrict the use of one or more of its capabilities. Slide 5 shows the FilterEntry and FilterList classes. These provide a way of specifying a particular condition to test, such as sourceIPAddress. Q (Ron): Isn't filter the same class as in Yoram's draft. A (John): No, this is a more general, yet device-specific, concept. Q (Chris): Don't these drafts conflict? A (Walter): The objective of this draft is to explicitly call out attribute level binding. A (John): The previous draft subclasses the policy model, and this draft subclasses the network model. Think of the previous draft as aimed at specifying the high-level structure of a policy, whereas this draft specifies the operands that can be used in that high-level structure. Q (Yoram S): We should combine the two drafts into a single draft. A (John): Think we should complete the specification of this draft and then consider doing that. Slide 6 describes the the different types of QoS Capabilities that we represent in a device. The purpose of this is to describe what is available in a given environment, or what is available for use by a specific application. Constraints are used to limit what capabilities can be applied on an application-specific basis. Slide 7 shows the different Service Relationships that are modeled. Main purpose of this slide is to draw attention to the ServiceServiceDependency association. This is used to resolve the modeling of data flow. One of the problems identified in the conceptual model is the flexibility in the composition and ordering of components in the forwarding path. So, referring to the next example, you might have a higher level service that conditions HTTP traffic. This might use a set of ServiceServiceDependency associations to bind together the different component services (marking, metering, etc.) that are used by the (higher-level) service that conditions the HTTP traffic. Slide 9: Roles. There are two different interpretations for roles. One is to provide a list of targets for the policy. The other is to provide a context for the policy to execute in, binding policy attributes to an instances (e.g., the set of queues in an interface). We debated this, and decided that there was a problem. Roles are defined on a policy level, and can't be used to specify both interface-level and queue-level attributes. So we decided that we really needed additional information (e.g., if we have a role talking about QueueDepth, then we need additional information, such as the Service that is using it, in order to provide a context for setting this attribute). Furthermore, we can't use PIBs and MIBs unless this context is identified. Note that if we incorporate things like "use queue 3" in a policy, this only works for the interface (and possibly a specific device) that this policy was built for. In particular, this policy doesn't work well for systems that only have 2 queues! So, referring to the Service Relationships Example slide, we combine the specific attribute to be set with the name of the service that is providing the context to set this attribute. Q (Ron): how do monitoring attributes apply to a directory? A (John): They don't. Remember, this is a general information model, not a data model. As such, we represent all necessary data in the model. Various data models can be produced from this information model; the mapping of the data in this information model to a data model useful for directories would not include such data. Wrapup Ed Ellesson The sense is that we're getting very close to stability in the policy core model and schema. We should first stabilize the requirements and framework document, and target these for a January release. We could then get the core information model and schema drafts out around March. We should comment on merging the two QoS drafts in the list.