Subject: action RPC I-D

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Oct 2006 13:59:47 -0700

Hi,

Balazs Lengyel has written a brief draft for a Generic Action RPC:

http://www.ietf.org/internet-drafts/draft-lengyel-action-rpc-00.txt

I think this might be relevant to our initial data modeling efforts,
and possibly the Notifications work as well.

First, the WG needs to decide how it wants to add features (as extensions)
to the protocol.  I am personally less comfortable with an ad-hoc,
approach than a designed approach.  Notifications were left over
from the initial charter, not really an add-on.

Why is this new special standard RPC method needed?
What increased multi-vendor interoperability does it provide?
What exactly is an "action"?
It is not defined in this document.

I know "reboot" is an action.
What about "save and reboot" (which changes
config and then does an action)?

IMO, the agent and manager MUST know the security and
other requirements a priori anyway (via a schema), so
some generic 'container' for actions does not provide any
real value -- just extra XML.

In your 'restart' example, 'actionName' could just as well be
the actual RPC method name, and 'callingPoint' is really
just an RPC parameter, along with the entire 'parameters' sub-tree.

How do you manage the allocation of action names?
You propose just xs:string as a data type, and all these
unbounded strings are in the NETCONF namespace.
This implies the WG is going to define the contents,
but that is not stated in the draft.

Do we really need a standard "action" RPC method container,
without defining any actual standard actions?

thanks,
Andy

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

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Fri, 13 Oct 2006 14:41:22 -0700

Why wouldn't we define standard actions? Seems like there are several the
would be useful. Off the top of my head

- reboot
- file system operations such as:
    - copy
    - delete
    - rename
    - erase/format
    - mkdir
- ping
- traceroute

-steve

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Oct 2006 15:01:36 -0700

> - file system operations such as:

I agree.
But we don't need an extra wrapper to define this.
I.e.

<rpc>
   <ping>
     <parm1>...
     <parm2>...
   </ping>
</rpc>

vs.

<rpc>
   <action>
     <actionName>ping</actionName>
     <parameters>
       <parm1>...
       <parm2>...
     </parameters>
   </action>
</rpc>

Andy

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Fri, 13 Oct 2006 16:22:20 -0700

I agree. I misunderstood which part you were objecting to.

-steve

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 16 Oct 2006 10:44:30 +0200

Hello,
I completely agree that there might be standard actions later, but my basic premise is 
that there will always be vendor specific actions as well. Just as I don't believe we can 
ever FULLY standardize the data model, the same way I believe we will never be able to 
standardize all actions.

I believe handling non-standard actions is easier if we define them in the data model and 
not as separate operations. It particularly helps intermediate SW to handle the actions. I 
agree with Andy that the "end-user" of the action must always understand all new actions 
whatever the form used to transfer them. However there may be, there will be a number of 
intermediate SW blocks on the path.

I gave a few examples in the draft of intermediate SW, but just as one more possibility to 
consider, think about the recent sub-agent draft and it's proposed architecture. The 
master-agent would also delegate the handling of some RPCs to other SW entities. With the 
generic action it just has to check the calling-point and can forward the action.

Also we have already know of working examples of this construct:
- LDAP extended operations
- Ericsson has a Netconf implementation that misuses the <get> operation to achieve just 
the same result
- Ericsson has a number of other implementations based on other protocols

For all these reasons I would ask the workgroup and it's chairmen to consider adopting the 
topic.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 16 Oct 2006 11:08:18 +0200

Hello,

> It is not defined in this document.
[BALAZS]: An action could be basically any management operation. I propose 2 cases when 
actions are really useful (from the draft):
1) "operations that do not change the configuration data (e.g. ping)"
2) "reading or writing a set of data that form a logical group but might be scattered in 
different parts of the management data model."
For number 1) I interpret your comment as I should have written: "operations where the 
main aim is an effect that does not change the configuration although the configuration 
might be changed as a secondary effect."

Naturally if you want to misuse action, you could do a <balazs-get> action. However you 
can misuse all other Netconf operations as well, so this is nothing new.
I believe it is impossible to give an exact, precise rule that can not be misinterpreted 
about when to use actions.
> just an RPC parameter, along with the entire 'parameters' sub-tree.
[BALAZS]: You are right, this is also possible. However, I try to say that doing it as a 
generic action will spare us some problems, work specially with intermediate SW and vendor 
specific actions.
> but that is not stated in the draft.
[BALAZS]: Good question, sorry for omitting it. Just some initial ideas:
- some other RFCs state that vendor specific extensions should be based on DNS types names 
to avoid conflicts.
> without defining any actual standard actions?
[BALAZS]: generic actions are aimed specifically for management commands that we do not 
standardize. For standardized commands we still might chose between putting them into 
generic actions or making them into separate operations. (But I do not want to open this 
debate, I just say that the options remain open.)

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2006 12:58:30 +0200 (CEST)

