Re: AUGMENTS clause

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Monday, January 10, 2005 8:43 PM
> Subject: Re: AUGMENTS clause
>
> On Mon, 10 Jan 2005, Randy Presuhn wrote:
> > On the contrary, your explanation makes it clear that AUGMENTS
> > was the wrong construct, since the relationship is not 1:1, but rather
> > 1:(0..1), depending on whether it's an SVC or PVC.
>
> One can add optional columns in a base table (optional, in the sense
> that they are not required to be instantiated under all
> circumstances).  Are you now telling me that it's unlawful to use
> the AUGMENTS clause to do the same thing?  That's exactly what RFC
> 3606 is doing.  The same thing, BTW, was done in the IF-MIB.
...

I think RFC 2578 sections 7.8 and 7.8.1 are clear on this point.

|7.8.1.  Relation between INDEX and AUGMENTS clauses
|
|   When defining instance identification information for a conceptual
|   table:
|
|(1)  If there is a one-to-one correspondence between the conceptual rows
|     of this table and an existing table, then the AUGMENTS clause
|     should be used.
|
|(2)  Otherwise, if there is a sparse relationship between the conceptual
|     rows of this table and an existing table, then an INDEX clause
|     should be used which is identical to that in the existing table.
|     For example, the relationship between RFC 2233's ifTable and a
|     media-specific MIB which extends the ifTable for a specific media
|     (e.g., the dot3Table in RFC 2358), is a sparse relationship.
|
|(3)  Otherwise, if no existing objects have the required syntax and
|     semantics, then auxiliary objects should be defined within the
|     conceptual row for the new table, and those objects should be used
|     within the INDEX clause for the conceptual row.

I think this particular case, where the table in 3606 has a single object,
is especially clear-cut as falling squarely under 7.8.1 (2).

Randy