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

Re: error-path

Martin Bjorklund wrote:


Hi,

error-path is really useful for troubleshooting.  But it is unclear
what the root of the absolute xpath expression is supposed to be.  In
our implementation, we currently generate error-path only for
application errors, and generate an xpath expression with root in the
datamodel, e.g.

 <error-path xmlns:srv="http://www.tail-f.com/test";>
   /srv:servers/srv:server
 </error-path>
 <error-info>
   <bad-element>foo</bad-element>
 </error-info>

But IF error-path is used for rpc/protocol errors (we don't do that), the root
will have to be the protocol root:

 <error-path>
    /rpc/get-config
 </error-path>
 <error-info>
   <bad-element>foo</bad-element>
 </error-info>


So the question is first if error-path should be allowed for
rpc/protocol error-types?  If so, should the root be different
depending on error-type?  If it's always the same (top-level), my
first example would be

 <error-path xmlns:srv="http://www.tail-f.com/test";>
   /rpc/edit-config/config/srv:servers/srv:server
 </error-path>
I think this was our intent -- that the error-path would be from the 'rpc' root 
so it is always unambiguous.  That is the whole point of this parameter.
If the QName in <bad-element> is ambiguous (because it can occur at multiple levels) 
then use error-path also.


Shouldn't the correct error-path in your example be:
   /rpc/edit-config/config/srv:servers/srv:server/srv:foo

It needs to indicate the same node as <bad-element>.

Andy









/martin


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