Subject: [Netconf] yang-push issue: error handling

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Dec 2017 12:55:20 -0800

Hi,

IMO the special error handling in YANG Push is not acceptable
because it violates NETCONF and RESTCONF error handling procedures.
NETCONF says if the operation does not work for any reason an <rpc-error>
element SHOULD be returned.

The <establish-subscription> returns data even on error.
Instead of the common error-tag, error-info, and other fields,
there is a subscription-result leaf.

If any client (or even server) functionality uses the NETCONF and
RESTCONF standard error handling, then subscription-result will not be
sent or expected as an error response. Depending on the server
implementation, the code that knows about establish-subscription
may not get called because common error handling code has
already determined there is an <rpc-error> to send instead of a data
response.

Expect that some servers are never going to send data on an operation
failure, and will only send <rpc-error> instead.

>From sec. 3.8:

   For instance, for the following request:

<netconf:rpc message-id="101"
   xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
   <establish-subscription
       xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
       xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
      <yp:datastore>
        <yp:source xmlns="urn:ietf:params:xml:ns:yang:ietf-datastores">
          operational
        </yp:source>
        <yp:subtree-filter netconf:type="xpath"
            xmlns:ex="http://example.com/sample-data/1.0"
            select="/ex:foo"/>
      </yp:datastore>
      <yp:period>500</yp:period>
   </establish-subscription>
</netconf:rpc>

                 Figure 3: Establish-Subscription example

   the publisher might return:

<rpc-reply message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <subscription-result
       xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
       xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
     yp:period-unsupported
   </subscription-result>
   <period-hint xmlns:"urn:ietf:params:xml:ns:yang:ietf-yang-push">
      2000
   </period-hint>
</rpc-reply>

                     Figure 4: Error response example

BTW, all the filter examples seem to be wrong, including the one above

OLD:

        <yp:subtree-filter netconf:type="xpath"
            xmlns:ex="http://example.com/sample-data/1.0"
            select="/ex:foo"/>

NEW:

        <yp:subtree-filter>
           <ex:foo xmlns:ex="http://example.com/sample-data/1.0" />

        </yp:subtree-filter>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Dec 2017 13:55:39 +0100 (CET)

> element SHOULD be returned.

I fully agree, and I have pointed this out several times in my
reviews.  The problem is actually in subscribed notifications, and I
think Eric is tracking that issue.

Trying to be constructive, I think that the existing mechanisms in
YANG can be used to achieve the same functionality that these drafts
try to achieve.  Specifically:

  1. Use identities just like the ones you have
     ("unsupportable-volume", "filter-unavailable" etc), but add text
     that explains that these identities are sent as "error-app-tag"
     in "rpc-error", encoded to a string as <module>:<identity>.  This
     works for both NETCONF and RESTCONF.

  2. For the "hints" extra info that you return, define a "yang-data"
     structure with the hints, and explain in text that this structure
     is returned in "error-info".  This works for both NETCONF and
     RESTCONF.

As an alternative to 1, you can put the error identitiyref in the
"yang-data" structure, and send both the identitiyref and hints in
"error-info".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Dec 2017 09:14:51 -0800

>      is returned in "error-info".  This works for both NETCONF and

+1

If the error handling was done correctly then the same procedures could be
applied to <edit-config> failures for configured subscriptions.

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 5 Dec 2017 20:03:25 +0000

Hi,

While possible, the solution of having to return rpc-error etc does strike me as somewhat clunky.  While it is possible to add an error-app-tag, and negotiation stuff as error-info (and I appreciate the suggestion), that solution would need to be described using a lot of prose in description statements a la SMIv2 (presumably as part of the RPC description, not as part of e.g. the identities, which might be used in a number of places, not just the error-app-tag).   I am not sure why that would make an RPC any easier to implement.  The same checks still have to be made.

Why would the proposed solution not acceptable?   Ideally YANG would provide better support to formally define application/RPC-specific return codes and corner conditions etc. Short of that, the proposed solution of adding RPC output parameters that are used for the purpose of indicating what is going on at the application level simply makes them part of the semantics of the specific RPC itself.  It is not Netconf’s role to define what an RPC can or cannot do, just like it cannot define what a particular leaf may or may not represent.  That is part of the RPC definition.

