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

"Belotti, Sergio (Nokia - IT/Vimercate)" <> Thu, 20 December 2018 09:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36B24131110; Thu, 20 Dec 2018 01:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.964
X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y4QTJ4xpM4aq; Thu, 20 Dec 2018 01:08:29 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe0e::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E937013110D; Thu, 20 Dec 2018 01:08:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/54RMHUcmOMAgpR+PnDJdI+WXVkDZOQv7RkH6mUcJk=; b=FEPqP8nxXsHoGtLC2Tt1bZEGshdfvGkU68g7hQibpSRb10kD81zvJX25qAAItWNxiay8LlMIwlW6/vhIPEIV/4uqJHcq8BfG148HN7oJJH/QeSp30Bf6+XEhqm0O87ov2BgyxR6+MaUsiTVKWUmTGybjCIuiYWMvQhPEGdxUBeI=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.13; Thu, 20 Dec 2018 09:08:23 +0000
Received: from ([fe80::2472:b9b2:f133:85e8]) by ([fe80::2472:b9b2:f133:85e8%3]) with mapi id 15.20.1446.020; Thu, 20 Dec 2018 09:08:23 +0000
From: "Belotti, Sergio (Nokia - IT/Vimercate)" <>
To: Andy Bierman <>, Jan Lindblad <>, "" <>, "" <>
Thread-Topic: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
Thread-Index: AQHUlv2bHKpB64q9oEOoL5It3/ZnuKWFzQ4AgABPvgCAAEuGgIAA7vXg
Date: Thu, 20 Dec 2018 09:08:23 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: it-IT, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4723; 6:02WJceh7Yjoaf7TLGMIEj37umQvSJ7itqgUL/Mvwygqba33yGki4HB+LgUH/0daP4r9T626JnwbKFZ6Yz24dXu0orHT3uLsLop7FXgklcnWQPF9WsWI9yRdEcc75nu31g5ZRgOze9NziBLz87svAanX2yNAOxBpvR+2IKcXbBCxBvpNzutb3Zu1cZ37BLYKva7xrz2wQRObXG2i4Dc7CDHFT29qaavZhKWk11vCOrDKqpt5vZB7YsJoptQH3m0kQArZZ47tH39N/EnF7cOPUCisGWertGjI5JIuToQxF1lb5HsqGR5q05q4tmBrybOQNtZOOo6x16ZRVbUyQ6C13ByFL7W/b8T/NDY7JAK2bfkz4YCsLU0PXwEnXcmxnua0wCY4n3BJJkZmHXAKboAyTTFsXdoEzETMeIokM81JLms5t/vcUvfZdi7k7OpC86qavgvtERVNPhliojn8vx0Iqaw==; 5:dgPHIUvXEhMsKwtWBp8ZK7AzMvzEo8LjVI0tBvJIYUGA4YIzeN2ktn9mEcS3htYW7Rsvno5mvMdcioQFyXOTKxydZqfmwgfJ6bD6hFSCECx0yaM4T73fhXrM00l08j6fU8m07j8vkt6QHrGqK/1OWYx6iRsAGqxhQl4fedzM6Uc=; 7:lnR0LAEzbikRXWrkUmMmf4Jj2ss+9Fr2ChHP/DvlgyflmYXGqZrwqnyt0/aWuIIdgOv9KwaXfB1KZKMgP95WQQlq4+kE5xyhuOU4bKNWDVFu2lr3/K/YWxHQ9F2mxSjONs7fyt0eH5woea2+aGLrOA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: e6c3417d-3552-48bc-8686-08d6665ab20b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB4723;
x-ms-traffictypediagnostic: AM0PR07MB4723:
x-microsoft-antispam-prvs: <>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(11241501185)(806100)(5005026)(6040522)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4723; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4723;
x-forefront-prvs: 0892FA9A88
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(136003)(396003)(52314003)(43544003)(189003)(199004)(478600001)(53936002)(14454004)(8676002)(105586002)(186003)(2906002)(74316002)(7696005)(33656002)(26005)(97736004)(9686003)(71200400001)(71190400001)(86362001)(236005)(2201001)(14444005)(256004)(68736007)(55016002)(11346002)(54896002)(6306002)(8936002)(476003)(6116002)(114624004)(110136005)(606006)(102836004)(3846002)(2501003)(53546011)(6506007)(966005)(66066001)(486006)(76176011)(9326002)(446003)(6246003)(229853002)(81166006)(81156014)(7520500002)(316002)(790700001)(106356001)(25786009)(5660300001)(99286004)(93886005)(7736002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4723;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 8/u5r0IZlOsK0QTEDLYqhuGFFgiCnwtTVoovzPwWoMJUfrselhY+QOAlK+/qcaCns8c53u0VHsruvB83iNMa59vgoaLqJHhX9J5yHgxbjCTYvh6Or+ydeLjl02ykNWfJLAEXJAcFmav7pSaEVaKpeVCLbSzKbyoJfD9sIfJ5kn3jg5NfcxEcrCqzXrAx/wPUH98zBa1TiVw8A9aVohoo64VIMC/I3vnDvDkdBlmxyo6Dqip7zZmhRcMnfzAvSF/drpMw0nYyqAJKvXfbEIRIulaJUFN6LECGFosGPKlreCRVzi/qjGEVRRczIFb9w0F6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5921ADC000E6FFF7E418F2EB91BF0AM0PR07MB5921eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e6c3417d-3552-48bc-8686-08d6665ab20b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2018 09:08:23.8952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4723
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: Thu, 20 Dec 2018 09:08:34 -0000


On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka <<>> wrote:
Jan Lindblad <<>> writes:

> Hi,
>>> 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.
>> NMDA has a lot of room for proprietary mechanisms for converting <running> to <intended>.
>> Many times the features desired by engineers exceed the capabilities of YANG, such as
>> a dynamic default leaf.  YANG allows a simple constant, and no business logic to pick the default.
>> This is a very valid use of "server auto-magic".
>> Maybe a future version of YANG can improve the client visibility into this "auto-magic"
> As you say, this is not uncommon. I usually recommend to leave out any
> default statement, and write in the description what happens if this
> leaf isn't set. The operator can then override the default by giving a
> value.

Anyway, this is not a case where the server writes something on its own
to a configuration datastore.

I don't think it is a problem if NMDA or non-NMDA servers write to <running>.
Just part of the complexity that is baked in -- NMDA does nothing to help the client know
why <running> is different than <intended> anyway.

SB>> But RFC 8342 says :

“It represents the configuration after all configuration transformations to <running> are performed (e.g.,template expansion, removal of inactive configuration)”

So my understanding is that by definition “intended” can be different from “running”.
Am I missed something?

> While some more advanced features for default values may be of some
> utility, the simplicity of YANG is also important. We don't want to
> make the YANG models -- the interface contracts -- the new place for
> all business logic.


I am not proposing YANG needs a new default-stmt. There is a description-stmt
and vendors can add their own extensions to flag auto-magic data nodes.


> /jan



Sergio Belotti
Senior System Engineer and Standardization Architect
IP/Optical Networks, Optics BU
M: +39-335761776
Via Energy Park, 20871 Vimercate (MB) , Italy<>

> _______________________________________________
> netmod mailing list

Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67