Re: MIDCOM MIB design question

OK, I surrender.  Looks like I ventured into an area the MIB experts 
command.

Harrington, David wrote:

> 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:[email protected]] 
>>Sent: Thursday, December 11, 2003 6:55 AM
>>To: Juergen Quittek
>>Cc: Harrington, David; Tom Taylor; [email protected]; [email protected]
>>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
>>
>>
> 
>