Basically, what we are discussing here is behavior of subscription configuration under corner conditions.  The fact that no subscription is created because it would result in an unacceptable volume of updates for a specific implementation is different from an error condition such as a malformed message that is missing a required message-id, or where a value violates a constraint specified in a MUST-condition.  In our case, what is being described are specific conditions at the application layer, above the Netconf/Restconf generic validation infrastructure.   The operation does not “work” in the sense that it does not result in an active subscription, but it does work in the sense that the behavior is very well defined in terms of the effect that the RPC has (i.e. the effect is that it result in creation of a subscription, if certain conditions are met, and it does not result in creation of a subscription in case certain conditions are not met).  Why should Netconf restrict what an RPC can or cannot do?  This is all application-specific.

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Monday, December 04, 2017 9:15 AM
To: Martin Bjorklund <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] yang-push issue: error handling

On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:

+1

/martin

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Dec 2017 12:10:57 -0800

Hi,

The protocol defines how error handling is done, not the individual
operations.
If the request fails, then clients expect an <rpc-error> and servers are
designed
to send an <rpc-error> when a client request fails.

IMO, a separate error handling procedure for each RPC is more clunky than
error-info.

Andy

On Tue, Dec 5, 2017 at 12:03 PM, Alexander Clemm <[email-masked]
> wrote:

> Hi,
>
>
>
> While possible, the solution of having to return rpc-error etc does strike
> me as somewhat clunky.  While it is possible to add an error-app-tag, and
> negotiation stuff as error-info (and I appreciate the suggestion), that
> solution would need to be described using a lot of prose in description
> statements a la SMIv2 (presumably as part of the RPC description, not as
> part of e.g. the identities, which might be used in a number of places, not
> just the error-app-tag).   I am not sure why that would make an RPC any
> easier to implement.  The same checks still have to be made.
>
>
>
> Why would the proposed solution not acceptable?   Ideally YANG would
> provide better support to formally define application/RPC-specific return
> codes and corner conditions etc. Short of that, the proposed solution of
> adding RPC output parameters that are used for the purpose of indicating
> what is going on at the application level simply makes them part of the
> semantics of the specific RPC itself.  It is not Netconf’s role to define
> what an RPC can or cannot do, just like it cannot define what a particular
> leaf may or may not represent.  That is part of the RPC definition.
>
>
>
> Basically, what we are discussing here is behavior of subscription
> configuration under corner conditions.  The fact that no subscription is
> created because it would result in an unacceptable volume of updates for a
> specific implementation is different from an error condition such as a
> malformed message that is missing a required message-id, or where a value
> violates a constraint specified in a MUST-condition.  In our case, what is
> being described are specific conditions at the application layer, above the
> Netconf/Restconf generic validation infrastructure.   The operation does
> not “work” in the sense that it does not result in an active subscription,
> but it does work in the sense that the behavior is very well defined in
> terms of the effect that the RPC has (i.e. the effect is that it result in
> creation of a subscription, if certain conditions are met, and it does not
> result in creation of a subscription in case certain conditions are not
> met).  Why should Netconf restrict what an RPC can or cannot do?  This is
> all application-specific.
>
>
>
> --- Alex
>
>
>
>
>
> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Monday, December 04, 2017 9:15 AM
> *To:* Martin Bjorklund <[email-masked]>
> *Cc:* Netconf <[email-masked]>
> *Subject:* Re: [Netconf] yang-push issue: error handling
>
>
>
>
>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Dec 2017 21:24:43 +0100 (CET)

> to send an <rpc-error> when a client request fails.

Agreed, and for RESTCONF, the HTTP error codes are used.  An HTTP
request that fails does not return 200 ok with a body that explains
that it actually was an error.

+1

Some additional comments inline.

> > just the error-app-tag).

If both the error code and hint is defined in a yang-data (i.e., not
using the error-app-tag), you would do:

  yx:yang-data subscription-error {
    container subscription-error {
      leaf error-code {
        type identity {
          base error;
        }
      }
      container hints { ... }
    }
  }

Then you are right, you have to describe in prose that this yang-data
structure can be sent as error-info.

> > I am not sure why that would make an RPC any

Agreed.

> > codes and corner conditions etc.

Also agreed.  But once we have that, such a solution would make use of
the rpc-error we have (for both NETCONF and RESTCONF).

/martin

> > Short of that, the proposed solution of

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 5 Dec 2017 20:35:03 +0000

Hi Martin,

