Subject: [Netconf] comingling <rpc-error> and other data?

From: Kent Watsen <[email-masked]>
Date: Fri, 16 Jul 2010 15:50:53 -0700

Is this valid:

   <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <rpc-error>...</rpc-error>
     <rpc-error>...</rpc-error>
     <rpc-error>...</rpc-error>
     <data>...</data>
   </rpc-reply>

Note <data> being returned after some <rpc-error>'s

RFC 4741 has:

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

4741bis-03 has:

     <xs:group name="rpcResponse">
       <xs:sequence>
         <xs:element ref="rpc-error"
                     minOccurs="0" maxOccurs="unbounded"/>
         <xs:any namespace="##any" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:group>

Should it be <xs:choice> instead of <xs:sequence>?

PS: I disappeared for a while as I was pulled into another project

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 16 Jul 2010 16:17:25 -0700

FYI: a partner's NETCONF implementation supports having the <rpc-error> *after* the data element.  They claim it's because the server may encounter the error after having already streamed out a partial response - so they close off the <data> element and add an <rpc-error>

Maybe it should be an <xs:all> then?

K.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Friday, July 16, 2010 6:51 PM
To: netconf
Subject: [Netconf] comingling <rpc-error> and other data?

Is this valid:

RFC 4741 has:

4741bis-03 has:

Thanks,
Kent

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Jul 2010 11:58:18 +0200 (CEST)

>      <rpc-error>...</rpc-error>

Yes, both according to 4741 and 4741bis-03.

> Should it be <xs:choice> instead of <xs:sequence>?

This would be backwards incompatible.  However, I do not know the use
case for the current design.  It may have been to allow warnings, but
if that was the case, it is odd that you cannot send warnings and
<ok/>.

See also the discussion starting at
http://www.ietf.org/mail-archive/web/netconf/current/msg03876.html.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Jul 2010 12:47:36 -0700

Hi Martin,

> Yes, both according to 4741 and 4741bis-03.

I guess I meant, does it make sense more so than syntactically valid...

> if that was the case, it is odd that you cannot send warnings and

Agreed, the current 4741 design seems misguided, and I don't see how the 4741bis design improves this any...

> http://www.ietf.org/mail-archive/web/netconf/current/msg03876.html.

Thanks for pointing out that thread, it was missing from my local folder.  Still, the thread peters-out without any resolution.  In the thread, you identified having the <rpc-error> come after <data> (i.e. #4) as "not conformant with the XSD", and yet it's the only one that makes real-world sense (IMO).  Did anyone consider allowing <rpc-error> to also show up after the <data> element? - for instance:

     <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:element name="rpc-error" type="rpcErrorType"
+          minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:group>

Or is this what 4741bis is trying to allow by having the <xs:any>?

Thanks,
Kent