RE: AUGMENTS clause

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of C. M. Heard
> Sent: Tuesday, January 11, 2005 07:55
> To: Mreview (E-mail)
> Subject: 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.
> 

So I do believe that the atmVclGenSigDescrIndex definition should have
added a DEFVAL { 0 } in that case.

Bert