Subject: Suggested new charter for discussion at the interim meeting

From: "John Strassner" <[email-masked]>
Date: Wed, 26 May 1999 09:10:42 -0700

Policy Enthusiasts,

The co-chairs have been working with our Area Director on a revised
charter for the Policy Framework WG (PFWG), attached below for your
review. We plan to discuss this first at the interim meeting, and then
over email.

Most of the changes are responses to current discussion and decisions
made in the PFWG.

Why we are rechartering:

Recently, there has been significant discussion as to whether we can
make progress without an agreed upon, and flushed out, policy
architecture. There has also been significant discussion concerning
the growing complexity of the core schema.

Proposed resolution of these issues:

We need to redo the list and schedule of deliverables. We need to
fine-tune the description, and make some fundamental decisions as to
how broad a scope we want to tackle.

Discussion:

We are reaffirming that our mission is to first develop a secure,
extensible policy architecture, information model, and schema, that
can be used in signaled (e.g., RSVP) and provisioned (e.g., DiffServ)
QoS applications.

Recent mail list and IETF discussions have demonstrated that there is
a lack of focus. This has, for example, caused the core schema to grow
in complexity. Quoting from the original charter:

  “3. The framework and PDL will first concentrate on provisioned and
        signaled QoS. Both will then be extended to consider other
needs.”

Unfortunately, this statement seems to have not been taken literally
enough. The reason for this is quite straightforward, and certainly
justifiable: we not only see other IETF working groups wanting and
trying to use policy schemata, we see the need for other entities that
are not part of the IETF per se wanting to use our work (e.g., to
define backup and restore policies).

While these are certainly good uses of policy, the problem is that
this has degenerated into trying to solve the world’s policy problems.
This is simply too large a task to take on, especially without
implementation experience. The chairs therefore recommend, with the
support of our AD, that we refocus the PFWG  to be limited
specifically to working on RSVP and DiffServ QoS. Every effort will be
taken to ensure that we do not box ourselves into a corner, and
produce an extensible architecture and core schema that can be used
for other disciplines (e.g., IPSec and DHCP). In fact, the simple
point
that we still have a core schema shows that we are trying to produce
an extensible architecture to be used by other disciplines. We will
also try to ensure that we have captured all of the work that has been
done so far. However, we will explicitly defer all questions that do
not
pertain to QoS until a future time. By explicitly limiting the scope
of our work to signaled and provisioned QoS, it will be much easier to
make progress.

An important sub-goal is by producing a Policy Architecture,
Information Model, and Schema that is focused on QoS, rapid
implementation experience can be gained. Given this implementation
experience, we will then be able to extend the architecture,
information model, and core schema as necessary to other application
domains.

A question has come up as to whether we can proceed in building the
core schema without having an agreed-upon architecture. The co-chairs
think that this is largely a semantic argument, revolving around the
definition of what an “architecture” really is. It is also possible
that people are confused between the purpose of the core schema and
the purpose of the QoS schema. The core schema is a means to express
policy and to store it in a repository. Architecture involves
designing the systems, protocols, and communication mechanisms that
are used to implement a solution. The architecture will use the core
schema, but other than that, there is no interdependence between the
architecture and the core schema. Most importantly, finalizing an
architecture will not help in defining what the structure of policies
are,
or how they are represented. In addition, defining an architecture
in absentia of first defining the policies that this group is focused
on
will most likely lead to an architecture in which we try to force fit
policies. We think that this is backwards - we first need to define a
set
of exemplar policies that clearly scope what problems we are trying
to solve, and then build an architecture that can be used to implement
these solutions.

The QoS schema, which is derived from the core schema, has more
dependencies on the architecture. For example, it is concerned with
expressing how certain specific types of conditions lead to particular
actions that affect traffic conditioning. However, this dependence is
not on the communication mechanisms or functions of the devices
involved, but rather an agreement as to what constitutes policy
conditions and actions, and how we can represent those in the
information model.

A related problem is where to draw the line between policies that
reflect business rules and policies that affect device configuration.
Policies (even QoS policies) represent a continuum from business goals
and rules that are used to provide services to how a device is
configured to implement those business goals and services. This
working group will focus as much as possible on policies that affect
devices, while ensuring that they can be linked back to higher-level
policies.

In an effort to focus this work, exemplars of the types of policy that
the architecture, information model, and schemata that are produced by
this working group will either be included in its terminology spec or
be
the subject of a new spec.

Therefore, we recommend that we first define a set of policies that
capture the typical types of conditions and actions, as well as
constitution of policies. After this, work on the core schema can
proceed in parallel with work on defining a policy architecture that
is
specifically targeted to meet the needs of applications using RSVP
and/or DiffServ. Work can also proceed on the QoS schema; however,
after a certain point, this work must wait on the architecture to
define the specific set of conditions and actions that will be
targeted before it can proceed.

