Subject: RE: Consensus ?

From: "Stevens, Mark" <[email-masked]>
Date: Fri, 3 Dec 1999 17:46:28 -0500

John:

I have a few concerns and observations. Initially, the policy
working group decided that it would develop policy for QoS.
QoS policy would serve as a worked example, but focusing on 
QoS was not intended to confine our work to the treatment of
network traffic as your partial definition of policy may 
imply to some readers. As we go forward, we must remain 
mindful of the intent to be able to express references to 
concepts beyond traffic handling, such as IP address pools,
route partitions and the like. We must be prepared to 
develop support for policies that refer to quantities and 
qualities outside the scope of the treatment of traffic. 

In reference to your examples of invariant, internally,
we have been referring to these kinds of policies as 
configuration policies. We define configuration polices as
groupings of configuration settings that when put in place,
effect the desired outcome. These kind of policies are not
intrinsically event-driven, with the exception of time in
some instances. That said, although event driven policy is
quite interesting, I see configuration policy as a 
reasonable place to start given that COPS-PR provides a 
readily useful uni-directional method for delivering 
configuration.

-Mark

John Schnizlein wrote:

> Since I have not seen a sufficiently clear answer to this,
> here is one: These new colloquial terms are not useful.
> More importantly, they apply to the architectural blocks that
> we have failed to progress for a year (for different reasons).
>
> The proposal that we focus on functional blocks instead of
> components of an architecture identified the functions of
> translating, storing, and distributing policy information.
> This approach holds some promise for helping to crystalize
> the meaning of the critical term, "policy". Mark's proposal
> that a Policy Rule is "to express a desired outcome of the
> operation of a service in a network" is a good start.
>
> We have also discussed statements that policy is a set of
> relatively stable rules for configuration in business terms.
>
> A source of some concern, and at least 3 BOF presentations,
> is the idea that policy, expressed in terms of
> if <condition>, then <action>,
> supports general programming of devices. Most of the buzz
> in my vicinity during these discussions was that programming
> was much to general and powerful for what we want to do.
> Instead of conditional actions, I propose that we specify
> policy rules in terms of what are called "invariants" in
> programming language theory. These are statements that are
> supposed to be true across the flow of execution of a program,
> and therefore independent of the state of the program.
>
> Examples would be like these:
> 1) this kind of traffic gets this service
> 2) traffic from/to these stations/users is of this kind
> 3) this service requires this per-hop behavior across its path
> 4) this service gets this amount/share of bandwidth
> While these examples relate to QoS, more detail about the path
> (containing a firewall) and less about the service (drop) might
> extend it to much of the security domain.
>
> Information other than policy, but necessary in order to translate
> policy into configuration, such as which users appear at what IP
> addresses and ports, would also me exposed by this sort of
> functional decomposition.
>
> The term policy appears to have the following partial definition:
> a set of statements about the treatment of network traffic based
> on the business's allocation of resources, and invariant across
> the network.
>
> Is this alternative approach attractive to you?
>
> John
>
> At 06:46 PM 11/22/1999 -0500, Shai Herzog wrote:
> >I agree, we are generally describing 4 basic functional
> >blocks.
> >
> >1. MA: Repository                 (non volatile storage, interoperable)
> >2. PA: Policy server/advisor/...  (brains)
> >3. ED: Enforcement                (muscles)
> >4. UI                             (Console)
> >
> >I think this is the clearest functional breakup that we started
> >with and we keep on returning to (under different names).
> >
> >As usual, the IETF doesn't care about specific implementations
> >which may couple one or more of these blocks in the same physical
> >device (such as ED+PA: a.k.a. grown up kid ;-)
> >
> >I think we've been confusing this with what I call "Policy Operations"
> >which is the "Algebra" of policy processing.
> >
> >So far, we've defined the following policy operations:
> >
> >1. Decision
> >2. Translation
> >3. Formatting (which I'm not sure we defined well as of yet).
> >4. ...
> >
> >I claim that this is ALGEBRA operators and NOT functional blocks
> >and the reason is that they have no pre-defined order and may apply
> >on PORTIONS of a policy rule.
> > ...
> >At 12:03 PM 11/22/1999, Ron Josephson wrote:
> >>...
> >>We are basically defining a rather simple 3-Tier architecture:
> >>
> >>Policy Server - MA - (Repository, DB) - Dumb.
> >>PA - PDP -Intelligence - Smart.
> >>ED - PEP - Client. - Dumb.
> >>**Can someone explain me why we've changed the wording?
> >>
> >>
> >>From: John Strassner <[email-masked]>
> >>...
> >> > Mark is also correct, in that we decided in the Policy Framework wg
> >>meeting to define terminology that described functional blocks of a
system
> >>that are independent of protocol or implementation. There are many
possible
> >>architectures that can be built. It is not our job to define an
architecture
> >>in the terminology draft, or even to imply one; rather, it is our job to
> >>define terminology to represent functions that can be used to assemble
an
> >>architecture. We should strive NOT to define an architecture, but rather
to
> >>describe terms that can be used to build an architecture
> >>...
> >> > At 05:00 PM 11/15/99 -0500, Stevens, Mark wrote:
> >> > >...
> >> > >From my perspective, it appeared that we had developed a
> >> > >modicum of consensus in the policy working group meeting
> >> > >when we heard the suggestion that we define terms that
> >> > >describe functional blocks within a policy system. It was
> >> > >my understanding of the suggestion to mean that these
> >> > >functional blocks would describe necessary and sufficient
> >> > >processes within a policy system that when combined in one
> >> > >way or another could affect policy in a network. The terms
> >> > >you describe below appear to be little more than new names
> >> > >for the components of a preconceived architectural model.
> >> > >Policy-based networking is more than outsourcing decisions.
> >> > >We need to break the process down into functional blocks
> >> > >and work from there. Once defined, the functional blocks
> >> > >can then be grouped and interconnected with protocols as
> >> > >appropriate.
> >> > >
> >> > >My first pass at functional blocks includes:
> >> > >
> >> > >Policy Rule - to express a desired outcome of
> >> > >              the operation of a service in a network
> >> > >
> >> > >Policy Processor  - to find and interpret policy rules
> >> > >                    by or on behalf of a service
> >> > >
> >> > >Policy Repository - to store and retrieve policy rules
> >> > >
> >> > >Policy Interface - to provide an implementation-independent
> >> > >                   description of interesting network
> >> > >                   services
> >> > >
> >> > >Policy Proxy - to provide a Policy Interface where none
> >> > >               exists
> >> >
> >> > [js] I think that this is a good start. I do, however, think that we
may
> >>want to formalize the notion of "translating" the description and/or
> >>specification of a policy rule between functional components (e.g., it
may
> >>need one form in a UI, a different form for storage in a particular type
of
> >>data store, and yet another form to be applied to a device).
> >>
> >> > [js] .... So, I would propose that we go back to Mark's
> >>definitions and begin anew.