Sure, the eventual solution may make use of rpc-error again.  But until we get there, the currently proposed solution seems to make sense to me.  I don't think we have an issue today with lots of RPCs each defining their own way of dealing with corner conditions - definition of RPCs is something that has so far only rarely been exercised with YANG models.  Once this becomes more common, I am sure we will find a more general solution, but I don't think we are at that point. 

--- Alex 

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Tuesday, December 05, 2017 12:25 PM
> To: [email-masked]
> Cc: Alexander Clemm <[email-masked]>; [email-masked]
> > If the request fails, then clients expect an <rpc-error> and servers
> > are designed to send an <rpc-error> when a client request fails.
> 
> Agreed, and for RESTCONF, the HTTP error codes are used.  An HTTP request
> that fails does not return 200 ok with a body that explains that it actually was
> an error.
> 
> > IMO, a separate error handling procedure for each RPC is more clunky
> > than error-info.
> 
> +1
> 
> > > While possible, the solution of having to return rpc-error etc does
> > > strike me as somewhat clunky.  While it is possible to add an
> > > error-app-tag, and negotiation stuff as error-info (and I appreciate
> > > the suggestion), that solution would need to be described using a
> > > lot of prose in description statements a la SMIv2 (presumably as
> > > part of the RPC description, not as part of e.g. the identities,
> > > which might be used in a number of places, not just the error-app-tag).
> 
> If both the error code and hint is defined in a yang-data (i.e., not using the
> error-app-tag), you would do:
> 
> > > I am not sure why that would make an RPC any easier to implement.
> > > The same checks still have to be made.
> 
> Agreed.
> 
> > > provide better support to formally define application/RPC-specific
> > > return codes and corner conditions etc.
> 
> Also agreed.  But once we have that, such a solution would make use of the
> rpc-error we have (for both NETCONF and RESTCONF).
> 
> 
> /martin
> 
> 
> > > Short of that, the proposed solution of adding RPC output parameters
> > > that are used for the purpose of indicating what is going on at the
> > > application level simply makes them part of the semantics of the
> > > specific RPC itself.  It is not Netconf’s role to define what an RPC
> > > can or cannot do, just like it cannot define what a particular leaf
> > > may or may not represent.  That is part of the RPC definition.
> > >
> > >
> > >
> > > configuration under corner conditions.  The fact that no
> > > subscription is created because it would result in an unacceptable
> > > volume of updates for a specific implementation is different from an
> > > error condition such as a malformed message that is missing a
> > > required message-id, or where a value violates a constraint
> > > specified in a MUST-condition.  In our case, what is being described are
> specific conditions at the application layer, above the
> > > not “work” in the sense that it does not result in an active
> > > subscription, but it does work in the sense that the behavior is
> > > very well defined in terms of the effect that the RPC has (i.e. the
> > > effect is that it result in creation of a subscription, if certain
> > > conditions are met, and it does not result in creation of a
> > > subscription in case certain conditions are not met).  Why should
> > > Netconf restrict what an RPC can or cannot do?  This is all application-
> specific.
> > >
> > >
> > >
> > > --- Alex
> > >
> > >
> > >
> > >
> > >
> > > *From:* Netconf [mailto:[email-masked]] *On Behalf Of
> > > *Andy Bierman
> > > > NETCONF says if the operation does not work for any reason an
> > > > <rpc-error> element SHOULD be returned.
> > >
> > > > RESTCONF standard error handling, then subscription-result will
> > > > not be sent or expected as an error response. Depending on the
> > > > server implementation, the code that knows about
> > > > establish-subscription may not get called because common error
> > > > handling code has already determined there is an <rpc-error> to
> > > > send instead of a data response.
> > > >
> > > > Expect that some servers are never going to send data on an
> > > > operation failure, and will only send <rpc-error> instead.
> > > >
> > > >
> > > > >From sec. 3.8:
> > > >

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Dec 2017 12:55:56 -0800

On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm <[email-masked]

> Hi Martin,
>
> Sure, the eventual solution may make use of rpc-error again.  But until we
> get there, the currently proposed solution seems to make sense to me.  I
> don't think we have an issue today with lots of RPCs each defining their
> own way of dealing with corner conditions - definition of RPCs is something
> that has so far only rarely been exercised with YANG models.  Once this
> becomes more common, I am sure we will find a more general solution, but I
> don't think we are at that point.
>
>
It is not an issue because all the other YANG modules follow the rule that
data is only returned from an RPC or action if the request worked.
NETCONF and RESTCONF indicate errors in a specific manner which
can be done with common code because the protocol level (not the
application level)
defines the error handling procedures.

