Subject: Re: snmpconf General Functional Questions

From: Matt White <[email-masked]>
Date: Thu, 6 Jul 2000 11:26:56 -0400 (EDT)

On Fri, 23 Jun 2000, Jon Saperia wrote:

> on 06/19/2000 3:07 PM, Matt White at [email-masked] wrote:
> 
> > On Wed, 14 Jun 2000, Jon Saperia wrote:
> > 
> >> PmRoleESEntry ::= SEQUENCE {
> >> pmRoleESElement        RowPointer,
> >> pmRoleESString         SnmpAdminString,
> >> pmRoleESStatus         RowStatus
> >> }
> >> 
> >> I propose that the pmRoleESStatus be the place for the dirty bit. If that is
> >> not acceptable, another object in this table.
> > 
> > While this would work, I think I would prefer to look at the precedence
> > issue first.  We may come up with a solution to that problem that lends
> > itself well to solving the manual configuration problem.  Or we may not,
> > but I'd at least like to see where that goes before we lock ourselves into
> > a solution to this problem.
> > 
> > 
> > -Matt
> > 
> > 
> Matt,
> 
> can you clarify what you mean by the precedence issue please?
> 
> Thanks
> /jon

Jon:

Sorry for the delay, this folder was relatively low traffic so I thought I
could let it sit for a week while I worked on other things...silly me.  ;)

By "the precedence issue", I am referring to conflict resolution.  You
mentioned above the idea of associating a priority with a policy, which
IMHO is the right thing to do.  If we do go that route, we can look at
manual configuration on a box as an implicit policy, the "manual policy"
if you will.  The user can then assign whatever priority they want to
manual policy.  This provides the flexibility to say "policy foo and bar
do not override manual configuration, but policy baz takes precendence
always".

-Matt

---

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

> do not override manual configuration, but policy baz takes precendence

Matt this is an interesting idea but seems a bit complicated to me. I think
in effect what I and others have said is that a manual change always is
highest priority and overrides other parameters - perhaps a simpler version
of what you suggest.

/jon

---

From: Matt White <[email-masked]>
Date: Fri, 7 Jul 2000 12:57:21 -0400 (EDT)

Jon:

As you say, the dirty bit that we talked about previously is functionally
equivelant to locking the priority of manual configuration at the highest
level. 

As to whether allowing this priority level to change is complicated or not
really depends on how we deal with conflicting policies.  In my mind
however, there will always be the "manual configuration/firefighting"
policy which may conflict with other policies on the device.

For this reason, I think it might be worthwhile to decide how we're going
to deal with conflicting policies.  How to deal with manual configuration
may fall out of how we deal with conflicting policies.  At the very least,
we may get some ideas from that discussion.

-Matt

Matt White
Ericsson IP Infrastructure

---

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

> we may get some ideas from that discussion.

Note I changed the title a bit here since I wanted to start a new thread.

Matt, I believe we did and even had consensus on the list on June 24th. Even
Bert weighed in :-) The short answer is that the heavy lifting is done by
the manger. Local conflict resolution has always been done to some degree.
I gave the example of agents checking resources etc. Beyond that the policy
system inside a managed element does not do any conflict resolution and
detection. See my 7/3 posting.

All of this said, I am pretty convinced that there is significant value in
adding a policy group and policy priority object to the policy table.
Specifically group/priority is a way of connecting/prioritizing or doing
conflict resolution external to the device. If there are 10 policies on a
device and three related groups of policies, then I would say that there
would be three policy groups. I would also say that the policy groups should
be centrally named so that there is consistency across systems.

The policy priority should also be organized globally recognizing that local
optimizations may be needed.

/jon

---

From: Matt White <[email-masked]>
Date: Fri, 7 Jul 2000 16:54:47 -0400 (EDT)

Jon:

Comments inline.

-Matt

Matt White

On Fri, 7 Jul 2000, Jon Saperia wrote:

> Bert weighed in :-) 

I must be missing Bert's message and perhaps a few others.  My mailbox
seems to indicate no real consensus on what to do when Policy A sets OID1
to X and Policy B sets OID1 to Y.  The only recent message I have from
Bert states that if the element gives priority to Policy B and Policy B is
subsequently removed, then we should not go back and try to figure out
what value OID1 had before and change back.  I agree with this
wholeheartedly.  I also don't think that OID1 should automatically be set
to the value indicated by Policy A except to note that policy deletion is
probably a wizard time to re-evaluate the policies still on the device.

However, we seem to be talking about keeping a table containing every
instance on the device that is "under policy control" so that we know when
an operator makes a modification to an instance that was otherwise set by
policy.  The exact nature of how that works differs depending on whether
we take your path or the path suggested by Steve.  

I am merely asserting at this point that, if such a table is going to
exist, that it would be relatively simple to include as part of it a
pointer back to the policy that caused each row to be included.  It would
then also be a simple matter to have a priority level as part of the
policy table.  Then, when a policy is changing an instance, it could check
to see if that instance is already under policy control and whether the
policy being evaluated has a higher priority level.  If yes, apply the
change, if no, toss it.

Actually, if you are evaluating all policies on a device, it's even
simpler -- just evaluate in reverse priority order.

> The short answer is that the heavy lifting is done by

Again, this all seems to be in regard to deleting policies and rollback of
instance values.  I agree.  We can't do this.  The best we can do is
suggest that this might be a good time to re-evaluate those policies still
on the device.

> be centrally named so that there is consistency across systems.

Agreed.  Although as I mentioned above there seems to be some simple
things that we *could* do on the box.  Note that if we state that devices
should overwrite on equal priorities, devices which cannot handle
prioritizing can opt out by restricting the priority level to a single
value.

> optimizations may be needed.

An interesting point.

---

From: Jon Saperia <[email-masked]>
Date: Sat, 08 Jul 2000 10:12:08 -0400

> Ericsson IP Infrastructure
Matt,
I just wrote two notes that I think address at least some of your concerns.
lets see if they do :-).
/jon