[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: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