> Regarding the question about the different MIB-WALK implementations of
> prtStorageRefTable :
> > > I looked at the Interop mib walk test results. Vendor 2 has 2 storage
> > devices
> > > and they use prtStorageRefIndex.1.1 and prtStorageIndex.2.2. Vendor 4 has
> 4
> > > devices,
> > > with prtStorageRefIndex.1.1, .2.1, .3.1 and .4.1. Which of these is more
> > > correct?
>
> I think it's very clear that vendor 2 (it's not too difficult to guess who it
> is) has wrong implementation. And we should urge them to fix it. The reasons
> are :
> 1. RFC1759 says the prtStorageRefSeqNumber is "unique amongst all the entries
> with a common value of hrStorageIndex". This means it's sub-index in
> prtStorageRefTable. Since it's an index itself, it should start with 1, not 2.
If I'm not mistaken (but I could be), there is no rule that requires index
values must start with 1, unless the definition of the index object itself
requires such a restriction.
Index values in MIBs are primarily used to implement uniqueness. As such,
it should matter what the values are, just so long as they are unique.
(Of course, issues revolving around the need to collate the data may
reasonably require some sort of ordering of index values.)
I would agree, though, that starting with an index value is a bit strange.
But I don't believe any "rules" have been broken here.
Anyone disagree/agree with this?
...jay