Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces

Jan Lindblad <> Tue, 18 December 2018 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E966124BE5; Tue, 18 Dec 2018 05:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WxoohyhdOmOo; Tue, 18 Dec 2018 05:36:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AD4021200B3; Tue, 18 Dec 2018 05:36:49 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 284EB1B03C8A; Tue, 18 Dec 2018 14:36:47 +0100 (CET)
From: Jan Lindblad <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_78C8BFD7-5283-42AA-BB1B-CB25D5BA2C9C"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 18 Dec 2018 14:36:44 +0100
In-Reply-To: <>
Cc: Martin Bjorklund <>, "" <>, "" <>, "" <>
To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Dec 2018 13:36:51 -0000

> While I agree with Martin, in our systems we have a number of places, where the system does create configuration in running, due to
> different levels of automation and autonomous algorithms kick-in
> the created config needs to be possible to be further modified by the operator
> the created config needs to be referenced from operator created config
> the created config is not always ephemeral, it might need to be part of backup/restore
This is only a sampling from "the list of excuses". I have heard many more. The road to hell is paved with good intentions, however. If we want to build automation based on sound theory, clearly separating the orders from managers from a system's own operational view is key, IMO. Reliability, security, accountability are growing in importance, and they all play in this direction.

We may not need to standardize rules to outlaw the above; the market will take care of that. What we need to ensure is that it is possible to be standards compliant without having to implement design excuses like these.

Best Regards,