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

Alexander Clemm <alexander.clemm@huawei.com> Wed, 13 June 2018 17:15 UTC

Return-Path: <alexander.clemm@huawei.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 3C721130EE5 for <netconf@ietfa.amsl.com>; Wed, 13 Jun 2018 10:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 1K7OL1VE6BTc for <netconf@ietfa.amsl.com>; Wed, 13 Jun 2018 10:15:36 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE9F130E6C for <netconf@ietf.org>; Wed, 13 Jun 2018 10:15:36 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F1E626319A88B for <netconf@ietf.org>; Wed, 13 Jun 2018 18:15:31 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 13 Jun 2018 18:15:33 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.141]) by SJCEML701-CHM.china.huawei.com ([169.254.3.168]) with mapi id 14.03.0382.000; Wed, 13 Jun 2018 10:15:27 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "kwatsen@juniper.net" <kwatsen@juniper.net>, "evoit@cisco.com" <evoit@cisco.com>, "alex@clemm.org" <alex@clemm.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12
Thread-Index: AQHT/nTP5uT1VwdzTU2cEQAJ+CXbrKRVz9AAgAC3XYCAAEcoAIAAEmGAgAAJooCABrN1gIAABFCAgAAUYgD//5bkkIAA9I2AgAAyCjA=
Date: Wed, 13 Jun 2018 17:15:26 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB18357@sjceml521-mbx.china.huawei.com>
References: <b44492127969401f8b72f2e3dd67d58e@XCH-RTP-013.cisco.com> <4A685312-E065-4DF6-9BB1-BCC52947F1CA@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB17F84@sjceml521-mbx.china.huawei.com> <20180613.090421.188030980179358538.mbj@tail-f.com>
In-Reply-To: <20180613.090421.188030980179358538.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.209.216.179]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ldPt6OjIzFRFnK_d6R-RntKCBZA>
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: Wed, 13 Jun 2018 17:15:39 -0000

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