Subject: Re: snmpconf General Functional Questions

From: Steve Waldbusser <[email-masked]>
Date: Tue, 04 Jul 2000 01:43:53 -0700

Comments inline:

> > Also, I don't believe in having these bits set as side-effects of setting an
> > SNMP variable. Reasons include:
> > 1) An SNMP set for a variable that is under policy control doesn't communicate
> > the following necessary sentiment: "While I know that this variable is under
> > policy control, I intend to override that anyway". In other words, the SNMP
> > engine can't tell whether the request intended to override policy or was an
> > innocent mistake. It would be hard to say that we're enforcing policy when any
> > request has carte-blanche to get an exemption.
>
> The intent of the user, innocent or not does not matter here. What matters
> is that a value that was provisioned via the Policy module was changed by
> something other than the policy module.

But what happened to the policy system's enforcement responsibility? Getting the
network set up in a consistent way is only half the problem. From that point entropy
takes over and makes the configuration less and less consistent as more and more
devices get tweaked. Unfortunately, in my experience, humans are responsible for the
large majority of this "entropy": untrained technicians, sloppy engineers, people
from outside organizations, etc are all responsible for making configuration changes
that defy the network manager's wishes. It must be the responsibility of the policy
system to enforce the network manager's high-level wishes, while still allowing a
fireighting technician to override when absolutely necessary.

Another question this raises is why would we have the policyAction execute
repetitively if it will never end up changing any variables back into conformance
with the policy? The only time it is allowed to enforce the policy is when the
network element is already in conformance with the policy?

> Certainly a well run system would
> not give carte-blanche to any user to make modifications. This is one of the
> reasons why user based security can be helpful in policy management.

Security is orthogonal to this discussion. If I am a highly-priveleged Unix admin I
don't spend my day reading my email and writing documents while logged in as root. I
spend most of my time with my privileges disabled so that I won't make a mistake and
wreck the system. I enable my priveleges only when I need to use them so that I
don't break my own "policy". In other words, even privileged users need a policy
system to make sure that they don't make mistakes.

> > 2) Would require changing instrumentation for all MIBs.
>
> I do not believe this is so since it is the policy system that will detect
> this change, not the instance specific instrumentation.

This breaks down to:
        if (variable == 7) then
            variable = 7;
        else
            skip cuz somebody changed it;

In other words, a no-op.

Steve

---

From: Jon Saperia <[email-masked]>
Date: Tue, 04 Jul 2000 09:11:47 -0400

on 07/04/2000 4:43 AM, Steve Waldbusser at [email-masked] wrote:

>>> SNMP variable. Reasons include: 1) An SNMP set for a variable that is under
>>> policy control doesn't communicate the following necessary sentiment: "While
>>> I know that this variable is under policy control, I intend to override that
>>> anyway". In other words, the SNMP engine can't tell whether the request
>>> intended to override policy or was an innocent mistake. It would be hard to
>>> say that we're enforcing policy when any request has carte-blanche to get an
>>> exemption.
>>> 
>> The intent of the user, innocent or not does not matter here. What matters is
>> that a value that was provisioned via the Policy module was changed by
> But what happened to the policy system's enforcement responsibility? Getting
> the network set up in a consistent way is only half the problem. From that
> point entropy takes over and makes the configuration less and less consistent
> as more and more devices get tweaked. Unfortunately, in my experience, humans
> are responsible for the large majority of this "entropy": untrained
> technicians, sloppy engineers, people from outside organizations, etc are all
> responsible for making configuration changes that defy the network manager's
> wishes. It must be the responsibility of the policy system to enforce the
> network manager's high-level wishes, while still allowing a fireighting
> technician to override when absolutely necessary.

It seems like we want the same thing. Consistent control by the policy
system while allowing for human override. I agree that allowing the facility
for override might have the entropy effect. Nevertheless, we must do it
since that is how operators will want things done. All I am suggesting is
that when a change to a policy controlled element is made, that the policy
system can know about it. In fact this could be used by management systems
to produce exception reports. Lets put the extra value I described in the
object you suggested.

> repetitively if it will never end up changing any variables back into
> conformance with the policy? The only time it is allowed to enforce the policy
> is when the network element is already in conformance with the policy?

