RE: [midcom] MIDCOM MIB design question

["Harrington, David" <dbh@enterasys.com>]

Thanks Dave.
I agree.

Having two separate modules is not wrong; but it isn't necessary, and it
doesn't bring any real benefits. You can simplify the VACM config using
separate subtrees within the same module, or just separate tables. 

I expect that the network manager may want to look at some of the
information being set by the MIDCOM agent, so two users will need access
to the same data. A MIDCOM agent that had access to the statistics of
different middleboxes might be able to choose which middlebox would
provide the fastest/cleanest path between endpoints, so while not
required to implement MIDCOM, access to the management information might
be helpful. 

The data involved here appears to be closely related, and I recommend it
be kept  together in the same mib.  The separation into different
modules is just an unnecessary complexity based on thinking about two
different applications and the specific objects they use. If we follow
that reasoning, do we need to define a new mib module for every type of
application that might look at MIDCOM data? Should we put the traps into
a separate module because a fault/trap manager might only look at the
traps? Should we separate the statistics from the mappings tables
because some performance management applications only need the
statistics and not the maps? Should we put NAT-related MIDCOM statistics
in one module and the firewall-related MIDCOM statistics in another
module because applications might focus on one or the other but not
both?

This is not a good way to approach defining a data set to monitor and
manage MIDCOM functionality.
--

You should understand something sbout me. One of the things I usually
fight against is large modules; I prefer smaller modules because it
makes it easier to advance the individual pieces. But you can break it
down too fine as well, and then need to create multiple dependencies
between the modules, which causes both to advance simultaneously in the
advancement process. I also fight against that. I think using two mibs
makes it more complex than necessary. How much more complex depends on
how you do it.

If N is counting the things created in M, you have a N->M normative
dependency. If M is defining the priority of the rules created in N,
then you have a M->N normative dependency. These modules will never be
able to advance independent of each other.

You haven't discussed whether your intention would be to publish two
mibs in the same document, or different documents. If you put two mibs
in the same document, then the issue of normative references between
documents goes away and we can ignore it.

If you define two mibs within the same document, you create the need to
import a lot of the objects from one into the other. Under those
conditions, I don't see a real benefit from doing this. There aren't
major downsides either, but it does increase the complexity
unnecessarily when you could simply use subtrees within the same mib.

dbh

> -----Original Message-----
> From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk] 
> Sent: Thursday, December 11, 2003 6:55 AM
> To: Juergen Quittek
> Cc: Harrington, David; Tom Taylor; mibs@ops.ietf.org; midcom@ietf.org
> Subject: Re: [midcom] MIDCOM MIB design question 
> 
> 
> 
> > Coming back to the MIDCOM MIB problem.  On  one side, there 
> is a set of
> > objects that concerns the entire protocol operations: 
> statistics, the
> > list of entities that established policies using the MIDCOM 
> protocol,
> > the number of failed attempts to establish a MIDCOM session, etc.
> > This should not be accessible to all potential entities 
> that are allowed
> > to use the MIDCOM protocol.  On the other side, there is the set of
> > objects implementing the MIDCOM protocol. This set should 
> be accessible
> > to a wider group of users.
> > 
> > Now, Tom said that this security issue could be handled 
> more easily if
> > we would use separate modules. I do not see anything wrong 
> with this.
> 
> 
> Pardon me for chipping in, but I'm not quite sure how the 
> split between
> MIB modules makes any difference to the security aspects of things.
> Surely by the time access controls are applied, the MIB 
> module(s) will have
> already been combined (even if only logically) into a single OID tree?
> 
> I can see that having a suitable hierarchical structure for 
> the management
> objects could well aid (or hinder) the configuration of 
> appropriate access
> control settings.  But what difference does it make whether 
> these objects
> are defined in one module, or two?  (Or even one module per object!)
> 
> 
> The question of how to divide objects between MIB modules feels to be
> more related to issues of convenience for implementation 
> and/or revision
> management.
> 
> So what am I missing?
> 
> Dave
> 
>