[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netconf error handling

Juergen Schoenwaelder wrote:

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.


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




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?


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


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