Subject: Re: snmpconf well, back to work

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Sep 2000 23:41:39 +0200

>>>>> David Harrington writes:

David> 3) We need to plan the agenda for the next interim.

[...]

David> If anybody has any topics they want on the agenda, please speak
David> up.

I am not sure whether I will be able to attend the next interim (nor
did I read the minutes from the last one yet - so the comments below
may be out of line), but I am seriously concerned about some issues.

I believe that the split between a filter script and an action script
is not useful. In fact, this level of granularity will just turn out
to be very impractical if you express real-world policies. I actually
believe that the unit of concern should be a set of logically related
policy rules. (This probably maps to the concept of a PolicyGroup in
PCIM.)

I expect that a device which will be able to parse and execute the
"policy language" for filters and actions will also be able to parse
and execute a "policy language" for sets of policy rules. The
syntactic details you need to separate rules and actions from filters
should be easy to deal with. In fact, not having to expose the filters
and actions in separate MIB objects will save you code since the
policy language compiler/interpreter can now choose the internal
representation that fits best the execution environment. I also expect
that network operators will prefer to write and handle sets of
logically related policy rules in a single language and to store them
in a single file which they push to the managed devices. I don't see
much value in taking such a file on the manager side, to tokenize it a
bit, turn it into chunks of MIB objects that are pushed to the agent
by populating perhaps multiple tables and then ask the agent to
reassemble the data and tokenize the rest into a format that can be
executed.

I certainly like the idea to use languages to implement policies. But
we should be careful that we get the granularity right at the policy
abstraction level and that we divide the processing load in a
reasonable way. Doing a bit parsing here, a bit parsing there and
requiring the agent to provide SNMP access at the granularity of
single filters and actions is will lead to more complexity on both
ends.

Of course, once you accept the idea that policy rule sets are the
right granularity for distribution at the policy level, you can just
use RFC 2592 to distribute and invoke policy rule sets.  All which is
left to do is to reach agreement on a policy language and we are done
with it.

While reading the minutes form the Friday meeting, I got the feeling
that RFC 2592 actually provides answers for quite a few of the issues
discussed in Pittsburgh such as identifying language versions,
language extensions, handling and reporting of syntactic errors,
handling and reporting of execution errors, etc. I recommend that this
WG leverages existing work and focuses the resources that are
available on the new stuff that is in front of us and that the WG
reconsiders the granularity needed to distribute policies to
policy-enabled managed devices.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Jon Saperia <[email-masked]>
Date: Sat, 02 Sep 2000 09:06:44 -0400

on 08/31/2000 1:29 PM, David Harrington at [email-masked] wrote:

> The authors' bulleted lists worked especially well for identifying
> issues to be resolved. We need to verify WG consensus on Pittsburgh
> proposed solutions for the bulleted items. Could the authors publish the
> lists again, and describe potential agreements reached in Pittsburgh,
> and identify which items still have no potential agreement after
> Pittsburgh?  
> 
> If anybody has any topics they want on the agenda, please speak up.
> 
> Thanks,
> dbh
> -- 
Thanks very much. At least as a place holder, for an agenda topic Mike and I
would like to go over issues with the BCP. I know Mike did get some feedback
and I have more to write before we publish in advance of the interim.

Thanks 

/jon

P.S. - If I remember correctly we have the ADs OK on this, just checking. I
know that Bert has been away for a while so Randy is probably backed up as
well.

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 04 Sep 2000 13:06:28 +0200

Juergen,

