Subject: [Netconf] Question on text constraints within <error-message> for NETCONF protocol level errors

From: Mark Ellison <[email-masked]>
Date: Wed, 5 Aug 2009 14:58:36 -0400

Hi,

I am working from RFC4741/draft-4741bis-00 to develop a compliant
NETCONF implementation and have a question with respect to the
<error-message> element in <rpc-error>.

The <error-message> element is described in section 4.3. as:
     "Contains a string suitable for human display that
      describes the error condition.  This element will not be present
      if no appropriate message is provided for a particular error
      condition.  This element SHOULD include an xml:lang attribute as
      defined in [1] and discussed in [12]."

And just before the examples in this section the following statement appears:

     "Appendix A enumerates the standard NETCONF errors."

If my NETCONF client sends a frame containing NETCONF protocol level
errors as follow:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<rpc message-id="106"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
        <target>
            <running/>
        </target>
        <default-operation>splurge</default-operation>
        <test-option>set-then-test</test-option>
        <error-option>contemplate-on-error</error-option>
        <mishigas/>
        <config>
           <a-config-subtree operation="merge">
               blah blah blah blah
           </a-config-subtree>
        </config>
    </edit-config>
</rpc>
]]>]]>

If my NETCONF server is constrained by Appendix A, then it will
respond with: (example reply 1)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<rpc-reply message-id="106" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">An element value is not correct;
e.g., wrong type, out of range, pattern mismatch.</error-message>
        <error-info>
            <bad-element>default-operation</bad-element>
        </error-info>
    </rpc-error>
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">An element value is not correct;
e.g., wrong type, out of range, pattern mismatch.</error-message>
        <error-info>
            <bad-element>test-option</bad-element>
        </error-info>
    </rpc-error>
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">An element value is not correct;
e.g., wrong type, out of range, pattern mismatch.</error-message>
        <error-info>
            <bad-element>error-option</bad-element>
        </error-info>
    </rpc-error>
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>unknown-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">An unexpected element is
present.</error-message>
        <error-info>
            <bad-element>mishigas</bad-element>
        </error-info>
    </rpc-error>
</rpc-reply>
]]>]]>

However, there is more specific information available that my NETCONF
server can provide with respect to the simple types having an
enumeration constraint- <default-operation>, <test-operation> and
<error-option>: (example reply 2)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<rpc-reply message-id="106" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">Value 'splurge' is not
facet-valid with respect to enumeration '[merge, replace, none]'. It
must be a value from the enumeration.</error-message>
        <error-info>
            <bad-element>default-operation</bad-element>
        </error-info>
    </rpc-error>
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">Value 'set-then-test' is not
facet-valid with respect to enumeration '[test-then-set, set]'. It
must be a value from the enumeration.</error-message>
        <error-info>
            <bad-element>test-option</bad-element>
        </error-info>
    </rpc-error>
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">Value 'contemplate-on-error' is
not facet-valid with respect to enumeration '[stop-on-error,
continue-on-error, rollback-on-error]'. It must be a value from the
enumeration.</error-message>
        <error-info>
            <bad-element>error-option</bad-element>
        </error-info>
    </rpc-error>
    <rpc-error>
        <error-type>rpc</error-type>
        <error-tag>unknown-element</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">An unexpected element is
present.</error-message>
        <error-info>
            <bad-element>mishigas</bad-element>
        </error-info>
    </rpc-error>
</rpc-reply>
]]>]]>

The above error-message text is taken directly from the SAX/DOM parser
errors based upon the NETCONF schema and appear to be more useful than
the error-message text contained in Appendix A.

Now, in order to be compliant wih respect to 4741/4741bis does my
NETCONF server for errors occurring at the NETCONF protocol level need
to constrain eror-message text to that contained in Appendix A?  Or,
can the error-message text be as in example reply 2?  (Or even a
concatenation of Appendix A error-message text with the text in
example reply 2?)

Regards,

Mark

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Aug 2009 22:50:41 +0200

On Wed, Aug 05, 2009 at 08:58:36PM +0200, Mark Ellison wrote:

[...]

> to constrain eror-message text to that contained in Appendix A?? Or,
> can the error-message text be as in example reply 2?? (Or even a

My understanding is that the error-message text is implementation
specific and for consumption by human beings while programs use the
more formalized error fields.

/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: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Aug 2009 12:25:25 +0200 (CEST)

Hi,

Mark Ellison <[email-masked]> wrote:
> to constrain eror-message text to that contained in Appendix A?

No.  In Appendix A the string is labeled "Description", and it is not
intended to be used as the error-message content.  This should be made
more clear in 4741bis.  Also note that you are free to add an
error-app-tag or any error-info content to provide more specific
details about the error.

I have added this as issue 16 on the open issues list.

/martin