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

[Alexander Clemm <[e-mail]>]

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? 

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