[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New IPSec Monitoring MIB draft
Tim,
This draft looks promising. It shows a structure that can do the job
it sets out to do.
Looking ahead, though, I wonder if it is the optimal structure for the
longer term. This MIB is a monitoring MIB, and it certainly shows
most or all of what you might want to monitor. But at some point we
will also want to have a configuration MIB. Clearly, those two MIBs
would ideally use a similar way of organizing the data.
Your draft shows all the IPSEC/IPCOMP related data in one place: the
protection suite table rows. That method of organization may not be
all that convenient in a configuration MIB. For example, parameters
such as expiration limits, security services to use, etc., could be
organized in a table ("policies" -- or maybe that name is already
taken?) where they are named and then referred to. If lots of
protection suites are set up to a common pattern, this simplifies
configuration.
Such an organization could also be applied to the monitoring MIB if we
want to do that. So do we want to do that? I can see several
possible approaches:
1. Continue with the monitoring MIB in its present form; when we get
to a configuration MIB, that one may have a different organization,
but that's ok.
2. Spend some time outlining a skeleton configuration MIB
organization, and adjust the monitoring MIB to have an analogous
organization.
Obviously, #1 is quicker. Which one is better depends on whether
people feel it's more important to have a monitoring MIB soon
vs. having one closely patterned after the configuration MIB. To put
a stake in the ground, I'd prefer #2 because in the long run it will
make for a clearer and easier to understand picture.
paul
References: