Subject: error-path

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2006 11:11:09 +0100 (CET)

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>

/martin

--
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: Thu, 12 Jan 2006 06:08:50 -0800

>    /rpc/edit-config/config/srv:servers/srv:server

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2006 18:46:51 +0100 (CET)

> I think this was our intent -- that the error-path would be from the 

Ok.

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

The text says "the node which is associated with the error".  If the
error is missing-element, my interpretation was that the error is in
the parent.

If the intention is that error-path MUST indicate the same node as
bad-element, maybe this should be added to the text.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jan 2006 10:56:58 -0800

>bad-element, maybe this should be added to the text.
Actually, in this case, you should be using <missing-element>,
not <bad-element>, and <error-path> should point to 'foo',
which is the missing element.

We need to stop adding tiny little details to the draft.
IMO, we don't need to change anything here.

NOTE WELL:

   Implementation guidelines and errata will be collected
   and published separately (online) from now on.
   The IESG wants the final document versions now.
   Pencils down. Pass your papers to the front of the class  ;-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2006 20:54:17 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> not <bad-element>,

The element <bad-element> is in <error-info>:

There is no element <missing-element>.  The <error-tag> is 
'missing-element' in this case.

> and <error-path> should point to 'foo',

Ok.

Ok.

/martin