[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New IPSec Monitoring MIB draft
Paul,
Thanks for the comments.
Regarding the ideas about a configuration MIB, I believe that configuration
of IPSec is really configuration of policy. After all, it is the occurrence
of events/traffic/etc. that, when applied against the policy of a system,
cause the creation of SAs. This MIB is supposed to indicate what you have,
but not how you got there.
Since we have no standard way do define policy, a configuration MIB will
probably not get done until after policy is defined. There are already a
number of proposals for defining standard policy; drawing this MIB into that
will only slow its progress.
The only reason you would ever want to write to this MIB would be if you
wanted to change something about an existing SA. However, I don't believe
that this is the appropriate method to do that.
Tim
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@xedia.com]
> Sent: Wednesday, January 27, 1999 9:49 AM
> To: tjenkins@TimeStep.com
> Cc: ipsec@tis.com
> Subject: 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
>