Two additional issues are the status of PFDL and the PIB. It is
recommended that work not continue on PFDL until the architecture is
complete. At that time, it may be revisited. The PIB represents a
“missing link” between device-specific parameters, such as those
stored in a MIB, and the higher-level policies that are expressed in
the QoS schema. It is proposed that this working group take on this
work as part of a coherent strategy to link policies expressed as
business rules to how they are implemented in devices.

The above lead to the following revisions of our charter (obviously,
from here below is the proposed charter, which will be submitted
to the IESG for approval after the wg has reached consensus on
its contents; the above is discussion that rationalizes the charter
as well as provides an opportunity for those not at the interim
meeting to get an early feel for the direction of the group).

Last Modified: 21-May-1999

Policy Framework Working Group Charter

Chairs:

Ed Ellesson <[email-masked]>
John Strassner <[email-masked]>

General Area Director:

Fred Baker <[email-masked]>

Mailing Lists

General Discussion:

  List: [email-masked]

  To Subscribe: [email-masked]
  In Body:      subscribe
  Archive:      http//www.raleigh.ibm.com/maillists/policy/

 Description of the Working Group:

Problem Statement:

There is a need to represent, manage, and share policies and policy
information in a vendor-independent, interoperable, scalable manner.
The goal of this working group is to provide a framework that will
meet these needs, along with an information model and schemata
using that framework. These schemata will be used specifically for
QoS traffic management. A secondary goal of this framework is to
show that this general development process can be extended to
other application domains.

Objectives:

The objectives of this working group are to:

1. Define a set of exemplar policies that capture a representative
set of conditions and actions, as well as how they are used to
define the structure of a policy, to guide us in defining a
framework and schemata to store, retrieve and process
these definitions.

2. Define a secure architecture for policy definition and
administration for a heterogeneous set of Policy Enforcement
Points. The framework will be shown to be able to represent and
manage policy information in an unambiguous, interoperable
manner in a single administrative domain. It is assumed that a
single Policy Server controls this domain. Furthermore, this
domain will store policy information in  a directory,
accessible using LDAP. Care will be taken to ensure that this
work is extensible to other types of repositories, such as
relational databases.

This framework is specifically limited to provisioned and
signaled QoS for the current time.

3. Define an information model and schema that can be used to
represent policy information and structure. This will be referred to
as the core policy schema. This schema will serve as a basis for
producing various specialized schemata that are targeted
specifically at expressing policy information for a particular
application domain.

The only specialized schema that will be developed at this time
is one for RSVP and differentiated services.

4. Define an information model and schema that can be used to
represent signaled and provisioned QoS. RSVP and
differentiated services will be specifically modeled in this schema.
This schema will be derived from the core schema.

This working group will work with the DiffServ, IntServ, RAP, and
ISSLL working groups to ensure that the QoS schema meets their
Technical needs, and is suitable forr both IPv4 and IPv6 standards
track work.

5. To ensure that security issues are addressed, Russ Mundy will
serve as this working group's security adviser.

6. The charter specifically excludes:

      -protocol definition
      -schema attributes or classes that are vendor-specific
       (although the schema defined in this group will be defined in
       a way that is extensible by specific vendors)
     - schema work for applications other than those supporting
       RSVP and differentiated services

 Goals and Milestones:

1. Policy terminology draft (Informational Track)
  - Working Group Last Call in Oslo IETF, Summer 1999
2. Core schema draft (Standards Track)
  - Working group Last Call, September 1999
3. Architecture draft (Standards Track)
  - Working group Last Call, Washington IETF, Fall 1999
4. QoS Schema draft (Standards Track)
  - First issuance, no later than Oslo IETF, Summer 1999
  - Working group Last Call, Adelaide IETF, Spring 2000

Existing Internet-Drafts

 "Terminology for describing network policy and services",
 John Strassner, Ed Ellesson,

<http://www.ietf.org/internet-drafts/draft-strassner-policy-terms-01.t
xt>

Policy Framework Core Information Model,
John Strassner, Ed Ellesson, Bob Moore,
http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-03.t
xt

---

From: "Ken Roberts" <[email-masked]>
Date: Thu, 27 May 1999 12:31:13 -0500

