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).