[netmod] magic leaf 'type' in IETF interfaces

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> Fri, 14 December 2018 17:53 UTC

Return-Path: <jason.sterne@nokia.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 94821130E37; Fri, 14 Dec 2018 09:53:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level:
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 7Lsjk4Gcyoff; Fri, 14 Dec 2018 09:52:59 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150093.outbound.protection.outlook.com [40.107.15.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C92B130DF9; Fri, 14 Dec 2018 09:52:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kQUgBmDRq0B7fMldeCv55dpy3Xem/NV1g3oA/AtRvws=; b=I3ZIBVcbVY1o0PQaQB8NRadrgZbunhCXsqd7VhsWBulJSC7STb41oNYRmmIIyuCsCL4sFqZup50Ke5ehvblH+BzgBWs6AF6qJ8XvvlgcmmN9t/c8c70kntSAzQWzfRxKUOE+uvH2KJT1/aRuVByWC5Cs9L0V51jQrOqe8eX2xnw=
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB5424.eurprd07.prod.outlook.com (20.178.15.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.9; Fri, 14 Dec 2018 17:52:56 +0000
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::85f6:118d:d689:232a]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::85f6:118d:d689:232a%2]) with mapi id 15.20.1446.010; Fri, 14 Dec 2018 17:52:56 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
To: "netmod@ietf.org" <netmod@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: magic leaf 'type' in IETF interfaces
Thread-Index: AdST1E2jOdI/metmQeWzMudzc2MYTQ==
Date: Fri, 14 Dec 2018 17:52:56 +0000
Message-ID: <VI1PR07MB39818BD20967B36B8F24DBA69BA10@VI1PR07MB3981.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.245.20.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB5424; 6:pU6jHCQ02h6ov+J65oElREhY83Qt8qKopgY5SAKPPQ/uzCmJiXONyGPH5XMRO41fIU3gY3YyF0l6gkIOBbp10EoNU7Qu+aP6I0GAnK0SBAoT56aFUpOWIPxfKPxk2Maer3XEsTtjmhpqCzQXFwzvhJoUOJRQasRIZvJIUlqaHRYLn/rpu7WNlfm6r88aTBZvxSpUGrmnmIO8fLMh+qKtkLPTEvwSBBFNM7so2mOBAV5gsNduH82Oqplcc1QBagUyVgewJ5qbPml2HsoidSPyW4DviLQR7w3e95oKLyhzHn5RqEKmoqugqu1r7aPaxy5AdsWPiGBHuY3yTqNq0x6w+IBzzY5aQQiKMKLfCoBX4l0RrmTDYCzpoKUnc9LBwBkZF1erFd+IM1KkazDkiDjXeEYIH196fMaBvjwL+S3r8JoGqOVE4udRy+lvwkfsf+ZLRvUyTIVAqUn/hu88FkUhPQ==; 5:jW7nvVIf/LeGMImEy1lZRln0HNhs0+YLitfLKzKDTT24yg0pot1C9SEJz+7tCswu4rtB1UwbB4iWHZXobLiJyztqBzT68dvoHbh48DsYFWu4+RDc/O32BOW9FgYp43KhEirdbFdfsaT7gmARsHa/ObbOY0C0NKJDFbdjDlMlbe0=; 7:T4eYHW1nno5Mk6Z+HcJbTqaNN8meMci530raECvS40M05+gQvy5Na3HnMRzT2JgFxs+em0Lom+Si8HFXqmfDO7ImqoQyYy8ZQiBSsG4kIGuk+JSuvHvL9zNtmdkBALrGDZuVg0eaG8oeun0Pg/lS6A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a8ce0273-7651-477a-5553-08d661ecfa7e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5424;
x-ms-traffictypediagnostic: VI1PR07MB5424:
x-microsoft-antispam-prvs: <VI1PR07MB5424767D73C0DE796CCF71029BA10@VI1PR07MB5424.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(11241501185)(806100)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231475)(944501520)(52105112)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5424; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5424;
x-forefront-prvs: 08864C38AC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(39860400002)(346002)(366004)(376002)(53754006)(199004)(189003)(476003)(450100002)(14454004)(316002)(486006)(6306002)(55016002)(97736004)(66066001)(9686003)(110136005)(54896002)(25786009)(2501003)(14444005)(106356001)(478600001)(81166006)(6116002)(81156014)(6346003)(86362001)(26005)(71200400001)(3846002)(8936002)(71190400001)(8676002)(6436002)(68736007)(256004)(53936002)(105586002)(5660300001)(6506007)(2906002)(99286004)(186003)(102836004)(790700001)(7736002)(7696005)(33656002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5424; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com;
x-microsoft-antispam-message-info: p5o3iVr2n97z32gTnKlZ/ObKEAgTFf+JZVizcnIFeFtr0/HMv6cgKMpcQIIA28eEWNUc0HJ0JSBiQeYMHWs4OQ5+bJSEAUOCt1LxSF8YAydggjUrBmgldf7X2Rvr8BWkirnA5OmUlyjqSCqQa/22aT6TZiXbrwkk7M7AOsRRcXU4/TvsvSA5d3UHdCUntnozedHfJpX5ZhOyJFMLTvr9jKrDZIqniS3k3+ztQpUmvKBB9GYrDmrkoXHtRqN8vaUCsh9PvoPZEsayTqlgVF23JI7CDFnhxUxVqe2mdEJvJ2/gJU1gSGjiWF3lvr+6qTfx
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB39818BD20967B36B8F24DBA69BA10VI1PR07MB3981eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8ce0273-7651-477a-5553-08d661ecfa7e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 17:52:56.1950 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5424
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/tIvhNg4FXyAN6rfXXO3dKvoqD4U>
Subject: [netmod] 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: Fri, 14 Dec 2018 17:53:03 -0000

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.

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.

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).

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.

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'.

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.

Jason