Folks,
I agree it would be prudent to limit the scope of the work to what is
understood and attempt to progress this to completion(?). However I cannot
agree with the statements that the architectural issues are "semantic". 
Unfortunately in the real world the customer isn't only in the Enterprise
space and the requirements aren't only expressible in Enterprise specific
terms. An architecture that doesn't address (i.e. be extensible to
accommodate) the entire problem statement isn't sufficient. We see work in
other bodies using models aligned marginally different becoming integrated
with the IETF work - to date the IETF work has been largely separated from
these other initiatives.
I believe it is grossly premature to assert there is a comprehensive
architecture or even that the existing architecture can be extended to
address the full problem statement; so I can't agree there is no need for
this work to be undertaken. As stated above I do agree current work should
progress and urge the co-chairs to invent a solution where both "tracks" can
proceed. I wouldn't like to see a fragmentation of this work so it seems to
me to be best if both tracks were under the auspices of the PFWG but
separate such that work could proceed somewhat independent.
Ken Roberts
Optivity INM VCU
Phone: +1(408)565-7844
	       ESN 655-7844
Email:  [email-masked] <mailto:[email-masked]> 

	-----Original Message-----
	From:	John Strassner [SMTP:[email-masked]]
	Sent:	Wednesday, May 26, 1999 9:11 AM
	To:	policy
	Cc:	johns; ellesson; fred; wijnen; randy
	Subject:	Suggested new charter for discussion at the interim
meeting
	Importance:	High

	Policy Enthusiasts,

	The co-chairs have been working with our Area Director on a revised
	charter for the Policy Framework WG (PFWG), attached below for your
	review. We plan to discuss this first at the interim meeting, and
then
	over email.

	Most of the changes are responses to current discussion and
decisions
	made in the PFWG.

	Why we are rechartering:

	Discussion:

	We are reaffirming that our mission is to first develop a secure,
	extensible policy architecture, information model, and schema, that
	can be used in signaled (e.g., RSVP) and provisioned (e.g.,
DiffServ)
	QoS applications.

	Recent mail list and IETF discussions have demonstrated that there
is
	a lack of focus. This has, for example, caused the core schema to
grow
	in complexity. Quoting from the original charter:

	  "3. The framework and PDL will first concentrate on provisioned
and
	        signaled QoS. Both will then be extended to consider other
	needs."

	trying to use policy schemata, we see the need for other entities
that

	While these are certainly good uses of policy, the problem is that
	this has degenerated into trying to solve the world's policy
problems.
	This is simply too large a task to take on, especially without
	implementation experience. The chairs therefore recommend, with the
	support of our AD, that we refocus the PFWG  to be limited
	specifically to working on RSVP and DiffServ QoS. Every effort will
be
	taken to ensure that we do not box ourselves into a corner, and
	produce an extensible architecture and core schema that can be used
	for other disciplines (e.g., IPSec and DHCP). In fact, the simple
	point
	that we still have a core schema shows that we are trying to produce
	an extensible architecture to be used by other disciplines. We will
	also try to ensure that we have captured all of the work that has
been
	done so far. However, we will explicitly defer all questions that do
	not
	pertain to QoS until a future time. By explicitly limiting the scope
	of our work to signaled and provisioned QoS, it will be much easier
to
	make progress.

	A question has come up as to whether we can proceed in building the
	core schema without having an agreed-upon architecture. The
co-chairs
	think that this is largely a semantic argument, revolving around the
	definition of what an "architecture" really is. It is also possible
	that people are confused between the purpose of the core schema and
	the purpose of the QoS schema. The core schema is a means to express
	policy and to store it in a repository. Architecture involves
	designing the systems, protocols, and communication mechanisms that
	are used to implement a solution. The architecture will use the core
	schema, but other than that, there is no interdependence between the
	architecture and the core schema. Most importantly, finalizing an
	architecture will not help in defining what the structure of
policies
	are,
	or how they are represented. In addition, defining an architecture
	in absentia of first defining the policies that this group is
focused
	on
	will most likely lead to an architecture in which we try to force
fit
	policies. We think that this is backwards - we first need to define
a
	set
	of exemplar policies that clearly scope what problems we are trying
	to solve, and then build an architecture that can be used to
implement
	these solutions.

	The QoS schema, which is derived from the core schema, has more
	dependencies on the architecture. For example, it is concerned with
	expressing how certain specific types of conditions lead to
particular
	actions that affect traffic conditioning. However, this dependence
is
	not on the communication mechanisms or functions of the devices
	involved, but rather an agreement as to what constitutes policy
	conditions and actions, and how we can represent those in the
	information model.

	A related problem is where to draw the line between policies that
	reflect business rules and policies that affect device
configuration.
	Policies (even QoS policies) represent a continuum from business
goals
	and rules that are used to provide services to how a device is
	configured to implement those business goals and services. This
	working group will focus as much as possible on policies that affect
	devices, while ensuring that they can be linked back to higher-level
	policies.

	In an effort to focus this work, exemplars of the types of policy
that
	the architecture, information model, and schemata that are produced
by
	this working group will either be included in its terminology spec
