[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends

Wes Hardaker wrote:
>>>>>>On Mon, 09 Jun 2003 09:51:35 -0400, John Shriver <jshriver+ietf@sockeye.com> said:
> John> Absolutely.  The problem is that we lack a consensus on what to
> John> do about Mike Heard's comments.
> I'm pretty sure I remember posting quite a few posts about it (on your
> side of things).
> Also, there were a lot of other discussions (off-list) held by the MIB
> experts that sided with Mike...

Yes.  But only a very small percentage of the WG has anything to say. 
Perhaps the absence of dissent counts as consensus...

> John> I suspect that nobody is implementing the related MIBs.
> The IPSEC-POLICY-MIB has already been implemented (see the net-policy
> project on sourceforge for details), which does depend on your draft
> to date.  Specifically, I really need to know if your going to publish
> a new draft or not and send it through last call.  If you don't, I'll
> need to remove the dependencies from the IPSEC-POLICY-MIB.

I meant the three IPSec MIB that Tim and I did.  I know that the policy 
MIB has legs.

>>>2. We need to come to agreement on what changes are needed, that is
>>>we must address the MIB doctor comments.
> John> Well, I can make the changes from enumerations to simple typedefs.
> John> The real question is whether the IPSP folks are still interested in
> John> using this MIB if it doesn't have the enumerations in it.  To me, that
> John> was the primary value of the MIB, and why I convinced Tim to let me do
> John> it.  He was just exporting the variables as INTEGERs, which I found
> John> unfriendly. At least with any of the tools inheriting from the CMU
> John> ones, the enumerations are much more useful.
> John> So, IPSP folks (you are on the CC: list, right?), do you still want
> John> this MIB without the enumerations?  If so, I'll make Mike's changes,
> John> and ship it out again.
> I'd do it just because it still provides a standard convention for the
> datatypes and a standard place where the documentation about them
> can be listed.  However, I agree it's less useful with the enums removed.

Well, I will go ahead and do those changes.  I've even been working on 
MIBs in my paying job recently.

>>>draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and
> John> I think we can let them die, unless someone someone is wanting them.
> I think they'd be useful, but I haven't read them recently.  The
> concepts in them are definitely needed and I've spoken to various
> people lately about them and they agree that they'd be useful to put
> into their products.  However, that doesn't mean they will.

If we were to keep them alive, they would need to migrate to IKEv2, 
which is no small project.  I don't see any point in MIB-ing IKEv1.

There would need to be authors who were committed to implementing it.