> policy rules. (This probably maps to the concept of a PolicyGroup in

I do not understand your concern. I think the split is very useful,
because from it nature filters and actions are different things and have
different properties. Why are they impractical?

> policy-enabled managed devices.

I aggree with Juergen, that many Problems discussed in Pittsburgh can be
solved using RFC 2592. Are there reasons not to use RFC 2592?

Marcus
-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 04 Sep 2000 15:19:30 +0200

> different properties. Why are they impractical?

It is impractical because of the fine granularity. The problem is not only
the separation of filters and actions but also the implied separate handling
of each policy. I do not see the need to handle and modify each single policy
separately on the device level. Rather I see a significant potential for
simplification of both the SNMP agent and the management applications, if
policies are being managed in terms of policy groups.

If you would extend the proposed policy language by separators between
filters and actions, and by separators between different policies, you could
describe a complete policy group by a single piece of code that can be
handled as a one entity.

Then, the size of the policy tables would depend on the number of groups
rather than on the number of policies; activating a group would be possible
by a single activation seqence; and so on. This might be really "practical".

    Juergen Quittek
-- 
Juergen Quittek     [email-masked]     Tel: +49 30 254230-19
NEC Europe Ltd., C&C Research Laboratories   Fax: +49 30 254230-99
Hardenbergplatz 2, 10623 Berlin, Germany   http://www.ccrle.nec.de

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 05 Sep 2000 13:52:24 -0700

> policy rules. (This probably maps to the concept of a PolicyGroup in

I've been collecting and writing examples and haven't yet come up
with any impracticalities, much less a class of policy scenarios
that aren't handled by this architecture.

The split between filter (aka condition) and action follows
existing practice in other policy work (e.g. the policy WG).

Some of the benefits of splitting them include:

- Because all filter information is separate, the
  manager can inspect the filter and understand whether
  to download the policy to an agent
  (i.e. "this policy will never execute on this system so
   I don't need to download it")
- Because filter information is separate, the agent can schedule
  filter evaluation separately from action evaluation.
  If I have 50,000 circuits, I might not want to evaluate the
  filter as often as I want to assert the action. Conversely, if
  the action is more costly than the filter, I might want the
  filter evaluated more frequently (to more quickly discover new
  elements to which to policy should apply)
- The filter expression is known to be idempotent, information
  that both manager and agent can use for optimization.
- It is easier to re-use filter and action expressions when they
  are separate. Imagine a policy authoring environment that lets
  you drag an icon representing "all ethernet access ports" and
  associate it with an icon representing "mark voice with CP 35".

The split is a fundamental part of the architecture so I expect
we can keep coming up with other existing benefits to add to the
list.

> I also expect
> in a single file which they push to the managed devices. 

This is true only if they were trying to build policy by hand on top of
a scripting system. We are building them an infrastructure (our
standard plus the applications that will stem from it) that will
make it more convenient than doing it by hand.

> I don't see

I'm not sure if you understand the current document. There's no
tokenization or reassembly of code. Each filter or action 
expression contains everything necessary to do its job.

> policy-enabled managed devices.

Our execution environment is much different than that for the 
Script MIB. While the script MIB is for generic scripted
applications, the PM MIB execution environment is purpose-built
for processing policy expressions. We require facilities
that aren't in the script mib such as:

- Our filter expressions are called once for each element.
- Our action expressions are called once for each element that 
  passed the filter.
- Our expressions expect to be passed the identity of the 
  "current element" as a parameter.
- Our environment periodically re-runs expressions

The script MIB also allows things we need to disallow
- Ad-hoc invocation of expressions
- multiple languages
- download of script by http
- Trap sent on every error
- ... (would require thorough analysis to complete this list)

The Script MIB is a great generic scripting mechanism but it
would be very awkward to use for our application because the
differences are greater than the similarities.

Steve

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 06 Sep 2000 14:10:53 +0200

Steve,

> > left to do is to reach agreement on a policy language and we are done
...
> for processing policy expressions. 

If the Script MIB is built for generic scripts it runs also for policy
"scripts".
And I don`t see that they are really different.

> - Ad-hoc invocation of expressions

Allows to include the policy language you are developing.

> - download of script by http

Could be a nice idea to download policies via http, isn`t it?

> differences are greater than the similarities.

I do not aggree with that statement.

Marcus

-- 

Dr. Marcus Brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: Harrie Hazewinkel <[email-masked]>
Date: Wed, 06 Sep 2000 09:33:48 -0700

HI all,

This is just an update on the situation with respect to
the DiffPolicy-MIB module. The third work item of this
WG.

At the last IETF it was discussed that major changes
will be done to the DiffServ-MIB module. More precise,
the indexing scheme will change. These will be
defined in next release of the DiffServ-MIB draft.

The effect on the DiffPolicy-MIB module will be that the
MIB module will change according to the indexing scheme
changes of the DiffServ MIB module. How it all exactly
happens, I would like to wait until the DiffServ MIB
module is published. They are close to publishing the
new draft.

Hope to have you all informed of the situation.

Cheers,
Harrie
0- Harrie Hazewinkel ---------------------------------------0
 mailto:[email-masked]            phone:+1-415-536-5221
0-----------------------------------------------------------0

---

From: Jon Saperia <[email-masked]>
Date: Wed, 06 Sep 2000 15:12:34 -0400

> module is published. They are close to publishing the

Thanks very much for the update. I am confused. I thought the last version
recently published would have the changes. I take it that there is another
on the way fairly soon.

Correct?

/jon

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 06 Sep 2000 15:38:29 -0400

Please reply inline.  -- Kwok --

>recently published would have the changes. I take it that there is another

Jon, I think the last version you are mentioning is DiffServ MIB-04.  Which
Joel asked
for a new table in the Pittsburgh DiffServ WG session.  DiffServ MIB-05
contains
that table, called DataPathTable.  This will be published on the Diff Serv
list shortly.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Sep 2000 18:35:55 +0200

>>>>> Steve Waldbusser writes:

Steve> I've been collecting and writing examples and haven't yet come
Steve> up with any impracticalities, much less a class of policy
Steve> scenarios that aren't handled by this architecture.

Steve> The split between filter (aka condition) and action follows
Steve> existing practice in other policy work (e.g. the policy WG).

I am not arguing against the conceptual distinction between a policy
condition (or policy filter) and a policy action. This is fine as long
as we all believe in the rule-based approach, which I take as a given
at this point in time.

[One can question the rule based approach itself, but this really
falls out of the scope I think. ;-]

I am questioning whether it is useful to represent this distinction in
the MIB. This WG is using a lanuage based approach to describe policy
filters and policy actions. It is possible to

(a) represent each atomic statement of this language as single MIB
    objects

(b) represent filters (conditions) and actions as single MIB objects

(c) represent a rule (composed of a filter and actions) as single
    MIB objects

(d) represent sets of rules (a policy group) as single MIB objects

I believe that sets of related policy rules (a policy group) form a
high-level control construct and that it is useful to transfer and
invoke them as single logical entities. In this model, the execution
environment is required to take such a high-level control construct
and to transform it into an internal representation that can be
executed effectively. I also believe that policy rule changes do not
happen in real-time. So any attempts to introduce a "peek and poke"
capability to modify policy rule sets on the fly seem wasted to me.

Steve> Some of the benefits of splitting them include:

Steve> - Because all filter information is separate, the manager can
Steve> inspect the filter and understand whether to download the
Steve> policy to an agent (i.e. "this policy will never execute on
Steve> this system so I don't need to download it") 

But the same thing can be done by letting the manager generate a
policy rule script which is specific to the capabilities of the
agent. I don't think there is any significant advantage here for this
optimization from the granularity of the MIB objects.

Steve> - Because filter information is separate, the agent can
Steve> schedule filter evaluation separately from action evaluation.
Steve> If I have 50,000 circuits, I might not want to evaluate the
Steve> filter as often as I want to assert the action. Conversely, if
Steve> the action is more costly than the filter, I might want the
Steve> filter evaluated more frequently (to more quickly discover new
Steve> elements to which to policy should apply)

An execution environment can easily extract the filters from a policy
script and do what you describe above. The agent has to do some
parsing anyway and being capable to extract filters won't add much
overhead. In fact, since the agent does not forced to export the
internal representation as (writable) MIB objects, you will actually
be able to reduce significantly the complexity of the agent.

Steve> - The filter expression is known to be idempotent, information
Steve> that both manager and agent can use for optimization.  

I don't think this has any implications on the granularity with which
you communicate policy rules between the policy manager and an agent.

Steve> - It is easier to re-use filter and action expressions when
Steve> they are separate. Imagine a policy authoring environment that
Steve> lets you drag an icon representing "all ethernet access ports"
Steve> and associate it with an icon representing "mark voice with CP
Steve> 35".

I do not see why this is so much simpler. In the current approach, the
manager needs to search for a suitable filter. If it finds one, you
add another action to it. If there is no suitable filter, you create
one and add a action to it. The same will happen if your policy script
language combines filters and actions. The difference is only that the
current approach may do the addition by editing the MIB in place while
the proposed approach will push a new policy group to the agent.

I believe that this is actually a plus since I do not believe that a
decent policy tool will modify any systems while a human edits policy
rules. In fact, I believe that all the drag & drop policy editing is
finished before you hit the install button in your policy tool (at
which point in time the policy tool does some conflict detection and
optimization and pushes the policies into the devices, potentially
adapted to the device capabilities).

Steve> The split is a fundamental part of the architecture so I expect
Steve> we can keep coming up with other existing benefits to add to
Steve> the list.

As I said before, I do not argue against the policy filter / policy
action concept here. (BTW, what precisely is the difference between a
policy filter and a policy condition? Why does this WG not use the
commonly used term policy condition?) I am arguing that the choosen
granularity with which you communicate policy rules between a policy
manager and a policy-aware agent is wrong.

>> I also expect that network operators will prefer to write and
>> handle sets of logically related policy rules in a single language
>> and to store them in a single file which they push to the managed
>> devices.

Steve> This is true only if they were trying to build policy by hand
Steve> on top of a scripting system. We are building them an
Steve> infrastructure (our standard plus the applications that will
Steve> stem from it) that will make it more convenient than doing it
Steve> by hand.

You may have a nice GUI policy tool. But even then, having this tool
generate a nice readable format in a human readable policy scripting
language will be valuable - and if it is for debugging purposes only.

Steve> Our execution environment is much different than that for the
Steve> Script MIB. While the script MIB is for generic scripted
Steve> applications, the PM MIB execution environment is purpose-built
Steve> for processing policy expressions. We require facilities that
Steve> aren't in the script mib such as:

Steve> - Our filter expressions are called once for each element.  -
Steve> Our action expressions are called once for each element that
Steve> passed the filter.  - Our expressions expect to be passed the
Steve> identity of the "current element" as a parameter.  - Our
Steve> environment periodically re-runs expressions

The script MIB does (on purpose) not define any particular execution
environment. This WG can of course define a policy scripting language
execution environment which takes a policy script and executes it with
all the features you have listed above. The fact that the script MIB
is generic makes it applicable to this (and other) problem domain.

Steve> The script MIB also allows things we need to disallow - Ad-hoc
Steve> invocation of expressions - multiple languages - download of
Steve> script by http - Trap sent on every error - ... (would require
Steve> thorough analysis to complete this list)

Ad-hoc invocation of policy groups does not seem like a bad thing to
me. Multiple languages is no issue since this WG can standardize a
policy scripting language for interoperability. Download from URLs
(not only HTTP) will be very convenient, especially when policies
become larger. Getting notifications on errors is useful. And you can
turn them off by some standard SNMPv3 configuration if you really do
not care if your policy system goes crazy.

Steve> The Script MIB is a great generic scripting mechanism but it
Steve> would be very awkward to use for our application because the
Steve> differences are greater than the similarities.

Which I do not believe. 

Once again, the key difference is at which granularity you communicate
policy rules between the policy management tool and the policy
execution environment. I have listed four alternatives at the
beginning of this email. I believe that only (d) makes sense for any
system of serious size and complexity. (c) may still work for networks
which only require a few policy rules - that is basically new networks
that still have a consistent design.

/js

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 12 Sep 2000 03:46:04 -0700

Juergen Schoenwaelder wrote:
> condition (or policy filter) and a policy action.

> (d) represent sets of rules (a policy group) as single MIB objects

We agree that policy filters and actions are conceptually different.
Further, I have noted that filters have different syntax and semantics
than actions (e.g. filter syntax does not include SET operators but
action syntax does; filter code is executed on all elements while action
code is executed on matching elements; filter execution frequency is
controlled by filterMaxLatency, while action execution frequency is
controlled by actionMaxLatency; etc.).

The rest is simply Modeling 101:

We define different concepts as different objects. Then we structure
them to show the appropriate relationships between the concepts/objects.
We shouldn't encode filter and action into the same object for the same
reason that we shouldn't encode policyStatus as a decimal number at the
end of the policyAction string. We outlawed OPAQUE syntax years ago
because of similar bad modeling practices it was abused for.

To reiterate, the first step in Modeling 101 is to identify the
component objects. The second is to model the relationships between
them. One relationship we've had concensus on (here and in other groups)
is the association of a filter and an action which we accomplish by
having them as columns in the same table.

You raise another potential relationship: multiple policies being
associated together into a policy group. What is the best way to
represent such a relationship? It depends on the nature of the
association and the type of "service" that you want to offer by the
association. Unfortunately, the nature of policy groups is not
completely understood today so it is hard to tell today what the best
model will be, but I hardly believe that simply stuffing them all
together is sufficient.

We've already been discussing a counter example:

    Imagine two policies:
        1. if (diffServCapable) then (configureDiffServ)
        2. if (802Capable) then (configure802)

    One service that has been suggested for policy groups is
    to express that policy 1 and policy 2 are related such that
    at most one of them will execute. In other words, we need
    to arbitrate what will happen when diffServ and 802 are
    both present (only 1 should be configured). In order to 
    fully model this relationship, you need to specify which
    one wins in case of a tie (e.g. priority/precedence). 
    Simply putting them in the same object doesn't express
    priority. This is best modeled by a priority value
    attached to each policy. In other words we would need:
       policyFilter
       policyAction
       policyGroup
       policyPrecedence (priority within group)
 
    The point is that stuffing them into one MIB object doesn't
    meet the requirements (it doesn't encode priority) and was
    bad modelling practice because it didn't anticipate the
    full requirements for policy groups.

> be able to reduce significantly the complexity of the agent.

We agree that filters and actions are separate. We're simply debating
what's the best delimiter between filter and action. I'd rather use the
existing facilities of the SNMP protocol engine to delimit objects
instead of writing code that parses an octet string looking for internal
delimiters. Using existing facilities results in 2 MIB objects rather
than 1, but results in less code overall because each MIB object is
simpler.

> adapted to the device capabilities).

Filters and actions are separate for modeling reasons, the separation
was not added to allow interactive editing. Personally, I don't know 
if changing a running policy is a good idea.

> language will be valuable - and if it is for debugging purposes only.

I agree completely - that's why I've been a promoter of the
language-based approach. Network operators use scripting (e.g. Perl) as
a tool of choice in managing their network.

> is generic makes it applicable to this (and other) problem domain.

Maybe the script MIB isn't as generic as I maintained. In the script
MIB, scripts are started (only) by writing a value to smLaunchStart. In
the policy management MIB we need scripts to re-execute automatically
based on timer events.

Further, the Script MIB dictates that scripts are passed the contents of
the smLaunchArgument object. In the PM MIB, we need scripts to be passed
the index of "this element". I can't imagine a reading of the script MIB
that would allow such a change of semantics. I also can't imagine that
such a position would be healthy to the future of the script MIB.

You say that the script MIB doesn't define an execution environment -
that may be true for language and libraries, but it definitely not true
for scheduling and parameter passing and other areas where it is very
explicit and DIFFERENT than the Policy Management MIB requirements.

Meta issue: In order to make this work we would have to say that the
semantics of a registered MIB object are not forever defined by the
description clause, but can change in unanticipated ways based on what
other MIB object is "pointing" to them. This seems to shake the
foundation of our SMI framework.

> that still have a consistent design.

We agree that policy groups will be required for complex policies on
complex networks. However, you're confusing the encoding of policies
with the modeling of policy relationships. Encoding two things into one
object has never been the desirable way of modeling a relationship
between them.

Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Sep 2000 18:22:15 +0200

>>>>> Steve Waldbusser writes:

Steve> The rest is simply Modeling 101:

Steve> We define different concepts as different objects. Then we
Steve> structure them to show the appropriate relationships between
Steve> the concepts/objects.  We shouldn't encode filter and action
Steve> into the same object for the same reason that we shouldn't
Steve> encode policyStatus as a decimal number at the end of the
Steve> policyAction string. We outlawed OPAQUE syntax years ago
Steve> because of similar bad modeling practices it was abused for.

This is where we obviously have some disagreement. I think we are
talking in the policy management context about high-level control
programs that we want to distribute, invoke and execute. We are not
talking about fine grained little objects for network element
monitoring. The modeling practices for network element monitoring
simply do not fit the requirements for high-level network control
programming.

Whenever I write a piece of (control) software, I leave it to the
execution environment to tokenize the input into an internal format
that is efficient to execute. I do not expect to be able to tweak this
internal format. In fact, I am happy with any optimizations the
executing engine is able to make. Policy control rules are for me just
another high-level control language and I think that this WG needs to
discuss which level of granularity makes sense for distributing
scripts written in this language to policy-aware network elements. I
am seriously concerned that very fine-grained granularity adds
considerable complexity without any clear benefits.

Steve> The point is that stuffing them into one MIB object doesn't
Steve> meet the requirements (it doesn't encode priority) and was bad
Steve> modelling practice because it didn't anticipate the full
Steve> requirements for policy groups.

I do not agree. I can easily associate a priority to the policy rule
in the language itself, e.g.

    on (condition) do
      action1;
      action2;
    with priority n;

It all boils down to get the policy scripting language definition
right. We want it to be flexible and efficient and it should run in
relatively resource constraint environments. I believe that this WG
should spend all its resources to get the language right rather than
reinventing wheels that do already exist (both as specifications and
actual implementations).

Steve> We agree that filters and actions are separate. We're simply
Steve> debating what's the best delimiter between filter and
Steve> action. I'd rather use the existing facilities of the SNMP
Steve> protocol engine to delimit objects instead of writing code that
Steve> parses an octet string looking for internal delimiters. Using
Steve> existing facilities results in 2 MIB objects rather than 1, but
Steve> results in less code overall because each MIB object is
Steve> simpler.

Which I believe is not true if you talk about high-level control
programs. I still prefer to write my code in C, C++, Java, <fill in
your favourite language here> and to let the execution environment
turn it into something that executes efficiently. The parsing is a
one-time activity when you install a policy script and won't make a
big difference compared to the overhead of actually evaluating the
filter conditions regularly. Even the MIB objects currently proposed
require some amount of parsing on the agent side. (To be consequent in
your reasoning, you would have to turn an expression into a tree
representation and download this as a set of MIB objects. ;-)

Steve> Maybe the script MIB isn't as generic as I maintained. In the
Steve> script MIB, scripts are started (only) by writing a value to
Steve> smLaunchStart. In the policy management MIB we need scripts to
Steve> re-execute automatically based on timer events.

You can use the scheduling MIB to start scripts automatically based on
timer events. But even then, I would argue that fine-grained
evaluation of timed conditions is subject of the language runtime
system to be really efficient. The scheduling MIB should be used to
schedule the activation and deactivation of complete policy scripts
(aka policy groups in PCIM).

Steve> Further, the Script MIB dictates that scripts are passed the
Steve> contents of the smLaunchArgument object. In the PM MIB, we need
Steve> scripts to be passed the index of "this element". I can't
Steve> imagine a reading of the script MIB that would allow such a
Steve> change of semantics. I also can't imagine that such a position
Steve> would be healthy to the future of the script MIB.

I believe that this is not a problem since I propose to use the script
MIB only to distribute and activate/deactivate policy scripts that
contain several policy rules. I believe the timed evaluation of
conditions and the passing of condition context information to the
actions is the task of the language and its runtime system.

Steve> You say that the script MIB doesn't define an execution
Steve> environment - that may be true for language and libraries, but
Steve> it definitely not true for scheduling and parameter passing and
Steve> other areas where it is very explicit and DIFFERENT than the
Steve> Policy Management MIB requirements.

In the granularity I propose, the script MIB scheduling and parameter
passing mechanisms should work just fine.

Steve> Meta issue: In order to make this work we would have to say
Steve> that the semantics of a registered MIB object are not forever
Steve> defined by the description clause, but can change in
Steve> unanticipated ways based on what other MIB object is "pointing"
Steve> to them. This seems to shake the foundation of our SMI
Steve> framework.

I do not understand. Which registered MIB object are you talking
about?

Steve> We agree that policy groups will be required for complex
Steve> policies on complex networks. However, you're confusing the
Steve> encoding of policies with the modeling of policy
Steve> relationships. Encoding two things into one object has never
Steve> been the desirable way of modeling a relationship between them.

I believe that any programming language with conditional statements is
a viable counter argument to this statement. And I am not even
considering real rule based languages which I used back in those days
when expert systems were changing the world as policy systems do
today. ;-)

/js

---

From: Jon Saperia <[email-masked]>
Date: Tue, 12 Sep 2000 12:44:51 -0400

> simply do not fit the requirements for high-level network control

From my perspective, as an editor, not co-chair, I think there are important
differences in the semantics of the specific objects in the policy document.
I think this is what Steve was pointing out.

The status of a policy is not the status of what shows in the script mib
which talks about execution status. The status of a policy is semantically
much more complex and is not appropriately conveyed in the script mib
objects. The status of a policy could be overridden for example.
/jon

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Sep 2000 12:31:13 -0700

> >>>>> Steve Waldbusser writes:

I agree with Juergen's concerns about the SNMPCONF execution environment
and MIB design.  But I'm not sure I understand the execution flow,
so I'll review how I think it works:

1)  The agent and NMS populate the pmElementTypeRegTable, which specifies
    the static MIB sub-tree (pmElementTypeRegOIDPrefix object) that the
    agent will iterate through, for each element type.
   
2a) If the pmPolicyCalender object is not used, then a pmPolicyFilter
    is invoked in an implementation-specific manner. There is no obvious
    linkage between an individual pmPolicyEntry and the pmElementTypeRegTable,
    but it appears that:
       - a given pmPolicyFilter may only pertain to a single element type
       - the agent must maintain a dynamic mapping between all elements
         and all policies, which may be non-trivial. 
       - both the pmPolicyFilter and pmPolicyAction scripts must assume
         that the appropriate pmElementTypeRegOIDPrefix will be used for
         iteration, because they have no verification. Only the instance
         portion of the complete OID is passed in the 'dollar vars'.

2b) I have no idea how the iteration model works for calendar based policies,
    i.e., which value of pmElementTypeRegOIDPrefix the agent will use when
    the Scheduling MIB invokes the associated (pmPolicyFilter or pmPolicyAction?)
    script.

3) After determining that some elements have 'changed', or perhaps just running
   continuously, within a polling interval specified by the lower bound
   of all pmPolicyFilterMaxLatency objects, the agent selects a pmPolicyFilter
   script and a pmElementTypeRegOIDPrefix. 

