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

Henk Birkholz <> Fri, 15 June 2018 09:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45E10120049 for <>; Fri, 15 Jun 2018 02:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TbNxASlA7cuW for <>; Fri, 15 Jun 2018 02:01:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0F7612F1AC for <>; Fri, 15 Jun 2018 02:01:11 -0700 (PDT)
Received: from ( []) by (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 <>; Fri, 15 Jun 2018 11:01:08 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 15 Jun 2018 11:01:02 +0200
References: <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,


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