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

Martin Bjorklund <mbj@tail-f.com> Thu, 14 June 2018 08:12 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA5E130EA5 for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 01:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0n2ix4yi3zb for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 01:12:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3A112F1AC for <netconf@ietf.org>; Thu, 14 Jun 2018 01:12:08 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 637581AE01AA; Thu, 14 Jun 2018 10:12:04 +0200 (CEST)
Date: Thu, 14 Jun 2018 10:12:04 +0200 (CEST)
Message-Id: <20180614.101204.1206488770523128207.mbj@tail-f.com>
To: alexander.clemm@huawei.com
Cc: kwatsen@juniper.net, evoit@cisco.com, alex@clemm.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB18357@sjceml521-mbx.china.huawei.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB17F84@sjceml521-mbx.china.huawei.com> <20180613.090421.188030980179358538.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB18357@sjceml521-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/JvNhXOnLMfhr1vebgwmxJco-B8Y>
Subject: Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2018 08:12:11 -0000

Hi,

Alexander Clemm <alexander.clemm@huawei.com> 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:mbj@tail-f.com]
> > Sent: Wednesday, June 13, 2018 12:04 AM
> > To: Alexander Clemm <alexander.clemm@huawei.com>
> > Cc: kwatsen@juniper.net; evoit@cisco.com; alex@clemm.org;
> > netconf@ietf.org
> > Subject: Re: [Netconf] comments on
> > draft-ietf-netconf-subscribed-notifications-
> > 12
> > 
> > Alexander Clemm <alexander.clemm@huawei.com> wrote:
> > > Two quick replies inline, <ALEX>
> > > --- Alex
> > > > -----Original Message-----
> > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent
> > > > Watsen
> > > > Sent: Tuesday, June 12, 2018 3:45 PM
> > > > To: Eric Voit (evoit) <evoit@cisco.com>om>; Martin Bjorklund
> > > > <mbj@tail-f.com>om>; alex@clemm.org
> > > > Cc: netconf@ietf.org
> > > > 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
>