Subject: RE: WG Last Call: PCIM (Issue 2)

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 26 Jan 2000 15:38:37 -0500

I was originally planning on dealing with this issue later. However, since
PCIM so blatantly raises it and we want to get through last call quickly, I
will bring it up now to give adequate time for discussion. In reference to
the following text:

<PCIM>
2.2. Declarative versus Procedural Model

   The Policy Core Information Model is declarative, not procedural.
   Given that standardization efforts in policy should address policy
   definitions at the role level, the next issue is to decide on a
   language framework to define policies.  There are several design
   considerations and trade-offs to make in this respect.

   1.  On one hand, we would like a policy definition language to be
       reasonably human-friendly for ease of definitions and
       diagnostics.  On the other hand, given the diversity of devices
       (in terms of their processing capabilities) which could act as
       policy decision points, we would like to keep the language
       somewhat machine-friendly, i.e., relatively simple to automate
       the parsing and processing in network elements.

  2.  An important decision to make is the semantic style of the
       language, procedural or declarative.

       o  The procedural approach would model network behavior that is
           to be regulated through policy in terms of states and
           pertinent events.  In this model, policy directives are
           statements that control the state transitions and thereby
           regulate the network behavior.  An example of state is
           installing or removal of packet classification filters  and
           the appropriate configuration actions for traffic
           conditioning.  Examples of events include device boot-up,
           packet arrival, etc.

       o  The declarative approach would simply describe the desired
           network behavior in terms of certain actions that should
           happen when specific conditions hold.  For example, a policy
           directive that states that packets matching a specific traffic
           profile must be conditioned in a certain way is formulated in
           terms of conditions that describe the traffic profile and
           actions that describe the traffic conditioning behavior.  A
           policy rule in this approach is written as "if (policy
           condition) then <policy action>."

       The declarative approach has the benefit of simplicity, and
       facilitates hiding implementation differences, making it a
       suitable candidate for the policy definition language standard.
</PCIM>

This text raises an interesting question although the terms strike me as
somewhat misleading. Therefore, I will first discuss the use of terms and
see where we end up. In my understanding of the definitions of procedural
and declarative are somewhat different from those used in the text above:

Declarative: A set of actions triggered by a well known (possibly canned)
condition. 
Procedural: Any execution stream.

The main justification of declarative over procedural was that atomic
actions are easier to implement. In addition, simple actions can be grouped
to identify and arbitrate conflicts. In contrast, a procedural policy could
nest policies (or conditions) within other policies and describe more
complicated interactions at the expense of making conflict detection more
difficult if not impossible.

