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

["Eric Voit (evoit)" <[e-mail]>]

> From: Martin Bjorklund, September 13, 2018 2:44 PM
> 
> "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.

Yes, that was our original proposal.   The WG requested this change about a year ago.  (I can find the threads if necessary.)
 
> But are you sure that these "other protocols" even has a mechanism to insert
> the new error-info structures into their errors?

We will need to look at them one-by-one.  But I am hoping yes.
 
> > 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.

Thanks.

Eric

> /martin