> just an RPC parameter, along with the entire 'parameters' sub-tree.

and 

Balazs Lengyel <[email-masked]> wrote:
> I believe handling non-standard actions is easier if we define them
> in the data model and not as separate operations. It particularly
> helps intermediate SW to handle the actions. I agree with Andy that
> the "end-user" of the action must always understand all new actions
> whatever the form used to transfer them. However there may be, there
> will be a number of intermediate SW blocks on the path.

I also agree that a data model effort should allow for operations to
be defined within the data model.  However, how this is mapped to
Netconf rpcs is a different question.  An operation could be mapped to
a generic <action> rpc, or to a new rpc for each action.

I agree with the "intermediate SW argument" though.

> real value -- just extra XML.

We could apply this argument to e.g. edit-config - why is edit-config
needed at all?  Vendors could define their own <edit-bla-bla> rpcs, and
the <target> could have been some parameter (possibly different
paramtere names all the time) in <edit-bla-bla>.

> How do you manage the allocation of action names?

Without a <action> wrapper each operation name would have to be unique
per namespace.  With an <action> rpc, the operation could be
identified with an "OID" and the action name, which could be a subtree
expression or a XPath expression (such as
/interfaces/[ifIndex="2"]/reset).  This means that the action name
would be unique per "object".  The callping-point parameter would not
be needed in this case either.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 06:32:59 -0700

> I agree with the "intermediate SW argument" though.

Why?
This seems like an implementation-specific detail to me.
Your access control model should be more robust than
simply allowing user X to do anything called <action>.
I don't see what benefit an intermediate SW component
can realize if an extra generic container is added to <rpc>.

> per namespace.  With an <action> rpc, the operation could be

This is not true.
The WG or any vendor could put multiple elements in the
same namespace, just as we have <edit-config> and <copy-config>
in the same namespace now.

> be needed in this case either.

Why should action RPCs be identified differently than other RPCs?
This seems to create complexity, not reduce it.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2006 16:19:41 +0200 (CEST)

> This seems like an implementation-specific detail to me.

Yes, since the argument is that it might be easier to
design/implement/envision intermediate SW components if the structure
of the rpc is well-known; I guess this argument can be rejected as
being an implementation issue.

> can realize if an extra generic container is added to <rpc>.

I didn't think of the access control model, but maybe that is a good
example.  It will be more complicated to design an ACM which has to look
into any nested XML structure for a parameter in some format which
points to an object.

> in the same namespace now.

I didn't say that there could be a single operation per namespace, I
said that the operation name has to be unique within it's namespace.

> This seems to create complexity, not reduce it.

It's not identified differently, I wasn't clear - I meant something
like this:

  <action xmlns="...generic-action/1.0">
    <name>/interfaces[ifIndex="2"]/reset</name>
  </action>

more of an OO style I guess - execute the 'reset' action on the
'/interface[ifIndex="2"]' object.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 16 Oct 2006 10:45:08 -0400

>'/interface[ifIndex="2"]' object.

We have a rich history of failed OO-ish approaches.  IMHO the
key to netconf lies in leveraging the existing infrastructure
of existing CLIs.  CLIs are not oriented toward this sort of
approach, but use more direct action verbs:

    reset interface 2
    ping foo.net
    reboot
    install new-sw.tgz

which translate easily into direct RPCs:

    <rpc ...>
      <ping>
        <target>foo.net</target>
      </ping>
    </rpc>

Options from the "ping" command become xml elements under the
<ping> element.  Imagine trying to encode options under a
string like "/interfaces[ifIndex="2"]/reset".

In addition, using a string loses all the specificity that
an XML schema tries to buy you.  Your only tool to restrict
the content of a string is a regex, which, well, stinks when
compared with the descriptive capabilities of schema for
a <ping> element and its contents.

>being an implementation issue.
 
Let the schema (or whatever your schema is generated from) drive
your intermediate SW components.  If your command hierarchy (and/or
config hierarchy) drives your xml content, then the same internal
data can drive it all.  XML schemas, XML parsers, and command parsers
all groking the same data will help keep the schema, API, and CLI
in sync.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2006 18:40:21 +0200 (CEST)