I did not suggest having the policy action execute for the reason you state.
We do not want it overriding the human override. It is the evaluation (one
of the means I suggested) of the filter that will have to be done
repetitively independent of whether we do this feature or not. Otherwise how
will we know if a new policy element has come into existence that should
have a policy action taken. I did suggest that even the element evaluation
might not be necessary for this function since the system will already know
what elements are associated with a policy. That will be in the agent
anyway.
> 
>> Certainly a well run system would not give carte-blanche to any user to make
>> modifications. This is one of the reasons why user based security can be
>> helpful in policy management.
>> 
> Security is orthogonal to this discussion. If I am a highly-priveleged Unix
> admin I don't spend my day reading my email and writing documents while logged
> in as root. I spend most of my time with my privileges disabled so that I
> won't make a mistake and wreck the system. I enable my priveleges only when I
> need to use them so that > I don't break my own "policy". In other words, even
> privileged users need a policy system to make sure that they don't make
> mistakes.

I agree with you here again. I am saying that only those that can su to root
can make the change. My point was that permissions based on who you are can
help here.
> This breaks down to: if (variable == 7) then variable = 7; else skip cuz
> somebody changed it;
> 
> In other words, a no-op.
> 
> 
No, if the value is not 7 do not reset. The idea is to reflect that the
variable has been changed (not necessary to report the changed value since
that can be obtained directly via a get from the management system). I think
the logic would be:

    If first evaluation of policy (for each element in a policy)
        set value
    for each following application
        if value is equal default then continue, else
           if value does not equal default and
           pmTrackingElementToPolicyStatus
            is modified(3) - do not change (no-op)
        else,
           reset value and send notification.

How is this?

/jon

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 05 Jul 2000 11:20:43 -0700

>            reset value and send notification.

It all depends on how you set the value to modified(3). If it is done
implicitely
when the policy engine notices that the value has changed, then the
entire algorithm
breaks down to the no-op I described (i.e.: any time you notice a
variable has
changed, set the do-not-touch bit. Stated another way: only enforce
correct
configuration of variables that have correct configuration.)

However, if the modified(3) bit is set explicitely through an SNMP set
(or CLI
command), then the algorithm makes some sense.

It seems we have three models to choose from:

1. Allow no overrides
(Most conservative)
In this option, if the policy is causing an operational problem in the
field, the
policy must be re-written at headquarters and re-distributed, which will
delay
problem resolution.

2. Any change causes an implicit override
(Most liberal)
I claim that this becomes a no-op. However, even if it worked as
desired, it seems
too liberal to let anybody override policy even when they might not
realize that
they are overriding it or without understanding the implications of
overriding the
policies they are overriding.

3. Explicit override capability
(Middle Ground)
Allows quick resolution of a problem and then subsequent re-engineering
of the
policy to anticipate the new situation. Policy will still be enforced in
the
following situations:
    - Untrained technician misconfigures something
    - Service provider or vendor tech-support script (or human) makes
changes that
don't follow customer's policy
    - Highly skilled network engineer makes a mistake
    - etc.

I suggest that the mddle ground is the right way to go. Operators can
still tweak
(with SNMP or CLI) variables not under policy control. And operators can
still tweak
variables that are under policy control but only after disabling the
controlling
policy (with SNMP or CLI).

Steve

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 05 Jul 2000 18:28:59 -0400

The problem with I have with your proposal is two fold:
A) Your objection to alternative 2 (roughly what is on the table, stated 
somewhat oddly) is in your concern about whether someone should be able to 
override policy.  If they have the access to write directly to the 
variable, then they should be able to do so.  They should not have to 
understand the policy tables and find the correct place to markt "I mean 
this"  If they are making the change, they mean it.

2) If you require people to explicitly mark that they want to override 
policy, they will forget.  They will be surprised and confused when the 
system does things that they do not expect.

Fundementally, you are arguing that putting an object under policy control 
should remove it from SNMP control unless it is explicitly removed from 
policy control first.  I am arguing that the act of directly setting the 
attribute seems to me to be quite clear enough.

You raise the red herring of "then why reevaluate policy".  The answer is 
that there are many ways that reality can change, not just by changing an 
SNMP variable.  Some of these are equivalent to such sets (CLI is I agree 
still manual change).  But cards fail.  VCs come up.  peerings start and 
stop.  Cards get inserted and removed. These things may have effects on the 
policy decision.  Probably teh easiest case to understand is when a 
customer is added to a port.  Yes, this results in direct SNMP sets.  But 
these occur before the policy has manipulated the port.  So they don't 
prevent policy from taking effect.  Then the policy system decides what the 
effect of these (role, etc) attribute settings should be.  Another related 
example is where the role table is changed.  That does not change any 
object directly effected by policy, and therefore does not remove anything 
from policy.  The policy reevaluation will take these changes into account.

