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

[Keith McCloghrie <kzm@cisco.com>]

> > 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), then the augmenting table
> > cannot be defined with an identical INDEX clause; rather, it must
> > define a local object(s); this local object(s) will be read-only based
> > on the special case of bullet (2) at top of page 29 in RFC 2578.  For
> > example, a table needed to list all physical components with some
> > special property would be a sparse augments of the entPhysicalTable
> > requiring one object to be defined in the new table with syntax of
> > PhysicalIndex and its INDEX clause referring to this new local object.
> > 
> > The quote above says: "SHOULD be identical" and so it does allow for
> > exceptions, but you might want to mention this specific case.
> > 
> > Keith.
> 
> Keith,
> 
> I think this case would be covered by the paragraph after the one
> you cited:
> 
>      - If the row is an element of an expansion table -- that is, if
>        multiple row instances correspond to a single row instance in
>        some other table -- then an INDEX clause MUST be used, and the
>        first-mentioned elements SHOULD be the indices of that other
>        table, listed in the same order.
> 
> This does not specifically mention the 'read-only' exception in
> RFC 2578 Section 7.7, but I don't think it has to.  We did, after
> all, cite the authoritative material in the first paragraph of
> Section 4.6.4., and what we are trying to cover here are the common
> cases.  Or at least that's what I thought.
> 
> Mike
 
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 !!

Keith.