Andy

> the

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Dec 2017 14:19:46 -0800

Hi,

Here is the problem with the YANG Push error handling.
The <rpc-error> response is a MUST, not a SHOULD:

4.3.  <rpc-error> Element

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

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

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 6 Dec 2017 02:01:03 +0000

I still find this a bit clunky (and I still wonder if we could define “corner behavior” instead of error conditions), but OK, let’s go with the proposed as outlined by Martin.

Let’s close this; we will update the RPCs accordingly.

Thanks
--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, December 05, 2017 2:20 PM
To: Alexander Clemm <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]
Subject: Re: [Netconf] yang-push issue: error handling

Hi,

4.3.  <rpc-error> Element

   a specific sequence.  A server MUST return an <rpc-error> element if

   any error conditions occur during processing.

Andy

On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

--- Alex

> From: Martin Bjorklund [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>
> Cc: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > > *From:* Netconf [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of
> > > *Andy Bierman
> > > *To:* Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
> > > *Cc:* Netconf <[email-masked]<mailto:[email-masked]>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 5 Dec 2017 18:09:00 -0800

[Speaking as a contributor]

For the record, I agree with Martin and Andy on the use of <rpc-error> as the way to communicate the error. Otherwise, we just create inconsistencies in implementations that decide their own way of communicating an error.

> On Dec 5, 2017, at 6:01 PM, Alexander Clemm <[email-masked]> wrote:
> 

[Speaking as chair]

> Let’s close this; we will update the RPCs accordingly.   

Thanks.

> On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Martin,
> 
> > From: Martin Bjorklund [mailto:[email-masked] <mailto:[email-masked]>]
> > To: [email-masked] <mailto:[email-masked]>
> > Cc: Alexander Clemm <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> > Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> > > Hi,
> > >
> > > > *From:* Netconf [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf Of
> > > > *Andy Bierman
> > > > *To:* Martin Bjorklund <[email-masked] <mailto:[email-masked]>>
> > > > *Cc:* Netconf <[email-masked] <mailto:[email-masked]>>
> > > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund <[email-masked] <mailto:[email-masked]>>
> > wrote:
> > > >
> > > > Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> > > > > Hi,
> > > > >
> > > > >             xmlns:ex="http://example.com/sample-data/1.0 <http://example.com/sample-data/1.0>"
> > > > >             select="/ex:foo"/>
> > > > >       </yp:datastore>
> > > > >             xmlns:ex="http://example.com/sample-data/1.0 <http://example.com/sample-data/1.0>"
> > > > >             select="/ex:foo"/>
> > > > >
> > > > >
> > > > > NEW:
> > > > >
> > > > >
> > > > >         <yp:subtree-filter>
> > > > >            <ex:foo xmlns:ex="http://example.com/sample-data/1.0 <http://example.com/sample-data/1.0>"
> > > > > />
> > > > >
> > > > >         </yp:subtree-filter>
> > > > >
> > > > >
> > > > > Andy
> > > >
> > > >
> > > >
>  
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 6 Dec 2017 17:14:34 +0000

tl;dr — I agree that we should close this and use a yang-data declaration to define what goes into the “error-info”. Let’s make progress.

However, I also agree with Alex that the solution proposed is clunky, and I don’t think it actually promotes standardised error handling as the conditions we are dealing with here are just not as simple as “sorry, it didn’t work”. The RPC will have worked exactly as intended, and may have provided you with information relating to, for example, how to create a subscription request that will work. It just won’t necessarily have established the subscription exactly as you wanted. The RPC itself executed completely correctly, and thus “rpc-error” seems like an incorrect response. What we are doing here is simply not the same as, for example, an edit config that failed due to invalid data and left the system configuration state unchanged.

But anyway, let’s make progress. Machine readable error-info with yang-data is a step in the right direction, but because of that standardised error handling just isn’t plausible. If we’d reserved “rpc-error” for things that just didn’t work, that would provide cleaner semantics.

Cheers,

Einar

On 6 Dec 2017, at 02:01, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:

Thanks
--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, December 05, 2017 2:20 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Cc: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] yang-push issue: error handling

Hi,

4.3.  <rpc-error> Element

Andy

--- Alex

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 6 Dec 2017 17:44:25 +0000

From: Einar Nilsen-Nygaard, December 6, 2017 12:15 PM

<Eric> Agree.  We initially didn’t use existing error constructs because many of the interactions are not errors.   To make this easier for existing implementations to support, I am fine with piggybacking on the current error constructs though.

Eric

Cheers,

Einar

Thanks
--- Alex

Hi,

4.3.  <rpc-error> Element

Andy

--- Alex

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Dec 2017 19:02:54 +0100 (CET)

Hi,

"Einar Nilsen-Nygaard (einarnn)" <[email-masked]> wrote:
> tl;dr — I agree that we should close this and use a yang-data
> declaration to define what goes into the “error-info”. Let’s make
> progress.
> 
> 
> However, I also agree with Alex that the solution proposed is clunky,
> and I don’t think it actually promotes standardised error handling as
> the conditions we are dealing with here are just not as simple as
> “sorry, it didn’t work”.

In the draft, there is one "subscription-result" called "ok", and one
called "error".  Then there are a bunch of idententies derived from
"error".  Are you saying that these in fact are *not* errors?

> The RPC will have worked exactly as intended,
> and may have provided you with information relating to, for example,
> how to create a subscription request that will work. It just won’t
> necessarily have established the subscription exactly as you
> wanted.

:D  I'll try to remember to use this argument whenever one of my
program craches "it worked, but maybe not in the way you wanted" ;-)

> The RPC itself executed completely correctly, and thus
> “rpc-error” seems like an incorrect response.

I absolutely agree that if you want to return successfully, and
provide some result, you should not put that into "rpc-error".

/martin

> What we are doing here
> is simply not the same as, for example, an edit config that failed due
> to invalid data and left the system configuration state unchanged.
> 
> But anyway, let’s make progress. Machine readable error-info with
> yang-data is a step in the right direction, but because of that
> standardised error handling just isn’t plausible. If we’d reserved
> “rpc-error” for things that just didn’t work, that would provide
> cleaner semantics.
> 
> Cheers,
> 
> Einar
> 
> 
> On 6 Dec 2017, at 02:01, Alexander Clemm
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> I still find this a bit clunky (and I still wonder if we could define
> “corner behavior” instead of error conditions), but OK, let’s go with
> the proposed as outlined by Martin.
> 
> To: Alexander Clemm
> <[email-masked]<mailto:[email-masked]>>
> Cc: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Martin,
> 
> Sure, the eventual solution may make use of rpc-error again.  But
> until we get there, the currently proposed solution seems to make
> sense to me.  I don't think we have an issue today with lots of RPCs
> each defining their own way of dealing with corner conditions -
> definition of RPCs is something that has so far only rarely been
> exercised with YANG models.  Once this becomes more common, I am sure
> we will find a more general solution, but I don't think we are at that
> point.
> 
> --- Alex
> 
> > Cc: Alexander Clemm
> > <[email-masked]<mailto:[email-masked]>>;
> > [email-masked]<mailto:[email-masked]>
> > request
> > > > *From:* Netconf
> > > > *[mailto:[email-masked]<mailto:[email-masked]>] *On
> > > > *Behalf Of
> > > > *Andy Bierman
> > > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund
> > > > <[email-masked]<mailto:[email-masked]>>
> > wrote:
> > > >

---

From: "Alexander Clemm" <[email-masked]>
Date: Wed, 27 Dec 2017 02:35:49 -0800

Hi all,

Getting back to the thread on error handling in YANG-Push.  

In updating the module to move the negotiation hints into <rpc-error> and error-info etc, I have come across another issue for which it is not clear what is the best way to address it in YANG.  It would be great to get some guidance here from some of the resident YANG experts:-)

The problem comes when augmenting the RPCs defined in subscribed-notifications for YANG-Push. As discussed earlier in the thread, the negotiation hints and application-specific error conditions have now been moved into <rpc-error>, specifically error-info (as well as the app-error-tag).  The information to include is defined as part of the description clause pasted below.  

In YANG-Push, we want to add additional information to return as part of error-info.  For this, we would ideally want to augment the description clause of the RPC (previously we had augmented the RPC output parameters, but now this is moving into error-info).  How do we do that?  Clearly, we cannot augment just the description clause.  Given that we are still augmenting the input parameters of the RPC, one possibility would be to use the description clause of that.  This does not seem the ideal place to put it, but what are the alternatives?  Another option would be to not augment the RPC, but define an entirely new RPC (e.g. "establish-datastore-subscription" in addition to "establish-subscription").  This is not preferred (as it would run somehow counter to why we introduced the subscribed-notification mechanism as generalization of YANG-push, as opposed to making them orthogonal) .    Or perhaps there is a third option that we haven't yet thought of?  

Here is the description of establish-subscription in subscribed notifications that we want to augment.

  rpc establish-subscription {
    description
      "This RPC allows a subscriber to create (and possibly negotiate) 
       a subscription on its own behalf.  If successful, the 
       subscription remains in effect for the duration of the 
       subscriber's association with the publisher, or until the 
       subscription is terminated. 
       
       In case an error is returned, the subscription is not created.  
       In that case, the RPC error response SHOULD include an 
       error-app-tag that indicates the reason why the subscription 
       was not created.  Depending on the reason, one of the 
       following strings SHOULD be returned:   
       &quot;stream unavailable&quot; 
       &quot;encoding not supported&quot;
       &quot;replay not supported&quot; 
       &quot;filter unavailable&quot; // referenced filter does not exist
       &quot;filter type unsupported&quot; 
       &quot;filter unsupported&quot; // example: filter too complex
       &quot;namespace unavailable&quot;  
       &quot;insufficient resources&quot; 
       &quot;unsupportable volume&quot; // requested data volume too large
       &quot;no such option&quot; // requested parameter setting not supported
       &quot;DSCP unavailable&quot; // requested DSCP marking not allocatable
       &quot;QoS unsupported&quot; // requested QoS parameter not supported       

       In addition, the RPC error response SHOULD include error-info
       with a set of suggested parameter settings that would have a 
       higher likelihood of succeeding in a subsequent 
       establish-subscription request.  The error-info should include
       the following YANG data:
       // begin error-info       
       uses hints;       
       leaf replay-start-time-hint {
         type yang:date-and-time;
           description
             "If a replay has been requested, but the requested replay
             time cannot be honored, this may provide a hint at an
             alternate time which may be supportable.";
         }
       // end error-info
       ";
...

For the datastore subscription in YANG-push, we would like to augment that YANG-data that the error-info should include.  We also want to add additional app-error tags.  

Thoughts?
--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Tuesday, December 5, 2017 12:35 PM
To: Martin Bjorklund <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] yang-push issue: error handling

