Subject: [netmod] yang error codes

From: David Reid <[email-masked]>
Date: Thu, 18 Jun 2009 11:21:23 -0400

I have a question about error codes. If I try to set an object to a value
that is the wrong type or is out of range, what is the correct error-tag? 
>From rfc4741, I thought it should be bad-element. But the yang spec clearly 
says invalid-value.

rfc4741:
   Tag:         bad-element
   Error-type:  rpc, protocol, application
   Severity:    error
   Error-info:  <bad-element> : name of the element w/ bad value
   Description: An element value is not correct; e.g., wrong type,
                out of range, pattern mismatch.

Yang:
   o  If a leaf data value does not match the type constraints for the 
      leaf, including those defined in the type's range, length, and
      pattern properties, the server MUST reply with an "invalid-value"
      error-tag in the rpc-error, and with the error-app-tag and error-
      message assoicated with the constraint, if any exist.

-David Reid

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 08:32:55 -0700

>       message assoicated with the constraint, if any exist.

I think this error-tag overlaps with invalid-value.
I would follow the YANG spec, and use <error-path>
instead of <bad-element> to identify the error node.

> -David Reid

Andy

---

From: David Reid <[email-masked]>
Date: Thu, 18 Jun 2009 11:56:02 -0400

> instead of <bad-element> to identify the error node.

OK, thanks.

A follow-up question: when do I use error-path and when do I use error-info?
I'm looking at the example on page 15 of rfc4741 which uses error-info to
identify the error node.

       <rpc-error>
         <error-type>application</error-type>
         <error-tag>invalid-value</error-tag>
         <error-severity>error</error-severity>
         <error-message xml:lang="en">
           MTU value 25000 is not within range 256..9192
         </error-message>
         <error-info>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>25000</mtu>
             </interface>
           </top>
         </error-info>
       </rpc-error>

Let me try an example:

module foo {
     namespace "http://example.com/foo";
     prefix "foo";

     list interface {
         key "name";
         config true;

         leaf name {
             type string;
         }
         leaf speed {
             type enumeration {
                 enum 10m;
                 enum 100m;
                 enum auto;
             }
         }
         leaf observed-speed {
             type uint32;
             config false;
         }
     }
}

I issue the following edit-config request with an invalid value for 
interface/speed:

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <interface xmlns="http://example.com/foo">
        <name>Ethernet0/0</name>
        <speed>BAD</speed>
        <observed-speed>10000</observed-speed>
      </interface>
    </config>
  </edit-config>
</rpc>
]]>]]>

My error reply looks something like this:

<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <rpc-error>
    <error-type>application</error-type>
    <error-tag>invalid-value</error-tag>
    <error-severity>error</error-severity>
    <error-path>/interface[name=Ethernet0/0]/speed<error-path>
  </rpc-error>
</rpc-reply>
]]>]]>

Is my error-path right? 
Should there be anything for error-info?
Is "application" the correct error-type?

-David Reid

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 09:42:50 -0700

>            <top xmlns="http://example.com/schema/1.2/config">

IMO, most of the 'content' related examples in RFC 4741 and
5277 are horrible.  They demonstrate how little the WG
understood XPath, and the content layer at the time.
(Including me.)

>     <error-path>/interface[name=Ethernet0/0]/speed<error-path>

almost.

   <error-path xmlns:foo="http://example.com/foo">
      /foo:interface[foo:name='Ethernet0/0']/foo:speed
   </error-path>

Of course, some implementations work whether the XML namespaces
are present or not.  This isn't XML to the letter I guess,
but not as fragile either.

BTW, you need to generate an additional <rpc-error> for
the writing to <observed-speed> (config=false).

> Should there be anything for error-info?

whatever you want (in your namespace of course).
I like to add whatever data I think can help the
operator solve the problem faster.  Fishing
for more data wastes time. (e.g., <bad-value>,
<error-number>, etc.)

I suggest using <error-app-tag> and <error-message>
every time as well.  Use them before using <error-info>.

> Is "application" the correct error-type?

yes

If the error was with <target>bogus</target>,
then the error-type would be 'operation'.

Andy

---

From: David Reid <[email-masked]>
Date: Thu, 18 Jun 2009 13:48:24 -0400

>       /foo:interface[foo:name='Ethernet0/0']/foo:speed

How do I know what the root node in my xpath expression should be? Why is
it not /rpc/edit-config/config/interface[name='Ethernet0/0']/speed?

-David Reid

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 10:55:45 -0700

> it not /rpc/edit-config/config/interface[name='Ethernet0/0']/speed?

oops!
you are right!
It should be the path all the way back to /rpc
if it exists.  For <validate> and <commit>,
the other form is used, starting with the data root.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Jun 2009 19:59:43 +0200 (CEST)

> the other form is used, starting with the data root.

Well, this is one of the open issues for 4741bis.  The current spec
for error-path says:

      This element
      will not be present if no appropriate payload element can be
      associated with a particular error condition,

so when you do <validate>, no error-path should be returned, according
to 4741.  (The info is of course needed, so if it is not returned in
error-path it must be returned in some other element.)

/martin

---