4) For each instance in the specified sub-tree (in the same context as the PM MIB 
   I presume) the pmPolicyFilter is executed. The filter logic examines the instance
   info (in the dollar vars), calls accessor functions, makes arithmetic and logical
   calculations, and determines if the implied MIB object is 'selected' by this
   policy. There is no stateful data at all - just the implied MIB root and the
   dollar vars that comprise the 'current' MIB object.

   It's not clear (maybe implementation-specific) if the agent should internally 
   save the selected instances until the end of 'policy invocation', or if it should
   call the associated pmPolicyAction as each selected instance is identified.
   I'll assume the former, although there are will be some policy scripts which
   cannot be written without this unspecified choice impacting the outcome.

5) For each value in the selected instance list (in no assigned order?), 
   the agent invokes the pmPolicyAction script. Again, there is no state
   and no info passed from the policy filter to the policy action.

Given this understanding of the execution environment, I agree with Juergen
that the separation of conditions and actions is less than useful. 

I'll use his example:

     on (condition) do
        action1;
        action2;
     with priority n;

The MIB does not provide any possibility of script sharing, so the (condition)
and (action1;action2) logic is statically and tightly coupled. Separating this logic
into 2 scripts will cause high coupling and low cohesion, which is the
opposite of proper programming practices. This is also confusing.
Most of the execution order and policy selection details are unspecified,
and yet, policy filters must run separately from policy actions. 

