[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends
- To: Wes Hardaker <hardaker@tislabs.com>
- Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends
- From: John Shriver <jshriver+ietf@sockeye.com>
- Date: Fri, 13 Jun 2003 13:59:19 -0400
- CC: John Shriver <jshriver+ietf@sockeye.com>, Barbara Fraser<byfraser@cisco.com>, tytso@mit.edu, angelos@cs.columbia.edu, Bert Wijnen<bwijnen@lucent.com>, "Hilarie Orman, Purple Streak Development"<hilarie@xmission.com>, Luis Sanchez <lsanchez@xapiens.com>, "C. M. Heard"<heard@pobox.com>, Russ Housley <housley@vigilsec.com>, Paul Hoffman / VPNC<paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
- Organization: Sockeye Networks
- References: <4.3.2.7.2.20030606162749.04395f00@mira-sjc5-4.cisco.com> <3EE490E7.8080101@sockeye.com> <sd4r2u2b72.fsf@wanderer.hardakers.net>
- Sender: owner-ipsec@lists.tislabs.com
- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
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-ike-monitor-mib-04.txt,
>>>draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and
>>>draft-ietf-ipsec-monitor-mib-06.txt?
>>
>
> 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.