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

Martin Bjorklund <> Mon, 17 December 2018 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D028F128CE4; Mon, 17 Dec 2018 00:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1SKYOnq6LX6H; Mon, 17 Dec 2018 00:15:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 27369128BCC; Mon, 17 Dec 2018 00:15:08 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id B1FF21AE0397; Mon, 17 Dec 2018 09:15:06 +0100 (CET)
Date: Mon, 17 Dec 2018 09:15:05 +0100 (CET)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
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: <>
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: Mon, 17 Dec 2018 08:15:10 -0000


"Sterne, Jason (Nokia - CA/Ottawa)" <> 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

> 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