> string like "/interfaces[ifIndex="2"]/reset".

This string is just to identify the action.  In Balazs' draft, this
identifier is split into two parts, the <calling-point> and the
<name>.  Parameters are passed with in <parameters> element in his
draft.  They would not be "encoded" into the action name.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 16 Oct 2006 12:49:38 -0400

>draft.  They would not be "encoded" into the action name.

Okay, an action has a name, a target, and a set of parameters.
Your suggestion puts the name and the target in a string which
is uncontrolled and undocumented (as far as schema).  Putting
the parameters in an element won't help you constrain them,
since the constraints need to be tied to the particular action.

So the question is: what does a generic <action> action buy you?
And are you trade that against what a schema-friendly RPC buys you?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2006 19:43:51 +0200 (CEST)

> since the constraints need to be tied to the particular action.

No, they wouldn't be uncontrolled, just as parameters within an
edit-config are not uncontrolled.

But anyway, I just said that I do agree with the "intermediate SW
argument", i.e. using a well-known <action> rpc might make it easier
to write this kind of software.

As an example, suppose you have a set of hosts, each with a set of
services, and a service can be reset.  Using a normal rpc, this reset
could be:

  <reset-service-in-host>
    <host>foo</host>
    <service>web</service>
    <when>now</when>
  </reset-service-in-host>

Using the <action>, with Balazs syntax,

  <action>
    <callingPoint>/hosts/host[name="foo"]/service[name="foo"]</callingPoint>
    <name>reset</name>
    <parameters>
      <when>now</when>
    </parameters>
  </action>

My only point is that the latter might be easier for a SW component
like a master agent.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 11:00:14 -0700

Martin Bjorklund wrote:
>...

> My only point is that the latter might be easier for a SW component

IMO this is an implementation choice.
I prefer the former approach because I already have
SW components that auto-generate PDU fragments based
on the <rpc> element in the existing netconf-prot document.
Plus, the less XML layers the better.  I also agree with Phil
that the <rpc> version is more XSD-friendly.

Some people prefer not to couple all the 'action' RPC implementation
details together.  Others may prefer a common gateway approach.
The <reset-service-in-host> RPC method could use internal (implementation
specific) mechanisms to convert the XML parameters to different forms.
Exposing the complex <action> RPC to managers seems to make things
harder on the manager than the <reset-service-in-host> version in your example.

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 16 Oct 2006 16:29:21 -0400

Hi,

At the IAB Workshop, one of the strong points was that operators want
to be able to "read" the content on the wire. Adding such regex
formatting will make the content much less human-friendly.

I think the action increases the difficulty of access control
specification, and increases the likelihood of non-interoperable
commands.

I prefer to not have the action layer. I don't see adequate benefits
to justify the added complexity. 

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Monday, October 16, 2006 2:00 PM
> To: Martin Bjorklund
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: action RPC I-D
> 
> Martin Bjorklund wrote:

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Oct 2006 10:51:20 +0200 (CEST)

"David B Harrington" <[email-masked]> wrote:
> to be able to "read" the content on the wire.

Ok.

> Adding such regex

It's not regex, it's the Instance Identifier syntax (XPath) that Andy
proposed.

> specification,

Why?  I think it actually might be easier to do access control, since
the ACM can look at the callingPoint and name to find the operation,
without knowing anything about the schema.  In the
<reset-service-in-host> example, the ACM would have to understand the
schema to realize what the parameters <host> and <service> actually
mean.

/martin

> and increases the likelihood of non-interoperable
> commands.
>

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 27 Oct 2006 16:53:20 +0200

Hello,
You are right, we need access control.

For this reason each action defined in the data model should be defined as 
read/write/disturb-traffic.
read: it only reads configuration and state data and doesn't effect the traffic
write: it writes configuration data, but does not disturb the traffic
disturb-traffic: means it can do anything.

One can debate that these are the good categories for access control. Still the basic 
statement is that for each action defined in the data model you need to specify it's 
access properties in the data model as well.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 27 Oct 2006 17:06:25 +0200

Hello,
You could just as naturally map CLI commands into actions, see below.
Some of the intermediate entities might not want / not need to understand the full data 
model, like in the sub-agent architecture, etc.
Balazs

      <action>
        <actionName>ping</actionName>
        <callingPoint type="xpath">
          /top/interfaces/interface["ifName=eth0"]
        </callingPoint>
        <parameters>
          <target>foo.net</target>
        </parameters>
      </action>