Yours,
Joel

---

From: Jon Saperia <[email-masked]>
Date: Thu, 06 Jul 2000 06:45:56 -0400

> this"  If they are making the change, they mean it.

Obviously I agree with Joel's assessment.

An item we have yet to discuss is how often policies are evaluated on a
system. The need for this is exists independently of the current discussion.

/jon

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 06 Jul 2000 11:25:54 -0700

"Joel M. Halpern" wrote:
> 
> If they have the access to write directly to the

I believe the main constituency for policy-based management is the
network 
architect/engineer who is sick and tired of the ad-hoc nonsense that 
continuously creates problems. Maybe rigorous training of everybody who 
touches the network could solve this problem, but with staff turnover
and 
the constant stream of vendor staff, consultants and service provider
staff 
in and out the door, this is impossible.

Policy-based management can help the network architect make everything
consistent.

Now you say "if they are making the change, they mean it". Well, when an 
entry-level technician makes an out-of-policy change, two things are
true:
1. The technician meant it
2. The network architect wants to bash his brains in with a 2x4. 
   The architect DIDN'T MEAN IT.

Thus, there are 2 constituencies. One is tactically focused and one is 
strategically focused. 

The tactical constituency is the only one that has been represented so
far 
WRT SNMP configuration. We are here to provide a tool for the strategic 
constituency that lets them enforce the strategic goals. We can't let 
ad-hoc SETs always win or we haven't provided any enforcement
capability.

So far I've only been talking about the case where the technician "meant
it".
What about the case where nobody meant it?:
- I made a mistake
- I didn't know what I was doing
- I ran an old script, I didn't realise what it did.
...

> system does things that they do not expect.

This is better than having the network architect be surprised and
confused.

Yes, sometimes they will forget. They will have to learn. (An aside: it
would 
be great if we could figure out how to give them more instant feedback
without 
requiring changes to existing SNMP instrumentation).

Sometimes the architect and the tech mean different things. Sometimes
the 
architect is wrong and sometimes the tech is wrong. We can't assume that 
either is always right. The middle ground is to require that the tech
take 
special action for those things under policy control - to acknowledge
that 
what they are about to do is a conscious decision to violate the policy.

No more unreasonable than "Delete all files. Are you sure?"

Steve

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 06 Jul 2000 11:43:51 -0700

"Joel M. Halpern" wrote:
> policy decision.

But early in this discussion it was proposed that the way the policy
engine
learns that a variable has been modified is by comparing with the policy
value and when it notices that it is different, marking it as "don't
touch".

This was so that we didn't require changes to existing SNMP
instrumentation.

Thus the policy engine has no way to differentiate between changes due
to
SNMP, CLI, or simply state changes on the managed system - the net
effect
is that any change from any source locks policy out from fixing the
change.

Steve

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 06 Jul 2000 15:47:31 -0400

I had overlooked that (background change detection) proposal.  That would 
indeed produce the results you propose.  And was not what I was 
expecting.  I had assumed that one would indeed modify some internal 
mechanisms so taht if a change was being made to a variable which had been 
modified by policy, that the "don't touch" flag would get set.

I would observe that even if that were the case, one would still have 
policy effect on new things, and policy effect when collatoral conditionals 
were changed.

Yours,
Joel M. Halpern

Also, to respond to the note expressing concern about the interaction 
between the Network Architect and the Field Engineer, if the systems folks 
have decided that the field engineer should not be able to change certain 
things, don't given that engineer permission to change them.  In my 
discussions with ISPs they have confirmed that it is normal and desirable 
for field engineers to change things, and that preventing them from doing 
so would be a bad thing.

At 11:43 AM 7/6/00 -0700, Steve Waldbusser <[email-masked]> wrote:
>But early in this discussion it was proposed that the way the policy engine

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 06 Jul 2000 14:23:24 -0700

I'm not suggesting that the field engineer be prevented from making
changes. In fact, I was the original proposer for an override
capability as well as operational/debugging tools for field 
engineers - they are all in the draft today.

