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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 13 June 2018 16:02 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 448EA130E5C for <netconf@ietfa.amsl.com>; Wed, 13 Jun 2018 09:02: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] 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 SegKlNO3mv9R for <netconf@ietfa.amsl.com>; Wed, 13 Jun 2018 09:02:08 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id ABB98130E52 for <netconf@ietf.org>; Wed, 13 Jun 2018 09:02:07 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id EBDE4222B96D; Wed, 13 Jun 2018 18:02:06 +0200 (CEST)
Date: Wed, 13 Jun 2018 18:02:06 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>
Cc: Martin Bjorklund <mbj@tail-f.com>, "alexander.clemm@huawei.com" <alexander.clemm@huawei.com>, "alex@clemm.org" <alex@clemm.org>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20180613160206.gkutjhxigdxpv2uz@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>, Martin Bjorklund <mbj@tail-f.com>, "alexander.clemm@huawei.com" <alexander.clemm@huawei.com>, "alex@clemm.org" <alex@clemm.org>, "netconf@ietf.org" <netconf@ietf.org>
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> <e61d9a8666964a6ca3a7900c71e4f4d2@XCH-RTP-013.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e61d9a8666964a6ca3a7900c71e4f4d2@XCH-RTP-013.cisco.com>
User-Agent: NeoMutt/20180512
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eGbwuZOfWR3cOZ8NDqUiGdnNevs>
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 16:02:11 -0000

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

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