> a <ping> element and its contents.
Thats why I lifted out callingPoint. Also I agree that even for other parameters we should 
not encode multiple data items in one string.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 27 Oct 2006 17:30:57 +0200

Hello,

> formatting will make the content much less human-friendly.
You do not need regexp formating for action. I put in callingPoint just to avoid this. 
Where do you see regular expressions in the draft?
> specification, and increases the likelihood of non-interoperable
I believe that there will always be vendor specific actions as there are vendor specific 
CLI commands today. For me the question is really just how to handle them? <action> 
operation or new operation every time. If you have an <action> operation defined in the 
data model then at least you have a place to put the access control information (in the 
DM). How does using separate new operations defined in  a non machine digestible document 
make access control easier ?
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Oct 2006 08:37:27 -0700

Balazs Lengyel wrote:
> For this reason each action defined in the data model should be defined 
> as read/write/disturb-traffic.

IMO, a clean access control model for NETCONF need to recognize
the RPC model and the configuration datastore architecture.

First, there is the RPC method, defined by a QName.
The user must have access to invoke the RPC method.

Completely independent of that is the data access control model
applied to all configuration datastores.  The NETCONF operations
are create, delete, merge, and replace.  For access control purposes,
merge and replace operations are treated as a 'create' if the target
data instance does not exist.

The granularity could be a coarse as read/write, but that would
totally defeat the purpose of create and delete operations in
the edit-config method.  An access control that matches the
capabilities of the protocol needs to include read/write/create+delete
as the 3 levels of data access (4 if you count 'none').

It makes no sense to have an 'exec' or 'disturb-traffic' access
control classification in the data space.  Either the user can
invoke the RPC method or not.  Remember, it is the PROTOCOL that
needs an access control model, not blobs of XML.  IMO, focusing the ACM
on the XML is the wrong approach.

> 
> One can debate that these are the good categories for access control. 
> Still the basic statement is that for each action defined in the data 
> model you need to specify it's access properties in the data model as well.
> Balazs
> 
> Andy Bierman wrote:

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Oct 2006 08:15:17 -0700

> disturb-traffic: means it can do anything.

I prefer these well-known hierarchical enumerations for max-access:

    read-only       (read or notify)
    read-write      (all operations except create & delete)
    read-create     (all access)

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 27 Oct 2006 17:20:40 +0200

Hello,
Action is just as schema-friendly as defining separate RPCs.

What we gain with <action> is a guarantee that 2 bits of data callingPoint and actionName 
are always present.
We also gain a non-mandatory recommendation that the data model should define additional 
data like: access control behavior (read/write/disturb-traffic or some other values), the 
exact parameter types, default values etc.

We believe that there are intermediate protocol handling entities that actually don't need 
to know more then the actionName and the callingPoint so they will not need to handle the 
complete data model.

Action also gives the possibility to make some syntax checks on an incoming action based 
just on the data model without understanding what the action actually means. (parameter 
checks, value ranges etc.)

Balazs

PS. You will also make some companies (for example but not only Ericsson) happy that 
already use similar constructs, and you won't disturb others as they don't have to use this.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 27 Oct 2006 17:24:26 +0200

OK, I can agree with that.

But still I feel that the data model is not a bad place to put this access control data. 
If we use individual new operations for such vendor specific actions instead of generic 
<action> where do you put this data? If you put it in a document describing the related 
capability that will be unusable for machines.
Balazs

Andy Bierman wrote:
>> For this reason each action defined in the data model should be 
>> defined as read/write/disturb-traffic.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 27 Oct 2006 16:59:28 +0200

> being an implementation issue.
Yes it is an implementation detail, as everything else. However by ensuring that a number 
of data items are present in any such new RPC/action, and ensuring that they are present 
as separate easily recognizable bits of data we make implementation a lot easier.
Imagine some RPCs carrying the calling-point in one place other in another place.
Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 28 Oct 2006 16:15:51 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> the edit-config method.

Why?  The operation 'delete' is needed in order to be able to delete
stuff.  The access control can still be read/write - if you have write
access you're allowed to create/delete.

NOTE: I'm not saying that it *should* be just read / write, I'm just
questioning the logic in the argument.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 28 Oct 2006 10:01:42 -0700

> access you're allowed to create/delete.

delete fails if the object is not there to delete
create fails if the object is already there.

