[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reporting multiple rpc-errors

Rob Enns wrote:

Thanks for the text Andy.

With the modification to allow additional attributes, it looks like
this.
Note that message-id is optional on the rpc-reply because an error must
be returned if <rpc> is sent without a message-id.

<xs:complexType name="rpcReplyType">
<xs:choice>
<xs:element name="ok"/>
<xs:group ref="rpcReplyGroup"/>
</xs:choice>
<xs:attribute name="message-id" type="xs:string" use="optional"/>
<!--
any attributes supplied with <rpc> element must be returned
on <rpc-reply>
-->
<xs:anyAttribute/> </xs:complexType>

<xs:group name="rpcReplyGroup">
<xs:sequence>
<xs:element name="rpc-error"
type="rpc-errorType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="data" minOccurs="0"/>
</xs:sequence>
</xs:group>


This XSD still allows for an empty <rpc-reply>. I think the text says the agent must send
one of these non-empty permutations:
<ok>
<rpc-error>+
(<rpc-error>+ <data>)
<data>.

Andy



Rob




-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, March 23, 2005 8:55 AM
To: netconf@ops.ietf.org
Subject: reporting multiple rpc-errors

Hi,

The section on <rpc-error> and its XSD fragment are wrong in the -05 draft.

The following text (or something like it) should be added to sec. 4.3:

If an agent encounters multiple errors during the processing of an <rpc>
request, the <rpc-reply> MAY contain multiple <rpc-error> elements.
However, an agent is not required to detect or report more than one
<rpc-error> element, if a request contains multiple errors. An agent
is not required to check for particular error conditions in a specific
sequence. An agent MUST return an <rpc-error> element if any error
conditions occur during processing, and SHOULD return an <rpc-error>
element if any warning conditions occur during processing.


Here is the XSD for <rpc-reply>:

<xs:complexType name="rpc-replyType">
<xs:choice>
<xs:element name="ok" minOccurs="0"/>
<xs:element name="rpc-error"
type="rpc-errorType" minOccurs="0"/>
<xs:element ref="data" minOccurs="0"/>
</xs:choice>
<xs:attribute name="message-id" type="xs:string" use="required"/>
</xs:complexType>

1) The <rpc-error> element should have maxOccurs="unbounded" specified.
2) This XSD design 'choice' doesn't allow for errors/warnings and data to be
returned (just one or the other). This is broken. It doesn't
allow for the 'ignore-error' error-option in the <edit-config> operation.

I think this XSD is more what we wanted when we designed the <edit-config>
operation:

<xs:complexType name="rpc-replyType">
<xs:choice>
<xs:element name="ok"/>
<xs:group ref="rpc-response"/>
</xs:choice>
<xs:attribute name="message-id" type="xs:string" use="required"/>
</xs:complexType>

    <xs:group name="rpc-response">
      <xs:sequence>
        <xs:element name="rpc-error"
          type="rpc-errorType" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="data" minOccurs="0"/>
      </xs:sequence>
    </xs:group>


Andy


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




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






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