Subject: netconf error handling

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Dec 2007 14:53:33 +0100

Hi,

I recently looked into NETCONF [RFC4741] error handling and I have two
questions.

a) The 'error-type' distinguishes between 'transport', 'rpc',
   'protocol' and 'application'. This is inconsistent with the
   layering model shown in section 1.1. It would make more sense to
   distinguish 'transport', 'rpc', 'operations' and 'application'
   since the term protocol is used in most parts of the document to
   refer to the sum of these four layers.

b) I fail to understand the usefulness of the 'error-severity' which
   has the two values 'warning' and 'error'. Section 4.3 starts with:

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

   So what is the purpose of an error that is a warning? If I choose
   to ignore the warning, how can I do that? Digging deeper, I find:

     A server MUST return an <rpc-error> element if any error
     conditions occur during processing and SHOULD return an
     <rpc-error> element if any warning conditions occur during
     processing.

   What is the use case of a warning error?

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Dec 2007 07:31:31 -0800

>    refer to the sum of these four layers.

kind of late to change it now.
Protocol/protocol operation/operation are used loosely throughout
all the NETCONF documents.

>    What is the use case of a warning error?

It is there for future WG use or vendor use.

I don't know it this will ever get used.
I have the same concerns as you -- that applications
will treat 'warning-only' responses as errors
instead of the intended 'ok'.  (My mgr code looks
for a <data> element even if there are <rpc-error>s,
but does not treat 'missing <ok/> element' as success).

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Dec 2007 16:54:00 +0100

> all the NETCONF documents.

Even if people do now want to change the one the wire encoding, I
think at least the text should be clarified in a revised version of
the document so that it is clear what is meant. (I would even go as
far as changing the protocol encoding with a note that older
definitions may still use 'protocol'; the number of widely deployed
code bases still seems to be small and a Proposed Standard is well a
Proposed Standard...)

> but does not treat 'missing <ok/> element' as success).

To me, this error severity thing sounds like a broken feature to be
removed in 4741 bis.

Anyway, do we have a process in place how we deal with errors we have
found or wordings that need to be improved? Would it not make sense to
start a 4741bis ID so that we can keep track of things more easily? I
know this has been discussed before but I lost the status / conclusion
of the discussion...

/js