Subject: [Netconf] rpc-error

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Oct 2008 14:38:03 +0200 (CEST)

Hi,

At the NETMOD interim meeting we discussed what the NETCONF spec says
about how errors in <get> / <get-config> processing are treated by a
server.

It turns out that of four implementations, all four handle such errors
differently.  There's also a fifth alternative, which noone (of the
people there) implements.

The spec says:

   The <rpc-error> element is sent in <rpc-reply> messages if an error
   occurs during the processing of an <rpc> request.

and:

     <xs:group name="rpcResponse">
       <xs:sequence>
         <xs:element name="rpc-error" type="rpcErrorType"
                     minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="data" type="dataInlineType" minOccurs="0"/>
       </xs:sequence>
     </xs:group>

i.e. zero or more <rpc-error> elements are followed by zero or
one <data> element.

The five different ways of handling such errors:

  1.  Buffer all data, and if any error occurs, send the <rpc-error>
      element(s) (and possibly also send the <data> element).  If no
      error occured, send all buffered data in the <data> element.

      Noone implements this, since buffering all state data is out of
      the question for larger systems.

  2.  Stream the <data>, and if a particular object cannot be
      retrieved, silently skip that element in the output.

      A client cannot know if a missing element means it is not there,
      or if an error occured.

  3.  Stream the <data>, and if any object has an error, close the
      underlying transport in the middle of the XML stream.

      A client cannot know if a closed transport meant that an error
      occured, or that a network failure occured.

  4.  Stream the <data>, and buffer any errors as they occur.  Send the
      errors as <rpc-error> as in alternative 1, but send them *after*
      the <data> element.

      This alternative is not conformant with the XSD, which says that
      any <rpc-error> elements must come before <data>.

  5.  Stream the <data>, and send <rpc-error> inline in the <data>
      element.  Like this:

         <data>
           <interfaces xmlns="http://example.com/interface">
             <interface>
               <name<eth0</name>
               <mtu>1500</mtu>
               ...
             </interface>
             <interface>
               <name<eth0</name>
               <nc:rpc-error>
                 <nc:error-message>
                   Could not retrieve interface stats: EIO
                 </nc:error-message>
                 ...
               </nc:rpc-error>
             </interface>
             ...
           </interfaces xmlns="http://example.com/interface">
          </data>

      Clients have to be prepared to parse these errors in the middle
      of the <data> stream.  It is not obvious from the spec if this
      is allowed or not.  The XSD seems to indicate that this is not
      allowed (the group "rpcResponse" could be reused inline in the
      data, but it is not perfect.)

The question to the NETCONF WG is if the spec should state how errors
are supposed to be handled, or if it should be clarified that servers
may handle such errors differently.

Inline errors are may be out of scope for the protocol, but in scope
for a data modelling language.  In this case, we might want to clarify
that the <rpc-error> element in the netconf namespace should be used
by a DML to indicate inline errors.  (The exact rules for where they
can occur must be up to the DML).

/martin
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf