Issue 12.6) <rpc-error>

[Andy Bierman <abierman@cisco.com>]

We need to make progress on the error handling details.
This is mandatory for v1.0, and cannot be punted to a 
later release.

[Functional Requirements]

   - need a set of well-defined error responses
   - applications should be able to process error responses using 
     mostly common code
   - data model specific error responses should be avoided, but
     may be needed for referential integrity or resource errors
   - each <rpc-error> sub-element must have either a constrained
     set of standard values in order to be useful and interoperable
   - it must be possible to return multiple <rpc-error> elements 
     in response to a single request
   - need to differentiate between errors and warnings
   - need to allow for application errors as well as protocol errors

[Current Text, sec. 3.4]

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

   The <rpc-error> element includes the following information:

   o  tag: String identifying the error condition.

   o  error-code: Integer identifying the error condition.

   o  severity: String identifying the error severity, as determined by
      the device.

   o  edit-path: Configuration data that provides the context for the
      command that caused the error.  This can be the empty string if
      the command causing the error is located at the top level of the
      command hierarchy.

   o  statement: Configuration or command that caused the error.

   o  message: String describing the error condition.

   o  action: Action taken by the device in response to this error.

   [ed: A list of standard error codes is TBD.  Both protocol error and
   application error codes will be supported by <rpc-error>.]

   <rpc-error message-id="102" xmlns="http://ietf.org/netconf/base/1.0";>
     <tag>EXAMPLE_MTU_RANGE</tag>
     <error-code>128</error-code>
     <severity>error</severity>
     <statement>mtu 21050;</statement>
     <message>MTU 21050 on Ethernet/1 is outside range 256..9192</message>
   </rpc-error>

[XSD Fragment]

     <xsd:complexType name="rpc-errorType">
       <xsd:sequence>
         <xsd:element name="tag" type="xsd:string" minOccurs="0"/>
         <xsd:element name="error-code" type="xsd:integer" minOccurs="0"/>
         <xsd:element name="severity" type="xsd:string" minOccurs="0"/>
         <xsd:element name="edit-path" type="xsd:string" minOccurs="0"/>
         <xsd:element name="statement" type="xsd:string" minOccurs="0"/>
         <xsd:element name="message" type="xsd:string" minOccurs="0"/>
         <xsd:element name="action" type="xsd:string" minOccurs="0"/>
       </xsd:sequence>
     </xsd:complexType>

  Notes:
   - the minOccurs attribute should not be zero for all these fields
   - currently there is no support for multiple <rpc-error> elements
     because maxOccurs is (defaulted to) 1.

[Issue List Fragment]

12.6) <rpc-error> 

  Open: Need to finalize all fields in the <rpc-error> element   
        and improve documentation

12.6.1) Error codes  

  Open: need to define <rpc-error> content for standard errors
        - 5 layers
          - application mapping          
          - netconf protocol
          - RPC layer
          - protocol operation
          - data model specific
        The WG needs to document all but the data model specific
        error responses.  All the rest, except application mapping
        errors should be documented in the netconf protocol I-D.

[Proposal]

   - tag: 
     - need a standard set of these strings
     - the prefix string NETCONF_ is reserved for WG defined errors

   - error-code: 
     - need a standard set of these integers
     - the value zero is reserved to indicate NO_ERROR
     - the integer range 1 .. 1000 is reserved for WG defined errors

   - severity: 
     - this should be an enum, not a free-form string
     - the standard values 'error' and 'warning' are defined
     - no other values are allowed in this field

   - edit-path: 
     - this seems like a very CLI-centric and cumbersome way to 
       identify the specific part of the supplied data model 
       that contained an error.
     - would be easier to include enough of the config hierarchy
       in the response, and let the location of the <rpc-error>
       in the <config> element sub-tree identify the edit-path.
     - remove this sub-element

   - statement:
     - would be easier to include enough of the config hierarchy
       in the response, and let the location of the <rpc-error>
       in the <config> element sub-tree identify the edit-path.
     - remove this sub-element

   - message:
     - message strings for standard errors should be defined
     - vendor-specific edit-path and statement info can put 
       placed in this field, if needed
     - limit length of string to N bytes (N=1024?)

   - action: 
     - this field is redundant does not seem very useful
     - define a set of standard enum values or this field
       should be removed




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