Re: [netmod] [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: netmod@ietfa.amsl.com
Delivered-To: netmod@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 (CET)
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/netmod/QRuckfvGt6FkX-TAcheWzSxGFW4>
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-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