Re: IDPR MIB

[Kenneth Carlberg <[e-mail]>]

> A point can be made that all status objects have only local
> implementation significance

i take it you mean local to the domain, as opposed to a VG or a PG.

> However, having a status object allows the network manager to view,
> modify, or delete a policy without using a separate out-of-SNMP-band
> channel.  This seems to be a nice feature to me.

i agree.

> > I still have fundamental problems with the idea of modifying
> > configuration between restarts without changing the config file, unless
> > we change the implementation to also dump a config file back out when a
> > change is made.
>
> If we permit the network manager to only change the state from active
> to inactive and do not allow dynamic instantiation of new policies,
> then trying to keep consistent configuration databases is probably
> less of an issue.

Personally, I would extend the capability to *modifying* a policy. An
example that runs through my head is a stub domain that is connected to
two providers (transit domains) - one VG per provider:

	transit-1		 Transit-2
		\		    /
		 VG-1		 VG-2
		  \		  /
		   \_____stub____/
	
In my example, I have a set of policies that pertain to each VG 
(ie. each entry/exit point of my stub domain). 
These sets of policies would not change under 
normal circumstances (whatever they may be). But if per chance, one
provider is (temporarily) having serious problems and I can't send 
traffic through it, then it would seem like a nice idea to alter
the VG portion, for example, of a policy (or the on/off that you 
talk about) on the fly as opposed to making a definitive change in 
the policy files.

In other words, I would like to view the policy files as a static
entity, and change things on the fly as the need arises. In this
manner, I don't have to remember what my original policies are
when things go to normal because I will never have changed my original
set of policies.

my $0.02

-ken