Subject: [Netconf] Error-Option: why is stop and continue on error mandatory?

From: Balazs Lengyel <[email-masked]>
Date: Mon, 3 Jun 2013 14:36:48 +0200

Hello,
I know I should know this, but ...

Why are the error-option values stop-on-error and continue-on-error 
mandatory? Many of our systems operate on a strict transactional basis, 
you either commit the full edit-config or nothing. Both stop and 
continue imply that you should be able to store a partial transaction. 
Why mess up the configuration if you can do a rollback?
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Jun 2013 10:09:24 -0700

Hi Balazs,

We discussed this exact issue at the test event, and whether
the text was clear or not.  IMO, the error-option parameter
is very system-specific.  Our server works like yours -- you get
rollback-on-error no matter what you choose.  I think the consensus
was that stop-on-error and continue-on-error meant the server was
allowed to do those actions, but it did not have to leave the
config in a partial unknown state (stop) or intentionally leave errors
in the config (continue).  The only robust solution is all-or-nothing
(except for 'rollback-failed' errors).

We support a CLI parameter: --startup-error=stop|continue.
This is another area of contention -- errors loading the running
config from NV-storage. Some devices just prune the error instances
and continue.  Some shutdown and don't attempt to prune errors.

Andy

On Mon, Jun 3, 2013 at 5:36 AM, Balazs Lengyel
<[email-masked]>wrote:

> mandatory? Many of our systems operate on a strict transactional basis, you
> either commit the full edit-config or nothing. Both stop and continue imply
> that you should be able to store a partial transaction. Why mess up the
> configuration if you can do a rollback?
> regards Balazs
>
> --
> ______________________________**_________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>
>

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 10 Jun 2013 17:59:01 +0200

Hello Andy,

Thanks for the info.

For me these seem to be errors in the RFC. If I just read the text,
continue-on-error does not allow roll-back or at least strongly
hints at not doing it.

If I had the time I would consider writing errata about them: to
make them optional.

regards Balazs

.

On 2013-06-06 19:09, Andy Bierman
wrote:

Hi Balazs,

is very system-specific.  Our server works like yours -- you
get

rollback-on-error no matter what you choose.  I think the
consensus

was that stop-on-error and continue-on-error meant the server
was

config in a partial unknown state (stop) or intentionally
leave errors

in the config (continue).  The only robust solution is
all-or-nothing

This is another area of contention -- errors loading the
running

config from NV-storage. Some devices just prune the error
instances

and continue.  Some shutdown and don't attempt to prune
errors.

Andy

On Mon, Jun 3, 2013 at 5:36 AM, Balazs
Lengyel <[email-masked]>
wrote:

Hello,

Why are the error-option values stop-on-error and
continue-on-error mandatory? Many of our systems operate on
a strict transactional basis, you either commit the full
edit-config or nothing. Both stop and continue imply that
you should be able to store a partial transaction. Why mess
up the configuration if you can do a rollback?

regards Balazs

--

Balazs Lengyel                       Ericsson Hungary
Ltd.

System Manager

_______________________________________________

Netconf mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Jun 2013 09:15:42 -0700

Hi,

Keep in mind that error-option was written with the CLI model in mind.
It was intended to allow a server to process the XML in document order
as commands.  It should be deprecated.

Servers that use a transaction model always do rollback-on-error.
The entire request is validated before any of it is applied.
Every patch within the <edit-config> or <copy-config> is a recoverable edit.
Essentially the <commit> operation is implemented for any database write.

I agree that the error-option text might lead people to think it is actually
some sort of a parameter, when in fact it is a server capability instead.
We completely ignore that parameter in our implementation, after checking
it is a valid enum.  You can't ask the server to leave the database
corrupted,
let alone 2 specific ways to leave it corrupted.

Andy

On Mon, Jun 10, 2013 at 8:59 AM, Balazs Lengyel <[email-masked]

> continue-on-error does not allow roll-back or at least strongly hints at
> not doing it.
> If I had the time I would consider writing errata about them: to make them
> optional.
> regards Balazs
>
> .
> On 2013-06-06 19:09, Andy Bierman wrote:
>
> Hi Balazs,
>
> On Mon, Jun 3, 2013 at 5:36 AM, Balazs Lengyel <
> [email-masked]> wrote:
>
>> Hello,