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

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

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.  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


Eric

> [...]
> /martin