RE: Compressing Large Indices?

[Tim Jenkins <tjenkins@TimeStep.com>]

> -----Original Message-----
> From: Baugher, Mark [mailto:mbaugher@passedge.com]
> Sent: January 24, 2000 2:03 PM
> To: 'Tim Jenkins'; mibs@psg.com
> Subject: RE: Compressing Large Indices?
> 
> 
> 
> > > 
> > > Why not define the MIB to use integer indices?
> > 
> > We want the ability for the user to look up information based 
> > on things that
> > are meaningful to them: the IDs of the endpoints used in IKE 
> > negotiation.
> > 
> The user will interact with an management application program
> rather than directly with the MIB, right?  Seems we have had 
> this exchange before.

I'm new to this list, so I have no idea if this exchange has gone on before.

However, if I understand you correctly, you're suggesting the agent does not
need to provide this capability. If that's the case, the management station
would have to do a (potentially) full table search to get the information
based on the IDs in this case. Remember, the IDs are not the indices of the
main table.

I was told this is not friendly, and that we should provide a helper
mechanism to allow this to be done without an exhaustive table search.
That's what I'm trying to do here.

Is this a mistake?

[

Problem statement:

We have a (potentially) very large table that is arbitrarily indexed. This
is a table of IKE phase 1 SAs. It is possible that there are multiple phase
1 SAs between the same endpoints. This is recognized by the IDs (some of the
objects in each row of the SA table) of each endpoint being the same.

Users will want to produce a list of all the SAs that are between a given
pair of endpoints. We wanted to do this by providing a helper table whose
indices consisted of the endpoint IDs. This table would then point at the
SAs in the SA table that used those IDs. This would save an exhaustive
search of the SA table by the management station every time the user demands
to know about the SAs between a pair of endpoints.

The issue is that the IDs cannot be used as indices.

Now, it may be that we shouldn't be doing this at all?

]

> 
> Mark
> 

Thanks,

Tim