Subject: Re: [Netconf] Mixing <rpc-error> and "rpcResponses" in NETCONF replies

From: "Jernej Tuljak" <[email-masked]>
Date: Tue, 4 Oct 2016 10:03:33 +0200

Anyone?

Jernej

From: Netconf [mailto:[email-masked]] On Behalf Of Jernej Tuljak
Sent: Wednesday, September 28, 2016 1:41 PM
To: [email-masked]
Subject: [Netconf] Mixing <rpc-error> and "rpcResponses" in NETCONF replies

Hi,

is a RFC6241 compliant NETCONF server allowed to return a response like this for standard operations (get, get-config)?

<?xml version="1.0" encoding="utf-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">

  <data/>

  <rpc-error>

    <error-type>application</error-type>

    <error-tag>operation-failed</error-tag>

    <error-severity>error</error-severity>

    <error-message>Unknown error occured.</error-message>

  </rpc-error>

</rpc-reply>

That is, mixing a Positive Response and Negative Response? For the sake of argument, consider the <rpc-error> above as one of the standard ones from Appendix A [1] (and <data/> may not actually be empty). 

It is clear from Appendix B [2] that <rpc-error> and "rpcResponse" (<data/> above) may appear as siblings in sequence. But is mixing supported by RFC text below?

7.1 <get-config> [3]

   Positive Response:  If the device can satisfy the request, the server
      sends an <rpc-reply> element containing a <data> element with the
      results of the query.
 
   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

7.7 <get> [4]

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent.  The <data> section contains the appropriate
      subset.
 
   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

Also, is there a reason for different wording of Positive Response text for these two operations?

Another related question is, if a client receives a warning severity <rpc-error> to a query that normally returns an <ok/>, should it consider the query a success or failure? In other words, why are <ok/> and <rpc-error> mutually exclusive – can an operation not succeed with warnings? It would appear that only operations that return something other than <ok/> may express such behavior.

[1] - https://tools.ietf.org/html/rfc6241#appendix-A

[2] - https://tools.ietf.org/html/rfc6241#appendix-B

[3] - https://tools.ietf.org/html/rfc6241#section-7.1

[4] - https://tools.ietf.org/html/rfc6241#section-7.7

Jernej

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Oct 2016 10:26:21 +0200 (CEST)

Hi,

I think that both RFC 6241 and RFC 6020 are not clear on this, and
maybe even wrong (as you note).  I think that that a request should:

  fail with one or more rpc-errors of type "error"

  OR

  succeed with <ok/> or some other positive response, and optionally
  return one or more rpc-errors of type "warning"

Additionally, it should be ok to return <ok/> + additional positive
nodes, for example its should be fine to return this as a result to
<edit-config>:

   <rpc-reply>
     <ok/>
     <my-datastore-etag xmln="...">b3830f23a4c</my-datastore-etag>
   </rpc-reply>

I know that servers already return these kind of results...

/martin

"Jernej Tuljak" <[email-masked]> wrote:
> is a RFC6241 compliant NETCONF server allowed to return a response
> like this for standard operations (get, get-config)?
> 
>  
> 
> That is, mixing a Positive Response and Negative Response? For the
> sake of argument, consider the <rpc-error> above as one of the
> standard ones from Appendix A [1] (and <data/> may not actually be
> empty).
> 
>  
> 
> It is clear from Appendix B [2] that <rpc-error> and "rpcResponse"
> (<data/> above) may appear as siblings in sequence. But is mixing
> supported by RFC text below?
> 
>  
> 
> 7.1 <get-config> [3]
> 
>  
> 
> Another related question is, if a client receives a warning severity
> <rpc-error> to a query that normally returns an <ok/>, should it
> consider the query a success or failure? In other words, why are <ok/>
> and <rpc-error> mutually exclusive – can an operation not succeed with
> warnings? It would appear that only operations that return something
> other than <ok/> may express such behavior.
> 
>  
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Oct 2016 01:46:13 -0700

>   return one or more rpc-errors of type "warning"

Except not one single error-tag value is allowed to be used with
severity=warning
so this would not be a valid response

> I know that servers already return these kind of results...

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Oct 2016 10:49:21 +0200 (CEST)

> so this would not be a valid response

Right; but IMO there should be some error-tag for warnings.

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 4 Oct 2016 12:05:56 -0700

So, is this an errata for 6241 or 6020 (or 7950)?

Mahesh Jethanandani 
[email-masked]

On Oct 4, 2016, at 1:49 AM, Martin Bjorklund <[email-masked]> wrote:

> Right; but IMO there should be some

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Oct 2016 13:58:08 -0700

No,

This is how it is designed.
It will require a new protocol version to add warnings and/or change the XSD
the defines an <rpc-reply> element.

Andy

---

From: "Jernej Tuljak" <[email-masked]>
Date: Wed, 5 Oct 2016 10:16:22 +0200

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Tuesday, October 4, 2016 10:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] Mixing <rpc-error> and "rpcResponses" in NETCONF
> replies
> 
> Hi,
> 

While I agree that this is how things should be, there is one particular case that has been pointed out to us, which the above cannot cover. That is, not knowing an error will occur beforehand while avoiding buffering whole replies. 

Imagine a constrained device that wishes to avoid keeping entire replies buffered in memory and immediately starts flushing chunks of what later becomes a single (whole) reply on the client side. An error occurs during processing, but some chunks have already been sent. The device makes sure the reply ends up being well formed and includes an <rpc-error>, which means "some positive response" + <rpc-error> with "error" severity. This would probably means that the client needs to discard the positive part of the reply and give priority to <rpc-error>.

It seems like a viable use case to me, but I am interested in opinions of others. Has there been prior discussion on this topic (it seems likely)?  

Jernej

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Oct 2016 10:26:22 +0200 (CEST)

"Jernej Tuljak" <[email-masked]> wrote:
> While I agree that this is how things should be, there is one
> particular case that has been pointed out to us, which the above
> cannot cover. That is, not knowing an error will occur beforehand
> while avoiding buffering whole replies.
> 
> Imagine a constrained device that wishes to avoid keeping entire
> replies buffered in memory and immediately starts flushing chunks of
> what later becomes a single (whole) reply on the client side. An error
> occurs during processing, but some chunks have already been sent. The
> device makes sure the reply ends up being well formed and includes an
> <rpc-error>, which means "some positive response" + <rpc-error> with
> "error" severity. This would probably means that the client needs to
> discard the positive part of the reply and give priority to
> <rpc-error>.
> 
> It seems like a viable use case to me, but I am interested in opinions
> of others. Has there been prior discussion on this topic (it seems
> likely)?

Yes.  A typical example is if you do a <get/> and need to send back
lots of operational state, and an error occurs when you try to
retreive some state from some hw.  The simplest solution is just to
not send anything for such a node, but that is clearly not good; a
client might interpret this in some unintentional way.  Some devices
send inline errors in this case; i.e., in the middle of the <data>
you'll get an <rpc-error> structure.  A (bad) alternative if you still
want to be compliant to the spec is to drop the session from the
server when this happens.

/martin