Hi Martin,

--- Alex 

> > > While possible, the solution of having to return rpc-error etc 
> > > does strike me as somewhat clunky.  While it is possible to add an 
> > > error-app-tag, and negotiation stuff as error-info (and I 
> > > appreciate the suggestion), that solution would need to be 
> > > described using a lot of prose in description statements a la 
> > > SMIv2 (presumably as part of the RPC description, not as part of 
> > > e.g. the identities, which might be used in a number of places, not just the error-app-tag).
> 
> > > Short of that, the proposed solution of adding RPC output 
> > > parameters that are used for the purpose of indicating what is 
> > > going on at the application level simply makes them part of the 
> > > semantics of the specific RPC itself.  It is not Netconf’s role to 
> > > define what an RPC can or cannot do, just like it cannot define 
> > > what a particular leaf may or may not represent.  That is part of the RPC definition.
> > >
> > >
> > >
> > > volume of updates for a specific implementation is different from 
> > > an error condition such as a malformed message that is missing a 
> > > very well defined in terms of the effect that the RPC has (i.e. 
> > > the effect is that it result in creation of a subscription, if 
> > > certain conditions are met, and it does not result in creation of 
> > > a subscription in case certain conditions are not met).  Why 
> > > should Netconf restrict what an RPC can or cannot do?  This is all 
> > > application-
> specific.
> > >
> > >
> > >
> > > --- Alex
> > >
> > >
> > >
> > >
> > >
> > > reviews.  The problem is actually in subscribed notifications, and 
> > > I think Eric is tracking that issue.
> > >
> > > YANG can be used to achieve the same functionality that these 
> > > drafts try to achieve.  Specifically:
> > >
> > > > If any client (or even server) functionality uses the NETCONF 
> > > > and RESTCONF standard error handling, then subscription-result 
> > > > will not be sent or expected as an error response. Depending on 
> > > > the server implementation, the code that knows about