Subject: [Netconf] warnings: retake

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Jun 2010 09:35:49 -0700

Hi,

I am thought a bit more about NETCONF warnings.
We had it all wrong before.  Circa 4741, we were so
clueless we didn't even realize warnings were not
even possible.  (Sounds like a bug to me.)

The notion of returning warnings *with* <ok>
is also somewhat clueless.  It's too late by then
to act on the warnings.

Those annoying warning dialogs that applications
pop up are done before an action, not after.
They are a lot of work to hard-wire in the client,
and it should would be nice if NETCONF servers
helped out.

What is really needed is a bit in the <rpc-error>
to indicate if the error can be ignored, even
though there may be operational consequences,
and another bit in the <rpc> to indicate that
ignorable errors should be ignored or not.

The use-case I have now is a <set-my-session> operation.
A client can set defaults just for that session.
But setting the default 'with-defaults' to something other
than the basic-mode can be dangerous if editing is done
based on data retrieved in another mode.

It is much more scalable to have the server describe its
own set of warnings than hard-wire them into an application.
Right now, there is no way to even return a warning,
so that a client will know to try again.  It will get some
error and cancel the operation in progress.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Jun 2010 09:29:54 -0700

On 06/19/2010 09:35 AM, Andy Bierman wrote:

I guess the WG does not want to consider RPC warnings
further.  (too bad... ;-)

I left out an acceptable solution, which is what Kent is already
doing.  We can just add text to 4741bis that says a server MAY
choose to set the error-severity to 'warning' instead of 'error'.
The error templates just describe the default severity, but the server
can decide if it is a recoverable error or not.

Unless there are any strong objections, I am going to make this edit
to 4741bis.  There is nothing in the 4741 protocol definition that
says a client does not have to be able to handle error-severity='warning'
if the server sends it.  It is just our rigid interpretation of the error
appendix text that is the source of that CLR.

IMO, Kent is not violating 4741 by sending operation-failed
as a warning.  I was wrong before -- a 4741 client MUST be
able to accept error-severity='warning', so this should be a
safe server clarification to make in 4741bis.

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Jun 2010 22:38:17 +0200 (CEST)

Hi,

Andy Bierman <[email-masked]> wrote:
> to 4741bis.

I object.  What exactly does error-tag 'in-use' with severity
'warning' mean?  Or, for that matter, 'operation-failed'?  I think the
severity in the appendix is not just picked at random, but
thought through.

If we need a separate warning tag, we should add that, but this has
been discussed before in the WG, and we saw no consensus on a
solution.  I think you recently said that we need to finish 4741bis,
and not keep debating issues that do not have consensus.

For the record, I would have liked to see a mechanism with warnings
that worked, but as we have seen before in the discussions about
warnings, it is not that easy.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Jun 2010 15:02:01 -0700

> warnings, it is not that easy.

What if it was limited to a new error-tag only in 1.1?
Then it is still up to vendors to use this error-tag.
It will not break any clients because only a 1.1 client can get
a 1.1 session, and only 1.1 servers
would ever send error-severity=warning.

Two people who actually write NETCONF applications
say this is needed.   Vendors will make up their
own solutions, as we have seen, so this standards stuff
is just a formality anyway.

Andy