Re: [Netconf] magic leaf 'type' in IETF interfaces
Martin Bjorklund <mbj@tail-f.com> Mon, 17 December 2018 08:15 UTC
Return-Path: <mbj@tail-f.com>
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 D028F128CE4; Mon, 17 Dec 2018 00:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1SKYOnq6LX6H; Mon, 17 Dec 2018 00:15:08 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 27369128BCC; Mon, 17 Dec 2018 00:15:08 -0800 (PST)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id B1FF21AE0397; Mon, 17 Dec 2018 09:15:06 +0100 (CET)
Date: Mon, 17 Dec 2018 09:15:05 +0100
Message-Id: <20181217.091505.218628572185200621.mbj@tail-f.com>
To: jason.sterne@nokia.com
Cc: netmod@ietf.org, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <VI1PR07MB39818BD20967B36B8F24DBA69BA10@VI1PR07MB3981.eurprd07.prod.outlook.com>
References: <VI1PR07MB39818BD20967B36B8F24DBA69BA10@VI1PR07MB3981.eurprd07.prod.outlook.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/bbpP3GkVQ9HlJO644cTIiSM8C8Q>
Subject: Re: [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 17 Dec 2018 08:15:10 -0000
Hi, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> wrote: > Hi all, > > Cross posting because I'm not sure whether this is more of interest to > NETCONF clients or a general YANG & datastore question. > > In IETF Interfaces there is a leaf 'type'. Here is a snippet of the > model: > > leaf type { > type identityref { > base interface-type; > } > mandatory true; > description > "The type of the interface. > > When an interface entry is created, a server MAY > initialize the type leaf with a valid value > > This says that although the leaf is mandatory, a NETCONF client > creating a new interface does not have to specify/provide that > leaf. That strikes me as the first unusual point. Yes, unusual, but "safe" in the sense that a client that doesn't have code for this special case will just see the "mandatory true" and provide a value for the type as well. > Secondly -> this also means that a NETCONF client may send a config > with elements X, Y, and Z, but then later read back the config to see > X, Y, Z and T (e.g. type). But they never configured the type leaf. Right, but again this only happens for clients that know this special rule. > Shouldn't most clients generally assume that what they write, they > read back (unless there are 'choice' or 'when' statements involved of > course, but that are part of the YANG and any auto-clearing behavior > from those would be expected)? > > Or does 'anything go' / 'market decides' when it comes to behavior > like this explained in 'description' statements? > > Is it just fine that some NETCONF servers auto-magically create some > (extra) data nodes inside a list entry that a client created? (would > like to see opinions from multiple people on this - especially client > developers). In general, my reply is "no, that is not fine". The reason for this unusual design is that most existing systems code type-info into the name of an interface ("ethX", "ge-X/Y/Z", "GigabitEthernet-X/Y" etc), and having to provide the type in the name and in a special leaf would just be redundant and error prone. The thinking at the time was that the interface model that we designed had to adapt to how existing systems behave. > I would think that each and every magic creation/deletion/changes done > by a server (i.e. that aren't part of the YANG, except perhaps part of > a human-readable (non-machine parsable) 'description' statement) would > require some special handling code on the client (or app above the > client) side. Yes. But as long as this special handling is optional in the client I think it is ok. > I can imagine several alternatives to the way it was modelled above: > 1) NMDA approach: make the leaf optional. If the operator doesn't set > that leaf, then reading the conventional datastores doesn't return > that leaf. But reading the operational DS could return the actual > system selected value. > > 2) separate config & state leafs for 'type': make the leaf > optional. If the operator doesn't set that leaf, then reading the > conventional datastores doesn't return that leaf. But have another > state leaf called 'oper-type'. Both these cases assume that the type can be derived from the name. > I'm not proposing to re-open the IETF Interface model. Just using it > to ask questions about server created config data and explore > alternatives. The rule of thumb is to avoid server created config as much as possible. /martin
- [Netconf] magic leaf 'type' in IETF interfaces Sterne, Jason (Nokia - CA/Ottawa)
- Re: [Netconf] magic leaf 'type' in IETF interfaces Martin Bjorklund
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Balázs Lengyel
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Jan Lindblad
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Ladislav Lhotka
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Andy Bierman
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Jan Lindblad
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Ladislav Lhotka
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Andy Bierman
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Qin Wu
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Qin Wu
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Netconf] [netmod] magic leaf 'type' in IETF … Andy Bierman