It would be better to explicitly define the iteration behavior such
that a selected instance is acted upon at once (inline), rather than deferred
for later processing. This is the 'natural' behavior implied by the
well understood logic example above. A single script is much more readable
and manageable.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Sep 2000 09:26:41 +0200

>>>>> Jon Saperia writes:

Jon> From my perspective, as an editor, not co-chair, I think there
Jon> are important differences in the semantics of the specific
Jon> objects in the policy document.  I think this is what Steve was
Jon> pointing out.

Jon> The status of a policy is not the status of what shows in the
Jon> script mib which talks about execution status. The status of a
Jon> policy is semantically much more complex and is not appropriately
Jon> conveyed in the script mib objects. The status of a policy could
Jon> be overridden for example.

Not sure I understand what you are talking about here. Are you talking
about policy groups, policy rules, policy conditions and actions when
you use the term policy? And what does it mean to overwrite the
status?

You are probably refering to pmTrackingPolicyToElementStatus and
pmTrackingElementToPolicyStatus (since these are the only status
objects I could find that are not RowStatus). In this case, you talk
about the binding of policy conditions to the set of elements (or
targets). I believe this can be handled appropriately in a pure
language based approach as well. And even if this WG needs to
introduce new tables to provide additional interfaces, I still believe
that working from existing MIBs which have been specified and
implemented is worth to be seriously considered.

/js

---

From: Jon Saperia <[email-masked]>
Date: Wed, 13 Sep 2000 08:06:56 -0400

> you use the term policy? And what does it mean to overwrite the

What I mean is the state of the policy. For example you will have seen
postings leading up to the last IETF where a policy can be overridden by the
CLI for example or a policy can be superseded by another. Thus the answer to
your question above is policy as an entry in the Policy Table and policy in
the tables you reference below.  To the best of what I know, the SNMPCONF
work has not yet explicitly used the term 'condition'.
> language based approach as well. And even if this WG needs to

Your term, policy condition here is not clear to me. Additionally we do
width to have the state information visible via MIB Objects as described
above.

> introduce new tables to provide additional interfaces, I still believe

Not sure which WG you mean here?
> implemented is worth to be seriously considered.

I agree when there is a good fit like I think there is in the Schedule MIB
Module. I do not think the script mib as anywhere near as good a fit.

/jon