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

John Shriver <jshriver+ietf@sockeye.com> Fri, 13 June 2003 19:53 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21102 for <ipsec-archive@lists.ietf.org>; Fri, 13 Jun 2003 15:53:00 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20985 Fri, 13 Jun 2003 13:59:25 -0400 (EDT)
Message-ID: <3EEA10F7.1070402@sockeye.com>
Date: Fri, 13 Jun 2003 13:59:19 -0400
From: John Shriver <jshriver+ietf@sockeye.com>
Organization: Sockeye Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wes Hardaker <hardaker@tislabs.com>
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
Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends
References: <4.3.2.7.2.20030606162749.04395f00@mira-sjc5-4.cisco.com> <3EE490E7.8080101@sockeye.com> <sd4r2u2b72.fsf@wanderer.hardakers.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

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.