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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Fri, 15 June 2018 09:01 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.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 45E10120049 for <netconf@ietfa.amsl.com>; Fri, 15 Jun 2018 02:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TbNxASlA7cuW for <netconf@ietfa.amsl.com>; Fri, 15 Jun 2018 02:01:13 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 B0F7612F1AC for <netconf@ietf.org>; Fri, 15 Jun 2018 02:01:11 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w5F9179q006492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <netconf@ietf.org>; Fri, 15 Jun 2018 11:01:08 +0200
Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 15 Jun 2018 11:01:02 +0200
To: netconf@ietf.org
References: <20180613160206.gkutjhxigdxpv2uz@anna.jacobs.jacobs-university.de> <20180614.102216.2199378020340361225.mbj@tail-f.com> <f6f66d0c0a444f2bb0fc770082450037@XCH-RTP-013.cisco.com> <20180614.203959.786029239464099510.mbj@tail-f.com> <20180615062751.obzdeco6oka3ekue@anna.jacobs.jacobs-university.de>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <730b74c2-405c-a894-b8d9-ecf15c62538b@sit.fraunhofer.de>
Date: Fri, 15 Jun 2018 10:56:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <20180615062751.obzdeco6oka3ekue@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.43.163]
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Exf3zhiSsqVsJbx5-_nykKRGk1s>
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: Fri, 15 Jun 2018 09:01:16 -0000

Hello all,

on one hand, I understand the need for interoperability and therefore 
avoid non-interoperable solutions, obviously.

On the other hand, I would strongly recommend to allow for 
non-YANG-molded data here. Over the years we have seen a lot of 
convergence wrt to endpoint-, network- and function- visualization. 
While this might sound like the first sentence of yet another boring 
ivory tower publication - it is a fact that for multiple reasons code 
bases merge to simply onboarding, enrollment, deploylmen and maintenance 
of network equipment.

Using YANG-based interfaces to support this ongoing convergence by 
allowing for non-YANG-modled data is considered vital by a multitude of 
stakeholders. And while it is of course more difficult to enable 
interoperable implementations in this regard, it seems to me due to the 
fact how the "YANG-part" is structured/modled today it is neither 
harmful nor useless to the internet - and in contrast very useful to 
migrate away from older legacy interface.

I am new to the domain of NETCONF, but I am in strong support of 
allowing for non-YANG-defined notification messages wrt migration, 
simplification of implementation and well... simply moving away from a 
zoo of procedures that are already a nightmare. This is a chance get rid 
of that existing "nightmare" step-by-step and provide a path forward to 
enable structural and semantic convergence of data conveyed.

This is why I care very much about non-YANG-modeled telemetry provided 
by a YANG-based interface.

Viele Grüße,

Henk

On 06/15/2018 08:27 AM, Juergen Schoenwaelder wrote:
> On Thu, Jun 14, 2018 at 08:39:59PM +0200, Martin Bjorklund wrote:
> 
>>> An event record is not necessarily a YANG notification, as the event
>>> record's payload might not be driven by the result of a YANG
>>> statement.
>>
>> I don't get this.  Can you give an example of when an event record is
>> not defined as a YANG "notification"?
> 
> Why do we care about non-YANG-defined notification messages? How are
> systems expected to interoperate on such opaque data blobs? Perhaps
> there is a need to reduce complexity in order to get something that is
> coherent and consistent and at the end interoperable. The very goal of
> IETF standards is to enable interoperable implementations; it is not a
> goal to define a framework that allows multiple non-interoperable
> implementations to declare compliance to a standard.
> 
> /js
>