All I want is for the field engineer to have to do something special
to override a policy. Shouldn't he at least know that he has done
something significant? Wouldn't it be good if he was thus encouraged
to think twice? Wouldn't it be good if he was encouraged to mention it
to the network architect? ("hey, I needed to disable the blah policy
on trunk 7 last night because it was interacting poorly with the
backup circuit").

My proposal is that he issue 2 commands rather than one. The first
disables the policy on the interface and the second is a normal 
SNMP set that makes the change.

Regards,
Steve

---

From: Jon Saperia <[email-masked]>
Date: Fri, 07 Jul 2000 09:07:25 -0400

on 07/06/2000 3:47 PM, Joel M. Halpern at [email-masked] wrote:

> mechanisms so that if a change was being made to a variable which had been

Yes. The modification of the internal mechanisms to which you refer, does
not imply that one would need to modify the low level instrumentation as
Steve suggests.

/jon

---

From: Jon Saperia <[email-masked]>
Date: Fri, 07 Jul 2000 09:07:09 -0400

> SNMP set that makes the change.

Steve, I am in agreement with your concern. I think we can accomplish this
without having to issue two commands though. You gave the example of not
running as 'root' to avoid making mistakes - most of us have learned that
lesson. My point is that the access/change of policy is an operational
policy (forgive the pun) decision. If a system is under policy control,
access to the MIB tree that contains everything except the policy objects,
should be quite restricted. The operator would then have to use the root
password to make the changes. This is analogous to 'su root' make all your
changes and exit. Your preference would be to have the person 'sudo change
1', 'sudo change2' etc. In our case the equivalent of the sudo is to make
the explicit something special you suggest.

I do not think either of the two approach we discuss is very bad since they
do allow for policy override, which is my primary concern. I think Joel said
it pretty well: 

> If they have the access to write directly to the variable, then they should be
> able to do so.  They should not have to understand the policy tables and find
> the correct place to markt "I mean this"  If they are making the change, they
> mean it.

/jon

---

From: Jon Saperia <[email-masked]>
Date: Fri, 07 Jul 2000 09:08:05 -0400

on 07/06/2000 2:25 PM, Steve Waldbusser at [email-masked] wrote:

> Sometimes the architect and the tech mean different things. Sometimes the
> either is always right. The middle ground is to require that the tech take
> special action for those things under policy control - to acknowledge that

My experience suggests that the concern that people have about inconsistent
policies that Steve is concerned with is valid. That does not outweigh the
valid concern that people have that they are able to make modifications to
'standard' policies for any reason any of us can think of and probably more
that we can not think of.

If a particular environment does not want to allow these modifications then
we have the mechanisms in the infrastructure to let the people who deploy
the system decide who can change what where.

I believe we must support the ability for users who have been authorized
(regardless of job title) to modify elements that are under policy control
and for the policy system to reflect this state. Lets put the modified(3)
value in.

/jon

---

From: David Harrington <[email-masked]>
Date: Fri, 07 Jul 2000 13:00:33 -0400

Hi,
comments inline

Steve Waldbusser wrote:
> to think twice? 

I am wondering about a feedback loop that would make it apparent to the
field engineer that a proposed change might have wide-ranging
implications to policy. 

A management application could analyze all the conditions that might be
affected by modifying a particular managed object, but this seems a
heavyweight solution, and it could be difficult to synchronize between
the application evaluation of the conditions, and the local evaluation
of the conditions, i.e. it may be much more difficult for the
application to determine affected instances.

Any suggestions on how to provide feedback - upon request - to the field
engineer about how many policies would be affected by changing a given
managed object, so he could determine the scale of the potential impact
on policy?

> Wouldn't it be good if he was encouraged to mention it

Should we provide some mechanism for standardizing notifications
advising of changes to objects that have been moved "out of policy"?
There are two purposes - to remind the field engineer that he made a
temporary change that should be reset, and to notify the architect that
somebody changed a value that is subsequently affecting policy. 

One approach could be to define a general policy-system-wide
notification control for periodically sending notifications as long as
each element is out of policy (notification per element or role). The
other is to provide an object associated with the "disable-this-policy"
object that controls the notification frequency related to reporting
this particular out-of-policy state. This would allow notifications to
be sent more frequently for important policies, and less frequently or
not at all for less important policy changes (although the field
engineer could prevent the architect from being notified). The third is
to depend on an application run by the architect to poll for all
out-of-policy indicators. This may be less reliable as a reminder
mechanism for the field engineer, since he'll need to remember to run
the report.

Is the third mechanism adequate? It certainly seems the simplest and
most backwards compatible.
If an engineer doesn't set the flag, and changes an object, he can
affect policy until the next re-evaluation. Assuming policy would reset
it before the architect checked it, the architect may never know that
the engineer made such a change, and that could have security and
reliability implications.
A notification sent to the architect could ensure that the architect
knows about the temporary policy change. Reliance on subsequent polling
would not.

> SNMP set that makes the change.

I concur that two commands may be better than automatic flag-setting,
since this would indicate intent to knowingly override. 

> > for field engineers to change things, and that preventing them from doing

Yes, configuring access control to prevent the field engineer from
changing things he shouldn't change is the first step. But even field
engineers can sabotage or abuse networks. I seems that it would be a
good thing to provide a standard mechanism for the architect to detect
what changes had transpired that forced policy-controlled elements to an
out-of-policy state.

I think there may be a need for an out-of-policy-state notification
(which the architect may choose to disable or filter via snmpv3) for
security/auditing purposes.

dbh
-- 
---
David Harrington            Network Management Architect Engineer
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 12 Jul 2000 12:23:30 -0700

All we're trying to do is make sure that when operators override a
policy that they do so deliberately. Access control is not the 
right tool to accomplish this.

If every operator has some more restrictive "root" priveleges and all
objects require this new privelege, nothing has changed from an access
control perspective and the same mistakes will be made.

And administering fine-grained access control to restrict only those
objects currently under policy control is a nightmare.

Steve

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Jul 2000 16:24:33 -0400

I think I understand what you are asking for.  If there were a way without 
excessive violence to the system to cause the "user" to get an error if he 
tried to change something that was under policy control without first 
removing it, I would at least be sympathetic to the two step process.

But, if we make it a two step process without such coupling, what happens 
is that the "user" makes a change, gets no error, and comes back later and 
discovers it is gone.  The "user" involved may well not be familiar with 
the policy mechanisms (someone else takes care of that).  He needs to make 
the change.  Forcing him to try to go through audit logs to figure out what 
happened is not sensible, particularly since network management is NOT this 
"user"s primary task.  he is a network engineer trying to fix a customer 
problem.
Whether this "user" is aware of the organizations desired policies is an 
organizational issue, not a protocol issue.  Making sure that there is 
someway to tell that he has overriden the policy (the flag that can be 
checked, and the logs to say who set the flag) is a protocol issue.

It may be that different organizations desire different behaviors in this 
regard.  Experience suggests to me however that the larger organizations 
which most want policy also have folks who need to make changes without 
significant hinderance.  And adding more options to the behavior does not 
seem like a good way out of this mess.  That will just give our users more 
ways to get confused.

Yours,
Joel M. Halpern

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 12 Jul 2000 21:23:38 -0700

> not imply that one would need to modify the low level instrumentation as

It requires a change to the snmp protocol engine and to the CLI command 
processor and any other engine that processes management commands. Such
a requirement is pretty unprecedented in MIB development.

Some other issues:

========
Before any varbinds are modified, the system must check to see if it is
under policy control (and thus would need to set the modified bit).
How does this engine know that a variable is under policy control?
This is difficult because it is hard to look at a policyAction script 
and figure out which variables it is controlling because there are
conditionals (if A then set B else set C) and because some or all of 
the script is opaque depending on how much work you want to do 
interpreting it.

Seems there are 2 strategies:

A. When a policyAction executes, save a list of OIDs it modified in a 
   master list of policy-controlled OIDs. Then we can check this list 
   before modifying any variable.

   Problems:
   - Lots of memory used storing long list of OIDs.
   - When a policy becomes inactive, hard to tell which OIDs to take
     out of list (can't simply re-execute policyAction because 
     conditionals might have changed).

B. When you want to know if a variable has been modified, inspect
   policyAction to see which variables are controlled.

   Problems:
   - Requires execution of script to evaluate conditionals
   - Interpreting script in bowels of snmp protocol engine is not a
     good architectural decision.

========
When a policy goes away on an element and then comes back, should the 
modified bit get cleared?
========
This doesn't work when the policy agent is a mid-level manager
(i.e.: where the agent that implements the Policy MIB enforces policy
in a subdomain through SNMP requests).
I think the modified bit proposal requires us to abandon that part of
our architecture.
========
So far I've talked about the requirement for the operator to think
twice before overriding a policy. The same is true when the tables
are turned: When an operator overrides a policy to firefight a
problem, the architect should think twice before returning it to
policy control. The problem is that without an explicit forceOff
state, the architect has no evidence that a modification to policy
was done deliberately.
========

I am opposed to the modified bit because it doesn't offer the right
services to network architects and operators alike and secondarily
because of the modeling and implementation problems it presents.

The current solution (the forceOff bit), allows operators to override
any policy that is causing operational difficulties (subject to
access control, of course). Meanwhile, the network architect can be
assured that policy overrides are applied only when necessary.

Steve

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 12 Jul 2000 21:53:51 -0700

> managed object, so he could determine the scale of the potential impact

If you walk the pmTrackingElementToPolicyTable, you can count the number
of policies applying to an element. Just walk the subtree for the
element you are investigating.

> somebody changed a value that is subsequently affecting policy.

Yes, I agree this is important. Judging by other messages, it seems that
others feel this way as well. I view this as self-documenting
exceptions.

Steve

---

From: Jon Saperia <[email-masked]>
Date: Thu, 13 Jul 2000 06:29:18 -0400

> a requirement is pretty unprecedented in MIB development.

No, you assume a particular method of implementation. There is nothing in
the realization of the software to access the instrumentation such as an
interface counter object that is necessarily cognizant of how the request
got there. I will agree that with some systems this is easier to do than
with others. Many newer systems are implemented in the way I describe.
There are ways or 'retrofitting' this into architectures that have the
isolated CLI and SNMP systems that would be most problematic. I am working
on one such system now. How one works on this problem is a function of how
the system is put together.

> assured that policy overrides are applied only when necessary.

Several of us has stated a different view of this. There is no objection to
the foreOff bit. That said, we do not believe it is correct in this case, to
try to do social engineering by making it more difficult to do policy
overrides.

/jon

---

From: Jon Saperia <[email-masked]>
Date: Wed, 26 Jul 2000 08:51:46 -0400

> others feel this way as well. I view this as self-documenting

This was part of the out of policy thread that I just responded to. In this
note Steve responded to a note by Dave Harrington. The issue here is
notifications. I think we are all in agreement on the importance of
notifications. Please see the BCP document recently posted. It has a new
section on policy overrides. It mentions notifications specifically. There
is also a general section in the document on notifications, but it probably
should be expanded. The relevant section is:

> 6.7 Changes to configuration outside of the policy system
> 
> A goal of SNMP-based policy management is to coexist with other
> forms what have historically been instance based management. The
> best example is command line interface. Here are some guidelines for
> handling these changes.
> 
> A notification should be sent whenever an out of policy control
> change is made to an element that is under the control of policy.
> This notification should include the policy that was changed, the
> instance of the element that was changed and the object and value
> that it was changed to.
>

---

From: Jon Saperia <[email-masked]>
Date: Wed, 26 Jul 2000 08:45:35 -0400

on 07/12/2000 4:24 PM, Joel M. Halpern at [email-masked] wrote:

> tried to change something that was under policy control without first removing
> it, I would at least be sympathetic to the two step process.
> 
> But, if we make it a two step process without such coupling, what happens is
> that the "user" makes a change, gets no error, and comes back later and
> discovers it is gone.  The "user" involved may well not be familiar with the
> policy mechanisms (someone else takes care of that).  He needs to make the
> change.  Forcing him to try to go through audit logs to figure out what
> problem. Whether this "user" is aware of the organizations desired policies is
> an organizational issue, not a protocol issue.  Making sure that there is
> regard.  Experience suggests to me however that the larger organizations which
> most want policy also have folks who need to make changes without significant
> hinderance.  And adding more options to the behavior does not seem like a good
> way out of this mess.  That will just give our users more ways to get
> confused.

In preparing for the upcoming meeting, I see that there were some notes from
Steve Waldbusser and Joel that I had not properly responded to. I choose to
respond to this note since I think Joel summarizes the issue well.

The issue we have had is that some of us do not want the person who needs to
override a policy on an element to have to know which object to set in the
Policy MIB Module and thus a lot of details not relevant to the operational
task at hand. Steve wanted to have an explicit object to set to cause people
to know that they are overriding a policy also a good goal.

I do see a way that a CLI could be implemented such that it could ask a user
to 'confirm' their action if the action includes changing the value of an
element under policy control. This would be a implementation detail not part
of the protocol. Obviously SNMP-based managers can do even more. I still
think it would be best not to require the user to have to write a specific
SNMP object to override a policy.

I am sure we will have some fun with this at the meeting :-)
/jon