Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12

[Martin Bjorklund <[e-mail]>]

Alexander Clemm <[e-mail]> wrote:
> Two quick replies inline, <ALEX>
> --- Alex
> > -----Original Message-----
> > From: Netconf [mailto:[e-mail]] On Behalf Of Kent Watsen
> > Sent: Tuesday, June 12, 2018 3:45 PM
> > To: Eric Voit (evoit) <[e-mail]>; Martin Bjorklund <[e-mail]>;
> > [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-
> > 12
> > 
> > 
> > 
> > 
> > >> Sure, but can YP import the "Event Record" term from SN?
> > >>
> > >> Sure.  It imports other terms.  Alex, do you want to bring it in?
> > >>
> 
> <ALEX> Why should we bring it into YP?  We basically don't use the
> term there.  We use "update record" (which we do define).  </ALEX>

Alex, see the previous emails in this thread for context.  The initial
problem was the counter "pushed-notifications" in
subscribed-notifications.  Eric suggested to rename it and describe it
as:

         leaf count-sent {
           type yang:counter64;
           config false;
           description
             "The number of event records sent to the receiver.  The
             count is initialized when a dynamic subscription is
             established, or when a configured subscription
             transitions to the valid state.";

The question is what this leaf really counts.  Does it count the
number of <notification> messages sent?  The number of "event
records"?  Does it include "update records"?

(Does this change if we have a mechanism to bundle several event
records into a single <notification> message, as has been proposed?)



> > >> Also, I think that the definition could be improved.  It currently reads:
> > >>
> > >>    Event record: A set of information detailing an event.
> > >
> > > Yes.  But the word 'event' here is itself defined as:
> > >
> > >   Event: An occurrence of something that may be of interest.  Examples
> > >   include a configuration change, a fault, a change in status, crossing
> > >   a threshold, or an external input to the system.
> > >
> > >Reviewers have liked separation of the event itself from the record about it.
> > 
> > 
> > I'm okay with separation.  On one hand, it seems like common English, but it
> > might be good to have it well-defined in this draft.  Still it seems that the
> > definition could be improved, maybe by contrasting it to an event?
> > One is the what happened, the other a record about what happened...
> > 
> 

> <ALEX> The separation makes sense and I think is something we always
> had in mind.  I am not clear what is needed.  We currently have
> "event record", which is distinguished from the "event" itself, and
> the "notification message", in addition to "event stream".  (We
> could rename "notification message" to "event notification message",
> which woudl become rather lengthy; we did not call it "event
> message" since there might be notification messages that notify of
> updates, which are different from events.)   
> In short, I am not convinced that any changes are needed; I do think
> we have captured the right terms; but of course if you would like to
> see alternative definition text please make a suggestion.   

As Juergen noted you have "event record" and "notification message"
defined as new terms in subscribed-notifications.  It is not clear how
this relates to YANG's "notification" statement and RFC 6241/5277
<notification> message.

I *think* that YANG's "notification" statement defines an "event
record", and that your term "notification message" is the same as
6241/5277 "notification" (message).

Also, I think that an "update record" is represented as one of
"push-update" and "push-change-update" YANG notifications.  So aren't
these "event records"?  I.e., an "update record" is a special case of
an "event record"?



/martin