[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 has had implementations that use this, and he has made similar changes
to his IPSP MIB document in order to appease the MIB powers.  You and Wes should
coordinate changes and resubmit ASAP.


>  Date: Mon, 09 Jun 2003 09:51:35 -0400
>  From: John Shriver <jshriver+ietf@sockeye.com>
>  Organization: Sockeye Networks

>  > Hi John,
>  > 
>  > Ted and I have been, once again, digging back into the status of 5 of 
>  > the MIB documents and would like to see us once and for all get these 
>  > documents put to bed.  We've seen and read the thread concerning 
>  > draft-ietf-ipsec-doi-tc-mib-07.txt. Everything seems to have come to a 
>  > halt after Mike Heard posted his summary MIB doctor comments on April 
>  > 28. This document is referenced in the an IPSP document so we need to 
>  > somehow resolve the issues surrounding it,  which is why there is such a 
>  > wide distribution on this message.  First question is, are you willing 
>  > to continue to work on this document as the editor? 

>  Absolutely.  The problem is that we lack a consensus on what to do about 
>  Mike Heard's comments.  Honestly, nobody but Mike and I appear to give a 
>  darn, at least on the IPsec mailing list!  Even if I do decide to agree 
>  with the change from enumerations to simple typedefs, is an agreement of 
>  two people out of the entire IPsec list really a consensus?  Maybe it 
>  is, in the absence of any dissenting opinion!

>  Myself, I think the MIB is far more useful if we ignore Mike's comments. 
>    But, realistically, it would _never_ get through last call, and it 
>  would be futile to proceeed in that direction.

>  > Second, it seems 
>  > there has been some difference of opinion between you and Mike. One 
>  > comment made was that some of the difficulties arose from this document 
>  > being looked at in isolation of the other related documents. This brings 
>  > me to a question. Every time Ted and I have asked if anyone is 
>  > implementing these MIBs, there has been total silence leading us to 
>  > believe nobody is implementing them. 

>  I suspect that nobody is implementing the related MIBs.  I may remember 
>  one vendor implementing the drafts, but I wouldn't be surprised if 
>  they've been swept away by the dot-com meltdown of the last two years.

>  > Paul Hoffman has kindly resubmitted 
>  > 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 for us in the new format, and if he, 
>  > or someone else is willing to take them on, we could continue to 
>  > progress all of them.  

>  I think that IKEv2 is rendering much of the content of these MIBs as 
>  obsolete.  Plus the competiting IPsec Flow Monitoring MIB effort from 
>  Cisco & Tivoli people, which has the advantadge of being implemented. 
>  (You can't get through the standards track without implementations...) 
>  Hopefully the folks authoring the Flow Monitoring MIB will continue to 
>  pick up some of the good points from the earlier set of MIBs, I will 
>  concede that later versions were improved.  But I've seen little 
>  standards effort there, they may have decided to abandon the standards 
>  track, and just publish the MIBs under their trees?

>  > If that's what folks want to do. On the other 
>  > hand, we could also choose to progress only the document that Hilary's 
>  > group needs and drop the other three due to lack of 
>  > interest/implementation.  It's also fair to remind folks that these are 
>  > all IKEv1 MIB docs.
>  > 
>  > All this boils down to the following:
>  > 1. Are you willing to continue to edit draft-ietf-ipsec-doi-tc-mib-07.txt?

>  Yes.

>  > 2. We need to come to agreement on what changes are needed, that is we 
>  > must address the MIB doctor comments.

>  Well, I can make the changes from enumerations to simple typedefs.  The 
>  real question is whether the IPSP folks are still interested in using 
>  this MIB if it doesn't have the enumerations in it.  To me, that was the 
>  primary value of the MIB, and why I convinced Tim to let me do it.  He 
>  was just exporting the variables as INTEGERs, which I found unfriendly. 
>    At least with any of the tools inheriting from the CMU ones, the 
>  enumerations are much more useful.

>  So, IPSP folks (you are on the CC: list, right?), do you still want this 
>  MIB without the enumerations?  If so, I'll make Mike's changes, and ship 
>  it out again.

>  > 3. Are we going to continue to support 
>  > 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? 

>  I think we can let them die, unless someone someone is wanting them.

>  > If so, who's willing to take on the 
>  > document editor job? And, more importantly, how do we decide what 
>  > changes are needed to them.
>  > 
>  > I feel like we're living in Groundhog Day with these MIB docs. We keep 
>  > living the same thing over and over. Let's please get to the end :-)

>  Yeah, it would have been _easier_ if there had been some controversy, 
>  rather than stunning silence all the way...

>  > 
>  > thanks,
>  > Barb and Ted