Subject: RE: snmpconf Conflict Resolution Issues - Consensu

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 3 Jul 2000 15:04:14 +0200

Agree. See commentsinline

> ----------
> From: 	Jon Saperia[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Wednesday, June 28, 2000 7:10 PM
> To: 	[email-masked]
> Subject: 	Re: snmpconf Conflict Resolution Issues - Consensu
> 
> on 06/24/2000 6:24 PM, Joel M. Halpern at [email-masked] wrote:
> 
> > It is my opinion that deleting a policy should not directly cause a
> change
> > in any attributes of any instances.  It may be reasonable to expect
> > (depending upon our evaluation model) that the set of policies in effect
> > should be re-evaluated, which my cause some existing policy to change
> the
> > values of some objects.  Trying to perform a direct "unwinding" of a
> policy
> > when it is deleted would, I think, be a very bad idea.
> > 
> > Yours,
> > Joel M. Halpern
> > 
> 
> Folks, I believe that we have consensus on this topic even though my
> original postings may not have been clear.
> 
> The consensus is that we should not attempt to deal with this in the
> managed
> systems at all for all the previously stated reasons.  I agree. If a
> manager
> wants to do something fancy when deleting a policy that is outside the
> scope
> of the current work.
> 
> All agreed?
> 
So this means that if a policy gets deleted from the table, then no action
is taken, i.e. no config changes take place because of that action.
If my understanding is correct, then we should explicitly state so in the
DESCRIPTION clause of the table.

Bert

---

From: Jon Saperia <[email-masked]>
Date: Mon, 03 Jul 2000 10:59:33 -0400

> DESCRIPTION clause of the table.
Yes Bert. You understanding is consistent with mine. We should remember that
this does not obviate what Andrew Smith wrote the other week about each
level in a policy management system having responsibility for doing the
right thing. This is not new, agents have been doing this for a long time.

We need to do three things:

    1. On the next revision of the DiffServ Policy MIB Module we should add
this text where appropriate. This will be after the next IETF since we have
already published for this meeting.

    2. The Policy MIB Module has not been published. We should be able to
get that into the Policy MIB in time where it matters (seems particularly
relevant to the Policy Table. Steve can we get this in. I do not think it
affects any of the tables I wrote as drafts and published to this list the
other week (the redo of the capabilities table).

    3.  We should put this into the BCP policy section where appropriate. I
will do this as I work on that section.

/jon