Re: action RPC I-D

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

Hi -

> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Vincent Cridlig" <vincent.cridlig@loria.fr>
> Cc: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
> Sent: Monday, October 30, 2006 8:00 AM
> Subject: Re: action RPC I-D
...
> Any RPC method is potentially capable of touching any
> configuration datastore in unknown ways.  Rather than
> define a hard-wired ACM for 7 known RPC methods, I prefer
> to have a more generalized system that handles any RPC and any data.
...

From this I gather that the only way to represent the configuration
(for purposes of disaster recovery, for example) of a system that
supports these RPCs would be to record the sequence of RPCs
over the lifetime of the box so they can be replayed into the new
system.  The alternative would be to retrieve the entire configuration
of the managed system as some kind of checkpoint to minimuize the
number RPC replays required.  Neither approach sounds to me
like a very good way to do real configuration management.

But then, maybe I'm missing something about what edit-config
and its friends really do...

If one knows a system's initial configuration, and has a sequence
of successful edit-config operations, is it possible to compute
the final configuration state (in order to support, for example, 
disaster recovery) without knowing the internals of the system
being configured?

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/>