Subject: Re: [Netconf] rpc-error

From: Tomasz Mikolajczyk <[email-masked]>
Date: Wed, 26 Nov 2008 09:06:15 +0100

Hi,

My apologize that I don't respond directly to the Martin's mail. I was
looking through the mail archive and took interest in this topic. IMO,
this is one of the fundamental problem in the NETCONF standard's
specification. I can imagine a lot of cases when the underlying system
may return an error during "get" type operation (addressing non-existing
item, no access to the addressed item, communication error, device
error). The standard allows returning infinite number of the rpc-errors
before the <data> element. As you mentioned it may cause buffering a
huge amount of data in the memory. But even so, I think a collection of
the rpc-errors (other than syntax ones) before the <data> element would
not say enough where the problems exist. Sending rpc-errors inline in
the <data> structure may help, however it's conceivable that many
different reasons of the errors cause that rpc-errors appears at the
same level of the <data> structure. It means that a client has to rely
on the rpc-error's content rather than place of its appearing. Moreover,
in this case assumption that rpc-errors can appear in one fixed place
may make the client's code less complicated. Putting rpc-error inline in
the <data> structure is valid from the NETCONF XSD schema point of view
but I wonder if authors of the RFC were considering such case during
standard specification.

Regards,
Tomasz Mikolajczyk

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf