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

From: André Domingos Brízido <[email-masked]>
Date: Thu, 6 Oct 2016 19:00:16 +0100

Hi

Regarding the email thread below, I would like to check with you that my understanding is correct.
Any of these alternatives are acceptable in order for a server to be compliant to the NETCONF specification:

1.       Buffer the entire reply until the result of the operation is known, if the reply does not fit the buffer then  send the "too big" error [1]

2.       Silently discard errors and omit tags

3.       Send <rpc-errors> in the middle of <data> (When you say  in the middle of <data> you mean as a direct child, correct?)

4.       Drop the session (the least preferable)

Best regards
Andre

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

> "Jernej Tuljak" <jernej.tuljak at mg-soft.si> wrote:
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:mbj at tail-f.com]
> > > Sent: Tuesday, October 4, 2016 10:26 AM
> > > To: jernej.tuljak at mg-soft.si
> > > Cc: netconf at ietf.org
> > > Subject: Re: [Netconf] Mixing <rpc-error> and "rpcResponses" in
> > > NETCONF
> > > replies
> > >
> > > 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"
> >
> > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Oct 2016 20:20:30 +0200 (CEST)

André Domingos Brízido <[email-masked]> wrote:
> 1.  Buffer the entire reply until the result of the operation is
> known, if the reply does not fit the buffer then send the "too big"
> error [1]
> 
> 3.  Send <rpc-errors> in the middle of <data> (When you say in the
> middle of <data> you mean as a direct child, correct?)

I meant deep inline, where the real element would have been.

> 4.       Drop the session (the least preferable)

I don't know if (1) is preferred; it doesn't really help the client to
get a 'too-big' error in this case.

/martin

---

From: André Domingos Brízido <[email-masked]>
Date: Thu, 6 Oct 2016 19:33:27 +0100

But including the <rpc-error> instead of the expected element will not break the syntax defined in the YANG data model?
Or standard YANG modules have to be augmented by proprietary modules in every potential point of failure?

Best regards 
Andre

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 6 de outubro de 2016 19:21
To: André Domingos Brízido
Cc: [email-masked]
Subject: Re: Mixing <rpc-error> and "rpcResponses" in NETCONF replies

> 4.       Drop the session (the least preferable)

I don't know if (1) is preferred; it doesn't really help the client to get a 'too-big' error in this case.

/martin

> > > > NETCONF replies
> > > > 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:
> > > >
> > > 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)?
> >
> > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Oct 2016 20:39:07 +0200 (CEST)

André Domingos Brízido <[email-masked]> wrote:
> But including the <rpc-error> instead of the expected element will not
> break the syntax defined in the YANG data model?

Since the <rpc-error> is in a different XML namespace than the rest,
clients will hopefully not break; some clients will be prepared for
it, and some will just skip it.

I'm just saying that some servers work like this.  It is not well
defined in the specs.

> in every potential point of failure?

No that wouldn't be very useful.

/martin

---

From: André Domingos Brízido <[email-masked]>
Date: Fri, 7 Oct 2016 10:21:14 +0100

Ok. Thank you for your reply.

Best regards
Andre

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 6 de outubro de 2016 19:39
To: André Domingos Brízido
Cc: [email-masked]
Subject: Re: Mixing <rpc-error> and "rpcResponses" in NETCONF replies

> break the syntax defined in the YANG data model?

Since the <rpc-error> is in a different XML namespace than the rest, clients will hopefully not break; some clients will be prepared for it, and some will just skip it.

I'm just saying that some servers work like this.  It is not well defined in the specs.

/martin

> > > > > Subject: Re: [Netconf] Mixing <rpc-error> and "rpcResponses" 
> > > > > in NETCONF replies
> > > > >
> > > > > Hi,
> > > > >
> > > > > and maybe even wrong (as you note).  I think that that a 
> > > > > request
> > > > > should:
> > > > >
> > > > cannot cover. That is, not knowing an error will occur 
> > > > beforehand while avoiding buffering whole replies.
> > > >
> > > > replies buffered in memory and immediately starts flushing 
> > > > chunks of what later becomes a single (whole) reply on the client side.
> > > > 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>.
> > > >
> > > > 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
>