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

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

[ Original text quoted in its entirety so MIB Doctors can see it.  ]
On Mon, 31 Jan 2005, Keith McCloghrie wrote:
> Mike,
> 
> 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