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

Martin Bjorklund <mbj@tail-f.com> Thu, 14 June 2018 08:22 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 89A511310FB for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 01:22:19 -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 x3n-QO2U3uWd for <netconf@ietfa.amsl.com>; Thu, 14 Jun 2018 01:22:17 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A428E130E03 for <netconf@ietf.org>; Thu, 14 Jun 2018 01:22:17 -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 CE8861AE01AA; Thu, 14 Jun 2018 10:22:16 +0200 (CEST)
Date: Thu, 14 Jun 2018 10:22:16 +0200
Message-Id: <20180614.102216.2199378020340361225.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: evoit=40cisco.com@dmarc.ietf.org, alexander.clemm@huawei.com, alex@clemm.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20180613160206.gkutjhxigdxpv2uz@anna.jacobs.jacobs-university.de>
References: <20180613.090421.188030980179358538.mbj@tail-f.com> <e61d9a8666964a6ca3a7900c71e4f4d2@XCH-RTP-013.cisco.com> <20180613160206.gkutjhxigdxpv2uz@anna.jacobs.jacobs-university.de>
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/k45iVx77yarM14eWBm4QHvgJDsw>
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:22:20 -0000

Hi,

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Wed, Jun 13, 2018 at 03:36:01PM +0000, Eric Voit (evoit) wrote:
> > Each of the terms used are different.  While they all are defined in the first document they are used, let me paraphrase the meanings of the definitions...
> > 
> > Event - something that happened
> > 
> > Event record - the recorded details of a single event
> > 
> > Update record - one or more datastore node updates
> > 
> > <notification> - a structure defined in RFC5277 which is as a wrapper which contains an event record.  A <notification> can exist without any active subscription.
> > 
> > "notification" statement - a structure defined in RFC-7950 section 7.16 which allows the definition of event record types specific to a YANG module. The results of the a YANG "notification" statement are encoded in a <notification>.
> 
> Here is where I am getting lost. The RFC 7950 notification statement
> (its not a structure btw) does define the content of a notification.
> And notification used to be defined in RFC 6241 as a "server-initiated
> message indicating that a certain event has been recognized by the
> server." Your notion of an event record may come from the RFC 5277
> format that adds an eventTime etc. but the relationship of what is a
> YANG defined notification and how it related to your event record and
> the <notification> structure is still unclear.

I don't think we should align terminology with 5277.  More important
is to align with the current set of documents; 7950 and 6241.

If subscribed-notifications is transport-independent, it should
probably not talk too much about <notifcation> etc; this should go
into the transport docs.

7950 says that the "notification" statement defines a notification.
As Juergen pointed out this term is not defined in the terminology
section, but nevertheless the term is used.

Does the WG now want to introduce a new term for what the
"notification" statement defines?  It seems to me that the term "event
record" is being proposed for this.  The answer to this question will
have a big impact on the rest of the terminology.

> > Notification message - a message intended for a specific subscription receiver which includes one or more <notification>. A notification message will have undergone any security/content filtering on embedded <notification> as appropriate for that receiver.
> 
> So how does this fit Figure 1 of RFC 6241? This figure indicates that
> <notification> is a message as seen from the messages layer. You are
> saying a notification message is something else that includes one or
> more <notification>s. Yes, I know that the diagram in RFC 5277 is
> different but the diagram in RFC 6241 is the newer one.

This confuses me as well.

How much of this do we have to define in this document, and how much
should go into the transport docs?


/martin


> > Per the discussion below, I see an update record being a specialized type of event record.  For YANG push, the 'event' is driven by the update trigger: i.e., either the expiration of a periodic timer (for periodic subscriptions), or a change to the datastore (on-change subscription).
> >
> 
> I am missing a definition what an Update record is. It is surely not
> in this email. Anyway, if there are changes to architectural concepts,
> it would be nice to find them in a coherent well explained section.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>