Re: indexing scheme in draft-ietf-rohc-mib-rtp-06.txt

[Andy Bierman <abierman@cisco.com>]

At 01:07 PM 6/22/2003, C. M. Heard wrote:
>While reviewing draft-ietf-rohc-mib-rtp-06.txt I noticed something
>about the table indexing scheme that does not look quite right.
>
>Here are the relevant extracts (mainly the INDEX clauses) from the
>three MIB modules in this draft:
>
>ROHC-MIB DEFINITIONS ::= BEGIN
>    ...
>rohcChannelEntry OBJECT-TYPE
>    ...
>    INDEX { ifIndex, rohcChannelID }
>    ...
>rohcInstanceEntry OBJECT-TYPE
>    ...
>    INDEX { ifIndex, rohcInstanceType, rohcChannelID }
>    ...
>rohcProfileEntry OBJECT-TYPE
>    ...
>    INDEX { ifIndex, rohcChannelID, rohcProfile }
>    ...
>rohcContextEntry OBJECT-TYPE
>    ...
>    INDEX { ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID }
>    ...
>END
>
>ROHC-UNCOMPRESSED-MIB DEFINITIONS ::= BEGIN
>    ...
>rohcUncmprContextEntry OBJECT-TYPE
>    ...
>    INDEX { ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID }
>    ...
>END
>
>ROHC-RTP-MIB DEFINITIONS ::= BEGIN
>    ...
>rohcRtpContextEntry OBJECT-TYPE
>    ...
>    INDEX { ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID }
>    ...
>rohcRtpPacketSizeEntry OBJECT-TYPE
>    ...
>    INDEX { ifIndex, rohcInstanceType, rohcChannelID,
>            rohcContextCID, rohcRtpPacketSize }
>    ...
>END
>
>
>Here is my proposed review comment:
>
>- The table indexing scheme uses an inconsistent ordering of index
>components.  Specifically, although all tables are indexed by
>ifIndex and rohcChannelID, the tables without rohcInstanceType as an
>index component all have { ifIndex, rohcChannelID, ... } as a common
>prefix, while those with rohcInstanceType do not:  their common
>prefix is { ifIndex, rohcInstanceType, rohcChannelID, ... }.  While
>this will work, it tends to make the implementation harder than it
>needs to be, because there is less indexing code that can be re-used
>for the different tables.
>
>Recommendation:  in the tables that have rohcInstanceType as an
>index component, change the order of the leading components
>from:
>    INDEX { ifIndex, rohcInstanceType, rohcChannelID, ... }
>to:
>    INDEX { ifIndex, rohcChannelID, rohcInstanceType, ... }
>
>The affected row objects are rohcInstanceEntry and rohcContextTable
>in the ROHC-MIB module, rohcUncmprContextEntry in the
>ROHC-UNCOMPRESSED-MIB module, and rohcRtpContextTable and
>rohcRtpPacketSizeTable in the ROHC-RTP-MIB module.
>
>
>Does this seem reasonable to the other folks who inhabit this list?

not really.  I will withhold my usual rant about the
deficiencies of SNMP related to indexing here...

The INDEX order is entirely up to the MIB designers.
It serves two purposes:
 1) enforce a particular uniqueness hierarchy
 2) provide a particular search order that the designers believe
    will be most useful to application developers

I think you should point out the INDEX order inconsistencies
and ask the authors if they had specific reasons for this
ordering.  If they don't, then it might be appropriate to
suggest changing some INDEX clauses.


>Mike Heard

Andy