RE: MIDCOM MIB design question

David,

Thanks again for your comments.

--On 11.12.2003 9:57 Uhr -0500 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.

Agreed.

> 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.

I see your point, but I think there are very few web browsers that
check the MIB of a web server before selecting which one to choose.

> 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?

David, you are exaggerating.  I am asking for advice whether or not
concerning a split into two modules.  I have a preference, but in the
end I want to make the optimal choice, whatever it is. And I want to
understand the choice.

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

Agreed. The exaggerated examples are to be voided.

>
> You should understand something sbout me. One of the things I usually
> fight against is large modules;

OK. I understand you are a fighter against large modules.  You have my
full support.  I hate unnecessary complexity, particularly in tricky and
political things such as standard MIB 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.

Again, you have my full support.  However, I did not raise the issue,
because I just WANT to split the module into two. Initially Suresh,
Martin and I worked on a single module.

Then we discovered that there are two portions used by different
applications and not having many dependencies among each other.
One portion (the MIDCOM Protocol portion) is completely independent
and the other portion would have to import three index objects and
use them for providing information about resources used per policy.

Also, the second portion is optional while the first one is mandatory.
Therefore, we considered the idea of separating them.  But we did not
just do it but asked for advice first.  And that's where we are now.

> I think using two mibs
> makes it more complex than necessary. How much more complex depends on
> how you do it.

OK. You say: if you can do it in one MIB module, choose one.

> 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,

M is defining ONE priority applying to ALL rules created in N.

> then you have a M->N normative dependency. These modules will never be
> able to advance independent of each other.

Thanks for the lecture.  The overlap between the modules is three
shared index objects, defined in one module and imported by the other
one.  There is no configuration of M that affects a single particular
object in N.

> 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.

Well David, I did not discuss it on this list yet, but I did send a
detailed message discussing exactly this issue to Wes and you without
getting a reply. That's why I posted to this list. Here is a quote of it:

--On 01.12.2003 11:00 Uhr +0100 Juergen Quittek wrote:
JUERGEN> In general, we see the following three choices:
JUERGEN>
JUERGEN> 1. Have a single MIB module including all objects
JUERGEN>    Advantage: all in one
JUERGEN>    Disadvantage: The separation of both groups gets blurred.
JUERGEN>
JUERGEN> 2. Have two separate MIB modules,
JUERGEN>
JUERGEN>    - a MIDCOM-PROTOCOL-MIB for all objects relevant to the
JUERGEN>      MIDCOM agent
JUERGEN>
JUERGEN>    - a MIDCOM-SERVER-MIB for all additional objects that are
JUERGEN>      intended to be used mainly by network management applications.
JUERGEN>
JUERGEN>    This separation is much clearer, because the logical split
JUERGEN>    between protocol plane and management plane is reflected.
JUERGEN>
JUERGEN>    We can have these two modules on
JUERGEN>
JUERGEN>    2.a. a single document
JUERGEN>    2.b. two separate documents
JUERGEN>
JUERGEN> 3. Drop MIDCOM server managed objects, because they are out
JUERGEN>    of scope.

> 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.

As you can read from the draft Martin and I brought to your attention
some time ago (draft-stiemerling-midcom-server-mib-00.txt), it is not a
lot of objects but exactly three objects and all of them serve as common
index.

> 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.

OK. I will collect the posted opinions and come up with a summary before
making a decision.

Let me summarize your position (and please correct me if I'm wrong!):

David's recommendation: one MIB module.
  - Security is not a reason for having separate modules.
  - Two separated MIDCOM modules cannot be progressed independently
    because they depend too much on each other.
  - Three shared index objects increase complexity unnecessarily.
    Different subtrees should be used instead.

Thanks,

    Juergen

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