[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AUGMENTS clause



On Mon, 10 Jan 2005, Randy Presuhn wrote:
> [ Bert Wijnen wrote: ]
> > So, after a quick check of a few document, for example,
> > atmVclGenTable in RFC3606 seems to violate the concept of AUGMENTS,
> > right?
> 
> It's not immediately clear from RFC 3606 how this table is
> actually used, but it looks like you're right.  There seems to
> be some kind of chicken/egg relationship between
> atmSigDescrParamIndex and atmVclGenSigDescrIndex, but it's not
> clear to me how atmVclGenSigDescrIndex gets its initial value
> when an atmVclEntry is created.  This is a great example of
> where a use case or two might make a document much clearer.

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.

One other point to note is that SVCs are not normally set up by
management action ("provisioning") but rather by signalling
initiated by a user of the connection.  In that case the agent will
be the one creating the row.  That's probably why it was not spelled
out in great detail what a manager has to do to create a row that
contains a atmVclGenSigDescrIndex column.  However, if you look at
the DESCRIPTION clause of atmVclEntry I think you can figure out how
to to it (that DESCRIPTION clause does a very nice job of spelling
out the steps for creating a row).  Admittedly this takes a bit of
extrapolation.

//cmh