From: David Reid <[email-masked]>
Date: Thu, 18 Jun 2009 14:30:21 -0400

> if it exists.

I think it would be helpful to have an example rpc-error in the yang document.

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Jun 2009 22:35:03 +0200

> the other form is used, starting with the data root.

Really?

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 13:56:38 -0700

>> the other form is used, starting with the data root.

well, if you want the operator to know why the <commit>
failed, then using the instance-identifier of the node
that had the error is useful.

I should attach a disclaimer to every email:
"Opinions expressed are my own."

I don't let a careless sentence or two written 5 years
ago get in the way of running code.  NETCONF didn't
have an i-i data type then.  Put whatever you want
in the <rpc-error>.  The market will decide if
the data is useful or not.  Clearly the WG (5 years ago)
had very little clue what was useful or not.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Jun 2009 23:01:05 +0200

> that had the error is useful.

This does not answer why the root has to be /rpc. And sorry
for asking questions.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 14:04:48 -0700

>> the other form is used, starting with the data root.

Actually, this is exactly what the YANG spec (sec. 13)
says to do with the <error-path> field for
the 'instance-required' and 'missing-choice' errors.
So, really.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 14:34:24 -0700

> This does not answer why the root has to be /rpc. And sorry

    error-path:  Contains the absolute XPath [2] expression identifying
       the element path to the node that is associated with the error
       being reported in a particular rpc-error element.  This element
       will not be present if no appropriate payload element can be
       associated with a particular error condition, or if the
       'bad-element' QString returned in the 'error-info' container is
       sufficient to identify the node associated with the error.  When
       the XPath expression is interpreted, the set of namespace
       declarations are those in scope on the rpc-error element,
       including the default namespace.

My interpretation of this text is that the absolute XPath
expression refers to the request PDU (i.e., <rpc> element).

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Jun 2009 08:12:42 +0200

> the 'instance-required' and 'missing-choice' errors.

I found this text:

     Error-path:     Path to the element with the require-instance
                     statement

     Error-path:     Path to the element with the missing choice.

The question was what the root for this path is. I do not find this
spelled out anywhere - can you help me find it?

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 19 Jun 2009 14:22:50 +0200

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Friday, June 19, 2009 8:12 AM

> spelled out anywhere - can you help me find it?

Perhaps time to resurrect the thread that died out at the start of the month.

Just to recap, XPath defines a root node which is the parent of the document
element; that is what is, and I believe we should stick with it.  So the
question is what is the document element?

This has to be defined whereever we use XPath since what is a 'document' is not
obvious. 'must' and 'when' covers this, other places do not.  Needs fixing.  I
do not have strong views about what the document element should be; I do have
strong views that whereever we use XPath, it needs defining.

<rpc> was covered by Martin 28th May 2009.

Tom Petch

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Jun 2009 07:24:06 -0700

> <rpc> was covered by Martin 28th May 2009.

You cannot equate YANG and NETCONF for all usage of XPath.
YANG ignores the RPC layer in NETCONF, but <error-path>
cannot do the same.

Obviously, starting the error-path at <methodType> for <rpc>
ignores the top-level element, so any problems there
would not be reportable.  That is unacceptable.
The error-path needs to identify any error node,
whether it is in the input PDU or the database.
It is trivial for an application to tell the difference,
because nobody is ever allowed to define a YANG data node
named <rpc> in the NETCONF namespace.  So, /nc:rpc cannot
possibly be confused with a data node.

Starting at any other point, such as the method name,
would introduce ambiguity.  Starting with /rpc is the
only deterministic solution possible, without introducing
new error fields, which means a new protocol version.

Andy

---

From: "tom.petch" <[email-masked]>
Date: Tue, 23 Jun 2009 10:57:37 +0200

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "tom.petch" <[email-masked]>
Sent: Friday, June 19, 2009 4:24 PM

Andy

Um.

I agree that we do not have to make the XPath context the same for YANG and
Netconf; but making them different may confuse, which is how I understand your
suggestion.

For an absolute XPath expression for YANG, we currently have
/validate/source/...
whereas for Netconf's error-path you are suggesting
/rpc/validate/source/..

I agree with you on the need for <rpc> in the error-path; I would see it simpler
to be consistent and to add that to YANG (which is what you suggested last
December, as I recall).

More generally, I think that rfc4741bis needs to spell out  the XPath context in
more detail, as has been done in YANG for 'must'.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jun 2009 06:06:08 -0700

> whereas for Netconf's error-path you are suggesting

no I am not, unless it is wrong <source>rumming</source>

If the error node you are reporting in the <rpc-error>
is directly contained in the <rpc>, then the error-path
should start with /rpc.  If not (e.g., a must-violation),
then start with the YANG top-level element, since /foo/bar/broken
was never in the request PDU.

> more detail, as has been done in YANG for 'must'.

I think we are trying to agree on those details right now.
As I said before, if the error-path starts with /nc:rpc,
there is no ambiguity, so what is the problem?

I don't think there is one.
If you don't want to use the optional <error-path>,
then don't use it, but don't tell others that a well-formed
absolute XPath expression is wrong.  It's valid XPath,
so the manager can figure it out.

Andy