See my response to Phil. I propose that the errors that are "ignorable" be
part of the description of the data model as the behavior seems to be
coupled to the contents of the <config> element.
I think we have the same problem with "stop-on-error" as we do with
"ignore-error". In either case there is a partial success and partial
failure of the request. How can we stop-on-error how do we know which parts
of the request worked and which didn't get executed? It is specific to the
data/processing model that is being used.
The whole idea of the error-option depends on the notion that there are
multiple atomic operations described in the <config> element, and that some
may succeed and some may fail. The order in which these atomic operations
are to be attempted may be specified in the content of the <config> element,
or not. In the <cli> case below, the boundaries and order of the atomic
operations is pretty clear. In some other data models it might not be as
obvious, but they may still be there. In order for there to be any way to
understand the meaning of the stop-on-error and ignore-error options the
boundaries of the atomic operations need to be understood.
See some other comments below.
On 2/2/06 10:48 AM, "Andy Bierman" <ietf@andybierman.com> wrote:
Steve Berl wrote:
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.
Are you talking about simple XML-ifies CLI?
<config>
<cli>blah-blah</cli>
<cli>blah-blah</cli>
</config>
This is a trivial case.
It is a simple data model, yet we do support this in our implementation. It
is very useful considering the existing base of tools and knowledge that
understand the CLI.
Real XML data models are not so easy to implement for this feature.
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.
I understand the intent of the feature.
I don't think it is specified in a manner that will
allow developers to create interoperable implementations.
I agree. The behavior is specific to the data/processing model that is being
used.
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>.
I think you mean the application of config changes.
If a config change passes all tests then apply it,
otherwise go on to the next config change.
I think that's what you mean.
Yes. I think that is a better way to say it.
Just because an operation parses doesn't mean resources like locks
are free, or access control rules are met.
There's probably a better way to say that.
The problem with this feature is that netconf is not a CLI.
There is no concept in netconf that the XML payload within
an <edit-config> operation is serialized into an integral number
of "lines". "When an error occurs, continue to the next line"
does not mean anything in XML.
Well, the netconf protocol is supposed to be agnostic to the data/processing
model, so it should be able to work for a model that consists of a list of
text commands that are executed in order.
Support of this feature requires a lot of custom work,
and prevents widely available validation tools from being
used (because they validate an entire sub-tree or nothing).
This is back to the definition of what errors are "ignorable". If we say
that errors that are detected in the XML validation are not ignorable, but
those detected in the application of the configuration changes are
ignorable, then this is no problem. If a particular data model definition
wants to say that no errors are ignorable, then that is fine also.
You can't even say "on error continue at the next sibling node"
because that isn't always true. All you can say is "it is an
implementation-specific matter if and where processing
of the <config> sub-tree will continue after an error is
encountered."
IMO, this means "no interoperability whatsoever".
Unless there are interoperable data models, their wasn't any
interoperability at this level anyway.
-steve
Andy
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/>