Re: [Netconf] mbj's WGLC review of subscribed-notifications-16

[Martin Bjorklund <[e-mail]>]

"Eric Voit (evoit)" <[e-mail]> wrote:
> Hi Martin,
> 
> > From: Martin Bjorklund, September 13, 2018 1:42 PM
> > 
> > Hi,
> > 
> > "Eric Voit (evoit)" <[e-mail]> wrote:
> > 
> > [trimming...]
> > 
> > > > > > > > o  Section 2.4.6
> > > > > > > >
> > > > > > > >   The text says:
> > > > > > > >
> > > > > > > >     1.  "establish-subscription-stream-error-info": This MUST be
> > > > > > > >     returned
> > > > > > > >         if an RPC error reason has not been placed elsewhere within
> > > > > > > >         the
> > > > > > > >         transport portion of a failed "establish-subscription" RPC
> > > > > > > >         response.
> > > > > > > >
> > > > > > > >   (and similar for the other errors)
> > > > > > > >
> > > > > > > >   What exactly does "if an RPC error reason has not been placed
> > > > > > > >   elsewhere" mean?
> > > > > > >
> > > > > > > The intent is to match how NETCONF & RESTCONF historically
> > > > > > > handles errors.  As you know with NETCONF, each error identity
> > > > > > > will be inserted as the "error-app-tag".
> > > > > >
> > > > > > It could also be in "error-tag" and/or "error-message".  My
> > > > > > point is that I don't think that you mean that if an
> > > > > > implementation populate say "error-message", then it should not
> > > > > > popluate error-info with
> > > > > > establish-subscription-stream-
> > > > > > error-info.
> > > > >
> > > > > I do mean that.  I don't think we should send:
> > > > > "establish-subscription-stream-error-info" for NETCONF when there
> > > > > is no hint included.  All the necessary error info is already in
> > > > > the existing message.
> > > >
> > > > But is this really true?  In the
> > > > "establish-subscription-stream-error-info" there is a leaf called
> > > > "reason", which is an identity with a detailed error reason, for
> > > > example "history-unavailable".
> > > > This info is not present anywhere else in the rpc-error, so it needs
> > > > to be present here.
> > >
> > > For NETCONF, this info should be mapped into <error-app-tag>.  See
> > > section 7 of NETCONF-Notif, as well as Figure 10 for an example.  Or
> > > section 3 of RESTCONF-Notif, with Figure 7.
> > >
> > > This was done to align things with existing NETCONF & RESTCONF error
> > > mechanisms.
> > 
> > Ok.  I thought the special error-app-tag thing was removed.  If we have the
> > error-app-tag value, why do we also have the "reason" leaf?
> 
> Because of the need to be transport agnostic.  Other protocols are
> unlikely to have a pre-existing "error-app-tag" construct.

... which is a reason to not do the error-app-tag trick; it would then
work the same across all protocols.

But are you sure that these "other protocols" even has a mechanism to
insert the new error-info structures into their errors?

> And the
> current YANG data structure can be inserted where needed and contain
> 
> > Since I thought that the error-app-tag was removed, I asked Alex to remove
> > them from the examples in YANG push (that doc has examples ;).
> > These examples in YANG push need to put back the error-app-tag.
> > 
> > So now we're back to the main issue.  Is it clear from the SN text when to
> > include the error-info yang-data stuff or not?
> 
> I have added a new sentence which hopefully clarifies this intent within section 2.4.  I have also re-added the second sentence of each bullet to something close to the original text of -v16.  It now reads:
> 
> 
>    There is one final set of transport independent RPC error elements
>    included in the YANG model.  These are three yang-data structures
>    which enable the publisher to provide to the receiver that error
>    information which does not fit into existing transport layer RPC
>    structures.  These three yang-data structures are:
> 
>    1.  "establish-subscription-stream-error-info": This MUST be returned
>        with the leaf "reason" populated if an RPC error reason has not
>        been placed elsewhere within the transport portion of a failed
>        "establish-subscription" RPC response.  This MUST be sent if
>        hints on how to overcome the RPC error are included.
> 
>    2.  "modify-subscription-stream-error-info": This MUST be returned
>        with the leaf "reason" populated if an RPC error reason has not
>        been placed elsewhere within the transport portion of a failed
>        "modify-subscription" RPC response.  This MUST be sent if hints
>        on how to overcome the RPC error are included.
> 
>    3.  "delete-subscription-error-info": This MUST be returned with the
>        leaf "reason" populated if an RPC error reason has not been
>        placed elsewhere within the transport portion of a failed
>        "delete-subscription" or "kill-subscription" RPC response

Ok, I don't like this solution, but I can accept it.


/martin