Subject: Error-option in copy-config

From: Vincent Cridlig <[email-masked]>
Date: Wed, 25 Oct 2006 15:57:45 +0200

Hi,

Why is there no error-option in the copy-config operation ?
What should we do if an error occurs ? rollback everything, continue or 
just stop ?
I think this information is not mentionned in the draft.

Thanks,
Vincent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2006 08:56:25 -0700

> I think this information is not mentionned in the draft.

I don't know, but the <rpc-error> element(s) you return the copy-config
reply should reflect what actually happened.  It's not clear to me
that copy-config should have as many bells and whistles as edit-config.

> Vincent

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: Cridlig Vincent <[email-masked]>
Date: Wed, 25 Oct 2006 20:16:55 +0200

I ask that because we have a "MIB module"-based approach and modules 
sometimes reply with error during copy-config.
So, for us, it is exactly the same situation as edit-config.

Can you give us an advice to deal with such a case ?

Regards
Vincent

Andy Bierman a écrit :
>> What should we do if an error occurs ? rollback everything, continue 
>> or just stop ?

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2006 11:56:58 -0700

> So, for us, it is exactly the same situation as edit-config.

I have an "application parameter set" approach this is probably
very similar.  IMO, you can pick values for the error-option
and test-option, etc. outside the standard (any way you want).

Your MIB module probably defines the conceptual boundary for continue-on-error
semantics.  I use the parameter set as the boundary, and an application
can have an arbitrary number of data types, parameter sets, RPCs, and notifications.
An application is something like netconfd, security, routing, interfaces, etc.
A parameter set could represent a sub-system within the application, or
simply a grouping based on functionality (just like MIBs).  If any
errors occur within a particular parameter set in a PDU, then
that set is not applied (continue-on-error), and processing skips
to the next parameter set.  Errors get recorded along the way.
For other error-option enums, the boundary does not matter.
First error during apply phase causes an early exit (stop-on-error)
or a recover-and-exit (rollback-on-error).

I use a multi-pass agent architecture, so any PDU is fully validated
before any destructive phase is started.  The continue-on-error
option only matters when a parameter set 'apply' phase operation
fails (no resources usually).  Otherwise there is nothing to back out.
Continue-on-error will allow the manager to force sections that
validated okay to be applied, while skipping the sections that didn't.
(Reminder: continue-on-error *never* means "apply these parameters
even if they are invalid".)  The 'validate' phase attempts to parse
through the entire PDU and collect as many rpc-errors as it can.

Andy