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

[Steve Berl <sberl@cisco.com>]

The original intent of the option was to have behavior similar to Cisco IOS
doing "copy tftp://foo/blah running-config". In this case the configuration
is a list of lines, each represents an atomic configuration change
operation. If one line generates an error we can continue on and execute the
remaining lines, ignoring the error. The idea is that commands that don't
make sense can be ignored, but the ones that do make sense can be applied.

This proves to be a convenient behavior when an existing configuration runs
on a different device than it was originally created for, or when a device
has the software upgraded and some older commands are no longer supported,
or if the line cards in a device have changed so that some interfaces that
were there are now missing.

One of the data models that we are supporting in the Cisco implementation of
netconf is a list of command lines and this same behavior can be maintained
with the ignore-error option.

So, to better define the behavior in the netconf spec we need to be clear
about the errors that we are choosing to ignore. I think that these are the
errors that occur in the processing (not the parsing) of the <config>
element in an <edit-config>.

There's probably a better way to say that.

-steve

On 2/2/06 8:50 AM, "Andy Bierman" <ietf@andybierman.com> wrote:

> Hi,
> 
> We have heard from one implementer that says they cannot
> support the ignore-error <error-option> in the <edit-config> operation.
> Now one more.
> 
> Here is the total documentation on the ignore-error option:
> 
>          ignore-error: Continue to process configuration data on error;
>             error is recorded and negative response is generated if any
>             errors occur.
> 
> 1) How many operators want this option?
> 
> 2) How many vendors are supporting this option?
> 
> 3) What does this option really mean?
> 
>    - ignore malformed XML?
>      Most tools won't do that.  This is not only dangerous,
>      it isn't very easy to do.
> 
>    - ignore missing parameters?  What happens if the <config>
>      parameter is missing?
> 
>    - ignore extra parameters?
> 
>    - use RPC parameters that don't pass the schema validation tests?
> 
>    - ignore access control violations?
> 
>    - ignore lock access violations?
> 
>    - ignore unsupported portions of the config parameter sub-tree?
> 
>    - use parameters that fail the referential integrity tests?
> 
>    - continue to install child nodes of a parent node with errors?
>      (How?)
> 
> 
> IMO, this mandatory feature of the NETCONF protocol is poorly defined,
> hard or impossible to implement, and has no chance of interoperability.
> It needs to be fixed or removed from the protocol.
> 
> 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/>

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