[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf DiffPolicy MIB comments



I have included only the 1 section on which I have a comment.

> > 
> > How to find proper template:
> > 
> >   An important usability issue is how do I find the proper row in the
> >   DiffPolicyDPCTable to clone? These tables are indexed by a random
> >   integer assigned by the RowStatus algorithm, so they will be
> >   different on each host. NMS code or policyScript code will want to
> >   find the proper entry to clone but won't want to have to walk down
> >   the whole path checking that the parameters are equal to it's
> >   understanding of "gold" (in fact, they'd have to do this N times, as
> >   they searched through the templates in the table until they found
> >   the one with the proper parameters). If they actually had to scan to
> >   find the proper row, they would quickly find that it was easier to
> >   just create a new entry than to find an existing entry that matched
> >   all the parameters and then clone that one (you'd need to know all
> >   the detailed parameters anyway). (When Hongal wrote his example he
> >   hid a *lot* of complexity in the getCloneOfDataPath() function
> >   call).
> > 
> >   At first I thought this was a fatal flaw in the whole Provisioning
> >   MIB concept but I have a solution.
> > 
> >   Since integers aren't constant from box to box and aren't long-lived
> >   on a box, something else is needed. I'd suggest that an
> >   SnmpAdminString be created called diffPolicyDPCName (or ID or
> >   something similar). This would be an administratively assigned
> >   identifier for a template that would be unique within an
> >   adminstrative domain. It is up to the management stations to agree
> >   how these are assigned within the administrative domain. But once
> >   you assign "gold", that has a certain set of parameters that achieve
> >   "gold" from box to box, so NMS code or policyScript code can easily
> >   scan the table to find the proper template and then easily assign
> >   it.
> > 
> >   I think this concept will be needed for any xxxProvisioning MIB.
> 
> I agree on this. By having a name in the index it could be used
> on all systems. This will make writing the policy scripts easier.
> I believe that the IPSEC-MIb also has some policy-configuration
> capabilities. David P, you know more about this, right??
> How have they fixed this??

I agree on this point also. There are several places in our technology
where uniqueness is helpful.  This is one - I will look for others as we
do our review. I will also put a note in the BCP.

With regard to the IPSEC Module, I have some writing to do on that with
the other co-authors and will check into it.
> > 
> > StorageType
> > 
> >   You should probably add a storageType object or give blanket
> >   guidance as to what happens on a reboot.
> 
> I originally had some storageType and should be added again.
> However, there is still a problem related to the approach the
> hardware was made. Most DiffServ people told me the use
> flash memory and having on each entry a storageType is
> problematic. VIa the CLI the use a 'commit' like command.
> Should we follow that approach??
> 
> What do others think of this??

This is a general problem. Different implementations will have different
needs, for flash only based systems we certainly do not want to write
with each operation. There are two issues here that are not new and are
related.

        1. Permanence of the change
        2. When activated

Permanence choices:   in memory only
                      in memory and permanent storage
                      to permanent memory (am I wrong that most systems
                      do not give a choice of to disk versus flash - if
                      so and people really felt it were needed you could
                      expand this for flash, disk, etc. etc.)

Activation choices:   Activate now (now can be defined in an object -
                      like a commit, or make active object). Put in the
                      level of granularity needed such as per row, or
                      per table. Up to each table/module designer.

                      Activate on reboot

These give the control to the operations people. If we make the level
very granualar that might be a problem for flash only based systems so
we need to allow the control via mib objects for granularity and let the
operations people be the best judge.
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/