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

[Martin Bjorklund <[e-mail]>]

Hi,

Alexander Clemm <[e-mail]> wrote:
> Hi Martin, Eric,
> 
> ok.  I am still not sure why we would need the term in YP then?
> 
> I do agree we need to be clear on the semantics of what it is that is
> being counted.  As you indicate, we should distinguish the number of
> notification messages from the number of event records, specifically
> if they could be different (like in the case of bundles), and be clear
> which one we count here.  I don't think we need to get too fancy with
> statistics here.  If we do count the number of event-records, the
> question is what we count in case of YP; counting the number of
> update-records in that case is probably what makes sense (but
> update-record is defined independently of event-record).  If this is
> the case, perhaps we should update the definition of update-record to
> have the first sentence read as follows: "An update-record is a
> special type of event record that represents one or more datastore
> node updates" (and in this case we would have the reference to event
> record, which would then be a term to refer to from subscribed
> notifications).  Is this what you had in mind?

Yes.


/martin


> 
> --- Alex
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:[e-mail]]
> > Sent: Wednesday, June 13, 2018 12:04 AM
> > To: Alexander Clemm <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: [Netconf] comments on
> > draft-ietf-netconf-subscribed-notifications-
> > 12
> > 
> > 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
>