The point of adding these extra enums (besides the CLI style
merge and replace) was to make it a bit harder to inappropriately
add or delete data to the configuration.  It follows that
the access control model would distinguish between changing
existing data and add/delete operations as well.

Andy

---

From: Vincent Cridlig <[email-masked]>
Date: Mon, 30 Oct 2006 09:01:31 +0100

> on the XML is the wrong approach.

I don't really agree with this. When you define an access control model, 
you have to define permissions as a (action, resources) combination set. 
I think it is not possible to define permissions without a way of 
addressing data (XML-based or not). The ACM is usually strongly 
dependant on the data model. I don't understand what kind of access 
control policy you can specify if you don't consider the data but only 
the RPC ? Can you please give an example ?

Also a clear distinction between Access Control Model (which specifies 
who can do what), and supported operations (this data is writable or 
readable or both, ...) must be done. These are totally different 
concepts and sometimes I get confused when reading the messages.

IMO, a (read, write) based model is sufficient for access control. While 
"read" implicitely includes get, get-config, "write" implicitely 
includes edit-config (and its sub-operations), copy-config (write on the 
root node) and delete-config (write on the root node). If you define 
access control by RPC, you will need later to redefine access control on 
data: and that will be a two-levels access control which is hard to 
maintain and not necessary.

I think the distinction between create and write is not necessary. For 
example, in a table, you can give create access by allowing write access 
on the table. You can give update access by giving access to some 
particular entries in the table.

Regards,
Vincent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Oct 2006 02:45:32 -0800

> the RPC ? Can you please give an example ?

<ping> or other action RPCs

> particular entries in the table.

I don't think this actually works well if you have
nested read-create data structures, where the instances
are dynamic, and not statically assigned.

But I don't mind if the model starts simple and gets refined later.

Andy

---

From: Vincent Cridlig <[email-masked]>
Date: Mon, 30 Oct 2006 15:16:50 +0100

Andy Bierman a écrit :
>> I don't really agree with this. When you define an access control 
>> model, you have to define permissions as a (action, resources) 
>> combination set. I think it is not possible to define permissions 
>> without a way of addressing data (XML-based or not). The ACM is 
>> usually strongly dependant on the data model. I don't understand what 
>> kind of access control policy you can specify if you don't consider 
>> the data but only the RPC ? Can you please give an example ?
>
>

Ok but these RPCs are not some of the regular operations of the Netconf 
draft !

To counterbalance the previous comments, it could be possible to specify 
an ACM with RPCs if the operations are specialized like get-interface or 
set-route-map. The granularity would be very large in that case but 
possible. But Netconf chose to have generic operations (get, edit) with 
parameters and therefore needs the protected resources locations as part 
of the ACM.

Regards
Vincent

>
>>
>> Also a clear distinction between Access Control Model (which 
>> specifies who can do what), and supported operations (this data is 
>> writable or readable or both, ...) must be done. These are totally 
>> different concepts and sometimes I get confused when reading the 
>> messages.
>>
>> IMO, a (read, write) based model is sufficient for access control. 
>> While "read" implicitely includes get, get-config, "write" 
>> implicitely includes edit-config (and its sub-operations), 
>> copy-config (write on the root node) and delete-config (write on the 
>> root node). If you define access control by RPC, you will need later 
>> to redefine access control on data: and that will be a two-levels 
>> access control which is hard to maintain and not necessary.
>>
>> I think the distinction between create and write is not necessary. 
>> For example, in a table, you can give create access by allowing write 
>> access on the table. You can give update access by giving access to 
>> some particular entries in the table.
>
>>>> One can debate that these are the good categories for access 
>>>> control. Still the basic statement is that for each action defined 
>>>> in the data model you need to specify it's access properties in the 
>>>> data model as well.
>>>> Balazs
>>>>
>>>> Andy Bierman wrote:

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Oct 2006 08:00:22 -0800

> Ok but these RPCs are not some of the regular operations of the Netconf 

The protocol defines an RPC mechanism,
and then later defines RPC methods in the netconf-base namespace.
Just as the VACM can be used in SNMP for MIB objects defined
in the enterprise OID tree, the ACM for NETCONF must work
for any RPC method in any namespace.

> parameters and therefore needs the protected resources locations as part 

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.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 30 Oct 2006 12:56:08 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Vincent Cridlig" <[email-masked]>
> Cc: "'Netconf (E-mail)'" <[email-masked]>
> Sent: Monday, October 30, 2006 8:00 AM
...
...

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