[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: netconf error handling
On Wed, Dec 19, 2007 at 07:31:31AM -0800, Andy Bierman wrote:
> 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.
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...)
>> 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).
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
--
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 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/>