Subject: [Netconf] NETCONF warnings

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Oct 2015 13:28:35 -0700

Hi,

The issue of warnings keeps coming up with customers.
Technically, there are no error-tags that have an assigned
error-severity of 'warning'. The <rpc-error> message is
supposed to use 1 of the standard error-tags.

So how should the server send warnings in NETCONF?

 A) new message like <rpc-warning>
 B) new error-tag with assigned severity 'warning'
 C) pick an existing error-tag to allow as a warning
 D) allow any error-tag to be severity warning
 E) something else?

Andy

---

From: t.petch <[email-masked]>
Date: Sat, 3 Oct 2015 12:34:08 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Netconf" <[email-masked]>
Sent: Friday, October 02, 2015 9:28 PM

>  D) allow any error-tag to be severity warning

Depends what you mean by a warning.

I have worked with manufacturers that have a clearly defined hierarchy
of, say, four levels of result, of which warning is one.  Other
manufacturers take a different view.  Another slant on this is the
various return codes of e.g HTTP.

So first I would like the semantics of 'warning' clarified, then I can
make an informed choice.

Tom Petch

> Andy

------------------------------------------------------------------------
--------

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 3 Oct 2015 07:32:30 -0700

---

From: Andy Bierman <[email-masked]>
Date: Sat, 3 Oct 2015 07:38:14 -0700

Hi,

The RFC sways almost nothing about it:

  error-severity:  Contains a string identifying the error severity, as
      determined by the device.  One of:

      *  error

      *  warning

      Note that there are no <error-tag> values defined in this document
      that utilize the "warning" enumeration.  This is reserved for
      future use.

There is no definition of a warning in the RFC.
That would be up to each vendor or would require the WG to
define a warning.

Currently, the <error-severity> field is just a waste of bandwidth.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Oct 2015 18:53:38 +0000

The general definition is "error" means the process did not complete whereas "warning" means the process completed with issues.   That said, I'm unsure what happens for continue-on-error:

         continue-on-error:  Continue to process configuration data on
            error; error is recorded, and negative response is generated
            if any errors occur.

A negative response sounds like an <rpc-error> (since we don't have an <rpc-warning> yet), but I don't see which error-tag would be used for it.   If it's not defined, maybe we use and <rpc-warning> for it instead?

Kent

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Saturday, October 3, 2015 at 10:38 AM
To: "t.petch" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] NETCONF warnings

Hi,

      *  error

      *  warning

Andy

On Sat, Oct 3, 2015 at 4:34 AM, t.petch <[email-masked]<mailto:[email-masked]>> wrote:
----- Original Message -----
From: "Andy Bierman" <[email-masked]<mailto:[email-masked]>>
To: "Netconf" <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 02, 2015 9:28 PM

Tom Petch

> [email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 5 Oct 2015 12:41:19 -0700

Could we define a set of new error-tags with error-severity as warning and still use <rpc-error>? What would be the advantage of defining <rpc-warnings> vs using error-severity of warning within <rcp-error>?

> On Oct 5, 2015, at 11:53 AM, Kent Watsen <[email-masked]> wrote:
> 
> 
> From: Andy Bierman <[email-masked] <mailto:[email-masked]>>
> To: "t.petch" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Sat, Oct 3, 2015 at 4:34 AM, t.petch <[email-masked] <mailto:[email-masked]>> wrote:
>> From: "Andy Bierman" <[email-masked] <mailto:[email-masked]>>
>> To: "Netconf" <[email-masked] <mailto:[email-masked]>>
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>> >
>> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Oct 2015 12:46:51 -0700

Hi,

I think NETCONF clients are programmed to treat <rpc-error> as an operation
failure.
A new protocol version will be needed to introduce a new message like
<rpc-warning>.

IMO stop-on-error and continue-on-error are both implementation-dependent,
especially since NETCONF has no concept of edit order.   Only all-or-none
semantics are really interoperable (yet this is the only optional mode in
NETCONF!)

Andy

On Mon, Oct 5, 2015 at 11:53 AM, Kent Watsen <[email-masked]> wrote:

>
> The general definition is "error" means the process did not complete
> whereas "warning" means the process completed with issues.   That said, I'm
> unsure what happens for continue-on-error:
>
> A negative response sounds like an <rpc-error> (since we don't have an
> <rpc-warning> yet), but I don't see which error-tag would be used for it.
> If it's not defined, maybe we use and <rpc-warning> for it instead?
>
> Kent
>
> From: Andy Bierman <[email-masked]>
> To: "t.petch" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Oct 2015 10:47:17 +0200

> Could we define a set of new error-tags with error-severity as warning and still use <rpc-error>? What would be the advantage of defining <rpc-warnings> vs using error-severity of warning within <r…

RFC 6241:

   The <rpc-error> element is sent in <rpc-reply> messages if an error
   occurs during the processing of an <rpc> request.

I think a warning is not an error. But then RFC 6241 says:

And it also says:

   The <ok> element is sent in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request, and no
   data was returned from the operation.  For example:

This seems to be somewhat interesting, at least with my common sense
interpretation of a warning ("the server could succcessfully process
the input but there are a few things the client should pay attention
to"). The current design makes sense if I have an option to tell the
server 'treat all warnings as errors' but such an option does not
exist in RFC 6241.

If we go with my layman definition of a warnings (i.e., warnings are
not errors unless specifically requested), then there are a couple of
options to communicate warnings:

- warnings go to a system log
- warnings go into specific notifications
- warnings go into metadata that is attached to specific nodes

I think I have seen systems that send certain warnings inline as XML
comments but this seems to be targeting mainly developers since tools
usually do not bother processing XML comments.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Oct 2015 12:21:22 -0700

On Tue, Oct 6, 2015 at 1:47 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > Could we define a set of new error-tags with error-severity as warning
> and still use <rpc-error>? What would be the advantage of defining
> <rpc-warnings> vs using error-severity of warning within <rcp-error>?
> >
>
> RFC 6241:
>

I guess metadata would be the best choice here because it is
the easiest to implement (and does not rely on optional
features or parsing XML comments)

Except attributes cannot be used multiple times in the
same element, so only 1 warning could really be sent

      <rpc-reply>
         <ok nc:warning="Low memory warning" />
      </rpc-reply>

A new protocol version is probably needed to do anything with warnings.

Andy