Re: 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