Re: abandoning ike-monitor-mib, isakmp-di-mon-mib, and monitor-mib?

[rks@cisco.com]

About the TCs alone: as you and Mike Heard have pointed out,
ipsec-flowmon-mib-tc duplicates much of doi-tc-mib. Since the
latter is also used by the Policy MIB, I feel that it would be
better for the Flow MIB to be layered on the same set of textual
conventions.

I hope that you would include the couple of TCs which the Flow
MIB needs which are missing in your draft.

Thanks,

Rk
x77309

On Fri, 13 Jun 2003, John Shriver wrote:

> OK, let's try and sort out the MIB issues one decision at a time.  The
> first thing is to decide if we want to abandon the original set of MIBs:
>
>    draft-ietf-ipsec-ike-monitor-mib-04.txt,
>    draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and
>    draft-ietf-ipsec-monitor-mib-06.txt
>
> They have never attracted much interest.  Neither of the original
> authors work in the IPsec marketplace anymore, so they can't contribute
> any implementations to get them through the standards process.  I think
> that there is only one implementation of them, ever.
>
> Moreover, both the ISAKMP and IKE MIB modules would require MAJOR
> rewriting to be compatible with IKE Version 2.  Like merging them, since
> the ISAKMP/IKE layering is extinct in v2.
>
> So, given this set of considerable problems, is there anyone who wants
> these MIBs to track the IPsec standards going forwards, and can find
> resources to update them and implement them?
>
> If nobody wants to do this, will we take the lack of any dissent on
> their death as "consensus" per the "IETF Process"?
>
>
> I *NEED* to know this, because there are a number of TEXTUAL-CONVENTIONS
> in the doi-tc-mib that were only used by these three MIBs, and are not
> used by the IPsec flow MIB, or by the Policy MIB.  Since it looks like
> the doi-tc-mib will NOT be maintained by the IANA (no enumerations), the
> TC's have to be used in some MIB to progress through the standards
> process, so we can't stock up on "spare" TCs for possible future needs.
>
>
> So, please consider this a "last call", only for termination instead of
> promotion along the standards track.
>
>