[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AUGMENTS clause
On Mon, 10 Jan 2005, Randy Presuhn wrote:
> > From: "C. M. Heard" <heard@pobox.com>
> ...
> > The ATM-MIB (formerly RFC 1695, currently RFC 2515) was designed to
> > manage permanent virtual connections (PVCs). Switched virtual
> > connections could be represented, but "full management of SVCs may
> > require additional capabilities which are beyond the scope of this
> > memo". RFC 3606 contains the extensions that allow SVCs to be fully
> > managed. The atmSigDescrParamTable contains signalled parameters
> > that are relevant for SVCs but not for PVCs.
> >
> > A manager designed to work entirely within the scope of RFC 2515
> > (i.e., no proprietary extensions) would be able to set up PVCs by
> > creating the appropriate objects. It could continue to do so as it
> > always had done if it encountered an agent that supported RFC 3606,
> > because the additional objects -- i.e., atmVclGenSigDescrIndex and
> > the row instance it points to -- are not needed and are not
> > instantiated for a PVC.
> >
> > So, I don't think that there is anything troublesome about this
> > augmentation.
>
> 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.
I have gone back and re-read RFC 3606 and my description above
appears to be mistaken. The SYNTAX of atmVclGenSigDescrIndex is
AtmSigDescrParamIndex, which is defined thusly in RFC 2514:
AtmSigDescrParamIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of this object identifies a row in the
atmSigDescrParamTable. The value 0 signifies that
none of the signalling parameters defined in the
atmSigDescrParamTable are applicable."
So, an agent that implements the atmVclGenTable _would_ instantiate
atmVclGenSigDescrIndex but would give it the value zero. And it is
obvious (to me, anyway) that setting atmVclGenSigDescrIndex to zero
is the correct way for an agent to interwork with a manager that
populates only the base row varbinds in a SetRequest-PDU.
Having said that ...
> 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).
It may be clear-cut, but it is a CLR.
From reading Section 7.8 of RFC 2578, particularly this --
| [ ... ] instances of subordinate columnar objects of a
| conceptual row augmentation exist according to the same
| semantics as instances of subordinate column objects of
| the base conceptual row being augmented. As such, note
| that creation of a base conceptual row implies the
| correspondent creation of any conceptual row augmentations.
it has been my understanding that the intent behind the "AUGMENTS"
keyword is to be able to say compactly that "this row is a logical
continuation of that one". In other words, putting a column in an
augmenting table should be semantically equivalent to putting it in
the base row. Now, nothing in the SMIv2 rules that I know of
forbids me from adding to a read-create base row a single column
that is instantiated only under certain circumstances. But a strict
reading of the 1:1 relationship rule means that I am not allowed to
put that column by itself in an augmenting table, even though I want
to inherit the RowStatus (and possibly StorageType) columns from the
base table. I would have to use an INDEX clause and words in the
DESCRIPTION clause. That seems needless and arbitrary to me.
However, as editor of the MIB review guidelines document, I have to
confess to propagating this CLR in the following text in sec. 4.6.4:
- 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.
It's easy enough to get around this CLR, but I wonder if it might
not be wise to change the MUSTs in the above paragraph into SHOULDs.
Mike