Re: problems with 'ignore-error' <error-option>

[Andy Bierman <ietf@andybierman.com>]

Steve Berl wrote:
> I think I agree with you completely.
>
> It would be clearer if the choices were "stop-on-error",
> "continue-on-error", and "rollback-on-error". I'll leave it up to the editor
> and WG chair to decide whether to change it or not.
>
>   

I don't mind.  IMO, "ignore-errors" is really confusing.
It's not in the form of an action to take when an error occurs,
like the other 2 choices.

A NETCONF data model should describe its referential integrity
requirements somehow, so that implementers know which instances
of which objects are conceptually coupled.  It does not need to
describe any error-option specific behavior.

The real issue is not how agent implementers will deal with this,
but rather "will applications get consistent error info for
the same set of conditions from one agent to another?"

> The text should also make clear that these only apply to errors in applying
> the changes described in the <config> element. Errors outside of the
> <config> element are real errors in the use of the netconf protocol and
> cannot be ignored. The result should be no change to the device
> configuration.
>   

Can we say "application layer errors within the <config> element."?
Does that cover it?

Also:

"It is a data-model specific matter how an agent divides
an <edit-config> operation into sub-operations
for the implementation of the 'stop-on-error' and 'continue-on-error'
error-option values.  If one or more of the sub-operations
completes, but one or more sub-operations does not complete (due
to errors), then the agent MUST return a 'partial-operation' error tag
in the <rpc-reply>."



> -steve
>   
Andy


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