However, the PCIM text above takes a completely different slant. Declarative
is described as a high level behavior of the system while procedural is
described as an interaction with the system. So before we go any farther,
lets agree on definitions for each of these concepts. I would prefer that we
stick with the original definition of declarative and procedural as
discussed in previous meetings (and as I have described them in this
message). Then we can create terms for the possible ways to represent a
policy. If we can agree on my (or someone else's) definitions, we can start
on the next set of issues with this text.

In the PCIM text as described under declarative, I would suggest the term
"Behavioral Simulation Policy." In essence, the policy attempts to simulate
the behavior of a system at some high level. In the example given in the
declarative section of PCIM above, if a forwarding engine were to interpret
this policy directly, it would process the policy on a packet by packet
basis (just like an instruction stream). 

In the PCIM text as described under procedural, I would suggest the term
"System Interaction Policy." In this approach, the policy would interact
with the system to achieve a global objective. Using the same objective, the
policy would use a set specific values in the profile components and traffic
conditioning components of the forwarding engine. However, from the policy's
perspective, these components are black boxes.

Comments...

-Walter

---

From: "Ken Roberts" <[email-masked]>
Date: Thu, 27 Jan 2000 13:03:02 -0600

Walter,
You raise some interesting thoughts. If I may digress the debate between
procedural and declarative I've been through it before. The solution in the
past has been to NOT mandate one over the other but to standardize the
interface used to request information etc. In this way individuals aren't
"limited" and vendors may build machines using whatever technology they
think is viable to "answer" the question. The question of course is whether
the proposed action/ state change/ etc is consistent with the policies in
force at the time.
All sorts of possibilities exist to implement the "engine" using all sorts
of technologies. I would be disappointed if everyone had to use one, and
only one, technology.

--------------------------------------------------------------------------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   :        655-7844			?Direct  : 408-565-7844
?  Fax    :        408-565-8226
? email :      [email-masked]
 
This message may contain information proprietary to Nortel Networks
Corporation so any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.

 -----Original Message-----
From: 	Weiss, Walter [mailto:[email-masked]] 
Sent:	Wednesday, January 26, 2000 12:39 PM
To:	[email-masked]
Subject:	RE: WG Last Call: PCIM (Issue 2)

<PCIM>

Comments...

-Walter

---

From: Bob Natale <[email-masked]>
Date: Thu, 27 Jan 2000 18:11:57 -0500

At 1/27/2000:02:03 PM, Ken Roberts wrote:

Hi Ken,

>All sorts of possibilities exist to implement the "engine" using all sorts of technologies.
>I would be disappointed if everyone had to use one, and only one, technology.

I couldn't agree with you more.  And this latter mistake -- i.e., mandating
(deliberately or inadvertently) one particular interpretation or implementation
choice over all others -- was something that was assidiously avoided in past
successful IETF work...but seems to be slipping into more and more WG outputs
in recent times.  I hope we can reverse that trend.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

---

From: [email-masked]
Date: Fri, 28 Jan 2000 02:28:01 -0500

Walter,

>difficult if not impossible.

Agreed.  There was also the "let's walk before we run" justification.  I don't
think we need to put all of this in the text of the PCIM, though.

Maybe the easiest way to deal with this issue, is to just delete the
justification
and just state that what we have defined is a declarative model, and state what
that means.  Otherwise, I am afraid we will end up arguing about the
justification,
and I think we are way beyond that now.

>"Behavioral Simulation Policy.".....

>"System Interaction Policy." . . . . .

I would prefer to just leave the above paragraphs out entirely, since they
evidently do not contribute to their objective,  which was to justify the use of
the declarative approach.

>Procedural: Any execution stream.

How about this:

(I have taken the liberty of paraphrasing the following from a book titled
"UML and C++, A Practical Guide to Object-Oriented Development", by Richard C.
Lee and William M. Tepfenhart, Prentice Hall, 1997.)

Declarative approach:  Characterized by a data-driven expression of invariants,
constraints, and rules (situation-action heuristics). Distinguished from
procedural
in that the sequence of steps for doing the processing of declarative statements
tends to be left to the implementor (although we have provided for the option of
expressing the desired order of action execution in this policy info model, and
for expressing whether the order is mandatory or not).

Procedural approach: Characterized by a set of instructions which are always
executed
in a specified sequence (as in a program or script).

To quote Ken Roberts, in his note of Jan. 27:

>...The solution in the past has been to NOT mandate one over the other ...
[declarative vs. procedural]
>...vendors may build machines using whatever technology they
>think is viable

I agree with Ken, that we should not dictate implementation technology, but I
don't
think we are doing that, when we say that the model is declarative.  We are
simply
saying that the implementor is free to order the actions in any way that makes
sense
for the given conditions being tested.  Taking a procedural approach would
require that
we specify the condition testing sequence, and the action sequence, in the
policy
repository, which would, indeed, constrain the implementor.  So, I would argue
that
we have, indeed, satisfied the spirit of what Ken is requesting, by saying our
policy model is a declarative one.

In the end, this all gets implemented in code. What we are talking about, when
we
say "declarative", instead of "procedural", I think, is the style of how we
express
the rule semantics in the policy repository. How you implement what executes the
rules
is up to you.

Ed Ellesson
Tivoli Systems
Research Triangle Park, NC
[email-masked]
919-254-4115

---

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 31 Jan 2000 14:07:30 -0500

Ed,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 28, 2000 2:28 AM
> To: Weiss, Walter
> Cc: Ken Roberts; [email-masked]
That's fine.

> the declarative approach.
I disagree. One of the issues we need to address is how policies are
represented. Some of us of suggested that a policy should be described from
the perspective of a input into the system. For example, the forwarding
engine of a router takes as input a packet and the policy is described as
"if an arriving packet is an HTTP packet, mark 1 Mb as in-profile and the
rest as out-of-profile." This is what I have described in the previous
posting as a "Behavioral Simulation Policy" because the policy describes an
abstract processing rule for the forwarding engine. You could almost
describe the policy as a meta-forwarding engine.

In contrast, a "system interaction policy" would use interfaces to the
forwarding engine to construct policies. The same result could be achieved,
however, there are no assumptions about the construction of the forwarding
engine beyond what interfaces are exported by it.

In the former policy model, you are standardizing the behavioral
characteristics of the systems you want to define policy for. In the latter
model, you use defined policy semantics to create new policies on top of the
interfaces defined by services. In the former, a policy crossing say
security and QoS would need to be standardized because the behavioral
interaction between the two technologies would need to be agreed to. In the
latter, the interfaces to security and QoS would be standardized (MIBs,
PIBs, Information Models, etc.) and the policy uses the standardized
interfaces to create policy rules.

I certainly expect that we will not support both policy approaches in this
working group, but even if we do, we need to explain each to the point that
people understand the tradeoffs in the approaches. This does imply some
additional terminology. If you want to defer to the framework document for a
discussion of this issue, that's fine. But then we should not be implying
the use or applicability of either in this document.

> in a specified sequence (as in a program or script).

I am comfortable with these suggestions. I look forward to reading the next
version.

regards,

-Walter