Re: Separation of configuration and control - good or bad?

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

Hi -

> From: "Larry Menten" <lmenten@lucent.com>
> To: "netconf" <netconf@ops.ietf.org>
> Sent: Friday, May 16, 2003 9:29 AM
> Subject: Re: Separation of configuration and control - good or bad?


...
> I'd say that that captures the difference.  The Enns model is one in which
> configuration is expressed as the transformation of a document.  This is why
> you must lock the document before you operate on it.  There is a race
> condition
> between the get_configuration and the load_configuration.
>
> I prefer a model in which you explicitly name the target of the
> operation and
> you provide only that data relevant to the operation.  The Enns document
> uses
> "replace" to delete an element, requiring that all of the siblings of
> the deleted
> element must be provided in the transaction even though the intention is
> not to
> modify them.  Futhermore, you must now verify that those sibling trees
> to not also
> express a configuration change. More unneccessary processing in the agent.
>
> Seems to me that that is a very indirect way to manage a device.
...

This leads back to the question of whether the "definitive" configuration
is what's in the device at the moment.  The document-oriented model
makes more sense if one thinks of the desired ("definitive") configuration
data as not necessarily residing on the device, and which is delivered /
applied to the device as needed.  (Push and pull both work.)   The protocol
will have a big impact on how much work it is to identify and inform the device
about the relevant deltas.   It may make sense to distinguish manipulation of
configurations (as documents) from the process of delivering or applying
them to a device even more than we're already doing (perhaps not consciously).

Randy



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>