or
	be
	the subject of a new spec.

	"missing link" between device-specific parameters, such as those

	Chairs:

	General Area Director:

	Mailing Lists

	General Discussion:

	Problem Statement:

	Objectives:

	      -protocol definition

	 Goals and Milestones:

	Existing Internet-Drafts

---

From: Dan Romascanu <[email-masked]>
Date: Sun, 30 May 1999 15:37:12 +0200

Keith,

I am somehow confused about how you define a 'PIB' and I would like to
ensure that I understand well what is your proposal. The closest thing to a
definition that I could find was in the minutes of the Minneapolis meeting,
where you are quoted having said:

>The PIB is a policy-based abstraction, joining the capabilities as
described in the MIB with
>the higher-level business rules defined in (for example) a QoS Schema. The
PIB joins these
>two different, yet related, sets of information. The PIB is a special type
of MIB, and can in
>fact algorithmically be transformed into a MIB. However, not all of the SMI
is needed for
>the PIB.  

Shouldn't we first define formally the SMI subset that we are referring to?
That would also clarify those 'algorithms' that translate MIBs into PIBs, as
well as the relationship between the PEPs and respective SNMP agents. If any
pointer is available to some more consistent definition, please let me know.

It's only after having clarified this, we can approach the second issue,
defined by John in his new charter mail:

>The PIB represents a
>business rules to how they are implemented in devices."

Here my question is how does the PIB act as 'the missing link' between the
general model of the higher level policies and the device specific
information (usualy expressed in MIBs) which in so many cases is specific to
the capabilities of that or other class of device or of the PEP
implementation in the RAP model.

It looks like we need some more focused discussion until we understand what
are the missing elements in the architecture and how they exactly relate one
to the other.

Best Regards,

Dan
  
> From:	Keith McCloghrie [SMTP:[email-masked]]
> Sent:	? ??? 27 1999 3:57
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: Suggested new charter for discussion at the interim
> meeting
> 
> Raju,
> 
> On day-one of SNMP, each device had at most one agent and that agent
> was for its device.  Not too many years later, we had multiple agents
> in a single chassis, agents with multiple logical devices, proxy agents
> handling requests for multiple devices, etc., etc.  I can't predict
> whether the same will the same happen for PEPs.  In any case, an issue
> when using both MIBs and PIBs will be that the COPS agent will not
> necessarily be one-to-one with an SNMP agent (or, a contextEngineID
> and contextName, see RFC 2571).
> 
> > 1. I agree that we need means of recording PEP capabilities, so that
> policy
> > servers and other management entities may query a network device (say a
> > router) and figure out whether it is RSVP aware, or DS capable or
> whatever,
> > and the service types it supports (controlled load, expedited
> forwarding..).
> > Are we using PIBs to be the common information model to record this
> > information? Why cant we use MIBs to do the same job?
> 
> In this case, because you're asking about (static) "PEP capabilities",
> use of the PIB ensures that you get the right information, irrespective
> of the relationship between the PEP and associated SNMP agent(s).
> 
> > 2. Further, during the operation of the device we may need to store
> certain
> > device states that are germane to policy. These could include link
> > utilization or policy errors or warnings about imminent policy failure.
> > These too need to be stored and dynamically retrieved by policy
> > servers/management tools. Do we intend to use PIBs for this purpose too?
> =
> > Why not MIBs?
> 
> The COPS protocol contains error/warning codes about policies previously
> downloaded to that PEP.  Other network states which might be "germane to
> policy" seem to me to be appropriate for MIBs.
> 
> > 3. If the use of PIBs is to put in hooks through the policy working
> group so
> > that COPS may be the carrier of this information at a later date, I say
> > great! But let's say so right up front, so that those of us interested
> in
> > design/implementation can take a closer look at how it all fits
> together,
> > what works, what doesn't and build it right. If PIBs are to be an
> essential
> > component of the architecture, then let's not pretend in various
> > architectural drawings that an LDAP-only router solution is even
> supported.
> > We are saying that QoS policy is impossible without COPS. (I have no
> problem
> > with such an architecture, and to the best of my knowledge, neither does
> > AT&T :)
> 
> I've not heard people say "QoS policy is impossible without COPS".
> Rather, I think we've said that it's essential to allow the PEP and PDP
> to be separated (to introduce hierarchy, and therefore scaleability),
> and that COPS is being specified as a standard protocol for PEP-PDP
> communication.
> 
> > 4. If we have PIBs in the architecture for QoS, one would wonder why
> notfor
> > IPSec too? I believe there are suggestions to extend COPS to IPSec. It
> would
> > be useful to design PIBs with IPSec in mind too.
> 
> I presume you mean to define the PIB definition language with IPSec in
> mind, rather than to define a QoS PIB with IPSec in mind, yes ?
> 
> Keith.