Subject: [Netconf] warnings

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Nov 2009 18:58:52 +0900

Hi,

I am wondering: was the idea behind warnings to use them for sucessfully
completed operations? If not, warnings don't make much sense to me.

I guess warnings could be useful together with a capability that allows
for confirming a previously issued operation which the server classifies
as potentially harmful, like changing the IP address that is used for
the current session.

Other than that, warnings belong to notifications.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2009 11:07:40 +0100 (CET)

> as potentially harmful, like changing the IP address that is used for

I agree that this would be useful - "If you make this change your
users will experience severe service disruption - are you sure you
want to continue?".

But that can never have been the intention with the current protocol.

Hmm.. this could probably be added in a backwards compatible way, but
I'm not sure it is worth it.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 9 Nov 2009 10:38:23 -0500

>I'm not sure it is worth it.

Warnings are meant to give information that the user or client
might need, but won't stop the device from doing as told.  For
example, if you are installing a software image that requires
a reboot, a warning can announce this to the user.

What NETCONF got wrong IMHO is that warnings are a classification
of errors, so attempting to give a warning is really giving an
error, which isn't acceptable.  We had <warning> and <error> as
distinct tags at one point, but collapsed the two ideas into a
meaningless mush.

As it sits, warnings are unusable.  Can we repair them?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Nov 2009 08:37:27 -0800

> As it sits, warnings are unusable.  Can we repair them?

I do not see how they can be repaired in a backward-compatible
way.  Existing clients see <rpc-error> instead of <ok>
and that is it.  I doubt any clients check all the error-severity
fields, see they are all warnings, and treat that as an <ok>.

For example, introducing an <rpc-warning> element will
break old clients talking to new servers.  I prefer
not to do that.

The problem is that the protocol defines <ok> OR <rpc-error>,
but never both -- and clients rely on this fact.
Also, the hard-wired list of error-tag values are
defined to all have error-severity=error.

I don't think the standard will ever use warnings.
Even the use-case above is not a real warning.   It is just
part of the object behavior, as defined in the description-stmt.
A warning is needed when something not defined in the YANG module
happens during the server response.

>  Phil

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2009 19:03:16 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> way.

I can see how we could introduce the kind of warnings that Lada
mentioned (i.e. make it possible to continue an operation after a
warning) but not the "info" warning that Phil wants.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 9 Nov 2009 13:09:50 -0500

>but never both -- and clients rely on this fact.

Add <rpc-warning> that can exist with <ok/>.

>happens during the server response.

Such as "you asked me to do something and I did but here's something
you should know" (like "you need to reboot now").

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Nov 2009 00:48:57 +0100 (CET)

> Add <rpc-warning> that can exist with <ok/>.

But that would be an incompatible change, i.e. it might break
existing clients.  I don't think we should do that in this case.

/martin