Re: Corner case in draft-ietf-ops-mib-review-guidelines-03.txt

["C. M. Heard" <heard@pobox.com>]

On Mon, 31 Jan 2005, Keith McCloghrie wrote:
> > > In draft-ietf-ops-mib-review-guidelines-03.txt, section 4.6.4 says:
> > > 
> > >    - For conceptual rows:
> > > 
> > >      - If the row is an extension of a row in some other table, then an
> > >        AUGMENTS clause MUST be used if the relationship is one-to-one,
> > >        and an INDEX clause MUST be used if the relationship is sparse.
> > >        In the latter case the INDEX clause SHOULD be identical to that
> > >        of the original table.
> > > 
> > > for the sparse case, if the only information to be defined in the new
> > > table is the value of the auxiliary object(s), [...]

I think that I must have missed your point.  My thinking was as follows.

If you mean auxiliary objects in the new table, then these are (by definition)
index objects in that table.  Those objects wouldn't be in the INDEX clause of
the original table;  otherwise there would be no need to define them.  Since
the new table has more indices than the original, it is an expansion table
(multiple row instances correspond to one row instance in the base table).

On the other had, if you mean auxiliary objects in the original table, then
I do not need an augmenting table to tell me what their values are;  I can
get that information by retriving any accessible object in the original
table.

> The case that I'm thinking of is not an "expansion table"; here's
> an example:
> 
>    xxxTable  OBJECT-TYPE
>       ...
>    xxxEntry  OBJECT-TYPE
>       ...
>       INDEX   { xxxPhysicalIndex }
>      ...
> 
>    SEQUENCE { xxxPhysicalIndex xxxPhysicalIndex }
> 
>    xxxPhysicalIndex OBJECT-TYPE
>       SYNTAX      PhysicalIndex
>       MAX-ACCESS  read-only
>       ...
> 
> It's a sparse augments.  The INDEX clause cannot be "identical to that
> of the original table" because the entPhysicalTable has
> "INDEX { entPhysicalIndex }"  and then the SEQUENCE for xxxTable would
> be empty !!

I do not understand the example.  Sorry if I am being thick.

Mike