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

[Martin Bjorklund <[e-mail]>]

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?

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?


[...]

> > > > > If
> > > > > you want to pursue this further it is probably best to start a new
> > > > > thread dedicated to this topic alone.
> > > > >
> > > > > >   For example, what happens if the transport session is lost and
> > > > > >   re-established; are all event records in the buffer replayed again?
> > > > >
> > > > > No.  The publisher will not lose context of what was sent.
> > > >
> > > > This is not clear from the text.  In fact, the text explicitly says:
> > > >
> > > >    The leading event record sent will be the first event record
> > > >    subsequent to the latest of three different times: the
> > > >    "replay-log-creation-time", "replay-log-aged- time", or the most
> > > >    recent publisher boot time.
> > >
> > > I see your point.   I have tweaked the text to:
> > >
> > > " If the publisher does not know the next record intended for the
> > > receiver, the leading event record..."
> > 
> > Hmm, not sure this helps.  How about:
> > 
> > OLD:
> > 
> >    As a result, when any configured subscription receivers become
> >    active, buffered event records will be sent immediately after the
> >    "subscription-started" notification.  If the publisher does not know
> >    the next record intended for the receiver, the leading event record
> >    sent will be the first event record subsequent to the latest of three
> >    different times: the "replay-log-creation-time", "replay-log-aged-
> >    time", or the most recent publisher boot time.
> > 
> > NEW:
> > 
> >    As a result, when any configured subscription receivers become
> >    active, buffered event records will be sent immediately after the
> >    "subscription-started" notification.  The leading event record
> >    sent will be the first event record subsequent to the latest of four
> >    different times: the "replay-log-creation-time", "replay-log-aged-
> >    time", the most recent publisher boot time, and the time of the
> >    last event record sent to the reciever, if any.
> 
> The reason I didn't word it this way is if there are multiple events
> with the same timestamp.  How about the text below...
> 
> NEW 
> 
> If the publisher knows the last event record sent to a receiver, and
> the publisher has not rebooted, the next event record on the stream
> which meets filtering criteria will be the leading event record sent.
> Otherwise, the leading event record will be the first event record
> meeting filtering criteria subsequent to the latest of three different
> times: the "replay-log-creation-time", "replay-log-aged-time", or the
> most recent publisher boot time.

Ok.



/martin



> 
> > > I have also made a corresponding tweak to the YANG model.
> > 
> > In the leaf "configured-replay"?  I couldn't find this text.
> 
> Not in the configured-replay leaf, that looks good to me.  The first
> time this object is configured, this is when replay starts.  If it
> turns out there are multiple subscription-started notifications due to
> transport loss, the YANG model won't change.
> 
> To find the updated text, look for: refine
> "target/stream/replay-start-time"
> 
> Eric
> 
> [..]
> > /martin
>