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

RE: Status of ID: IPsec Flow Monitoring MIB

> -----Original Message-----
> From: Leo Temoshenko [mailto:leot@cisco.com]
> Sent: Monday, October 29, 2001 8:59 PM
> To: Tim Jenkins
> Cc: 'rks@cisco.com'; byfraser@cisco.com; tytso@mit.edu;
> bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> Subject: Re: Status of ID: IPsec Flow Monitoring MIB
> 
> 
> 
> 
> Tim Jenkins wrote:
> > 
> > > -----Original Message-----
> > > From: rks@cisco.com [mailto:rks@cisco.com]
> > > Sent: Sunday, October 28, 2001 6:17 PM
> > > To: Tim Jenkins
> > > Cc: byfraser@cisco.com; tytso@mit.edu; bbruins@cisco.com;
> > > ipsec@lists.tislabs.com; leot@cisco.com
> > > Subject: RE: Status of ID: IPsec Flow Monitoring MIB
> > >
> > >

...

> 
> > 
> > Since they are not application specific, and in their raw
> > form may not be what most implementors want, it is expected
> > that they will be used as the building blocks for application
> > specific MIBs. That is why I submitted the tunnel monitoring
> > MIB: as an example of how the base MIBs could be used as
> > the building block of an application specific MIB.
> > 
> 
> Too low level to be useful.  Why would one want to implement
> "unuseful" MIBs in order implement useful MIB?

Because they provide building blocks, and a foundation if you will.

Further, they are not "unuseful". As I have repeatedly said, an
application specific MIB will be more useful to a customer. But
that does NOT mean that providing a single all-singing-all-dancing
MIB is the correct answer either.

See more below about why they are useful.

> 
> > The status is that they have had minimal changes for the last
> > three revisions, and are ready for last call. We get next to
> > no comments on them now. (But we do know people are reading
> > them, since we get private questions on them.)
> >
> 
> So why can't one find these revisions??   Where can one get
> a copy of these revised drafts?  Since one cannot find them,
> how would/could one implement them?   

If you couldn't find them, how can you read them and criticize them?

Further, I know there have been some implementations, because John
and I have received emails from implementors. Hopefully, they will
speak up.

Here are the links, found by searching with the internet-drafts site
<http://search.ietf.org/search/brokers/internet-drafts/query.html>
with the keyword "shriver":

<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-05.txt>
<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-05.txt>
<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-03.
txt>
<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-0
4.txt>

...

> > 
> > This version was very forcefully rejected by the working group
> > at the meeting in Orlando because it was application specific,
> > and did not separate the components out. That is why there exists
> > the series you see today that honours the separation of the IPsec
> > components as they exist today.
> 
> So why are you objecting so strongly?  That was then, this is now.

You keep saying that. What has changed? IPsec hasn't changed. And I
keep telling you why I object.

We still have IPsec SAs that can be created statically, using IKE or
any other key exchange protocol that you like. There is a MIB for them.
That MIB is still usable if you don't use IKE to create the SAs.

We still have ISAKMP, a framework for a key exchange protocol. There
is a MIB for that. That MIB is still usable if you build a different
key exchange protocol on top of ISAKMP.

We still have IKE, a key exchange protocol. There is a MIB for that.

Again, I agree there is a need for an application specific MIB. In
order to illustrate that, I submitted the tunnel MIB as an example.
The hope was that someone would be able to develop an application
specific MIB more quickly if there was an example available.

> 
> > 
> > Perhaps the working group has changed its mind. If it hasn't,
> > then I don't see how the Flow monitoring MIB can be advanced as
> > it is since it duplicates much of what is already done in the
> > collection of base MIBs.
> 
> I beleive it has.

So, far the only voices I've heard that are suggesting that are
the authors of the flow monitoring MIB.

Could you provide some evidence that the working group wants
to promote a single MIB that cannot be used if a different key
exchange protocol is used to create IPsec SAs?

Could you provide some evidence that the working group wants
to promote an application specific MIB? (I actually agree with
this, but I believe it should be built on a solid foundation,
and not something that will have to be thrown away if one part
underneath it changes.)