[yang-doctors] Style question from individuals working on IEEE YANG

Scott Mansfield <scott.mansfield@ericsson.com> Wed, 15 January 2020 12:15 UTC

Return-Path: <scott.mansfield@ericsson.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE13120119 for <yang-doctors@ietfa.amsl.com>; Wed, 15 Jan 2020 04:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=ericsson.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 RaSoo5X0PjPw for <yang-doctors@ietfa.amsl.com>; Wed, 15 Jan 2020 04:15:22 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760055.outbound.protection.outlook.com [40.107.76.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4111612006D for <yang-doctors@ietf.org>; Wed, 15 Jan 2020 04:15:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eSgRBTjkcQQ5pSBN/V5VfaGhnTu8YnMAXOnEn01UbkS3bvsvuhEMrUGUBdx7j0c5GQ5ri20i6IghWcYQlWuWoXJrp2/aIa98+sSP6ABX2NKt6cJ7DzZK5H/TD52nd5TAHSnOJtJ2afF865XljePyZ8sNyc1Rh8fz8tqOaEd48Ld2DEKJup5WBLR3SOZ4Xm+FyPtvpAldTloJ27uaW2fb0sTG0qWVzq9c5Y8dlTrmKA5EOGe4CGfixUV8vwX8SHyqVTPvAfvvzI+Nrpz7bJWU1LzU/4vANOdA6HHAFA0HRE2zPhWn68LP6kXa4ilpoby085Xwib4SO0gAVxEULgLnPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gUv2H9gIhMCOl9kXrNHbM5oEkKzSb7rhns4GKs9YIbY=; b=A0hiXUAzXBrHVPCSdXLy+48n2FT7oLddrqIw/mWrcqLnAYmdHPYFz383GC3tRG0jnVSJFQEXFzLnxW2nJVhNoFCqKXL7Ry2A98Ky4WfmIrKXydaHbuekZOJG23+3BCnnXiTQOz7+llIWfuP2rtFMxR3K3NAvxhD4f2Bw2t2uNya8wRPM81PO+Owc8ZHdR0g6kedU37xp1yLj0elefAeDKSiJB6/sdxUebX22kdGLMkZaxCAwEgHBWPfFxWf51uuGt7VAhMdf+0fYGXMTC4GomffPHtH1MUoAcvXvr/bTsX05oefATtPhv93v40q4z6xINe1gafTVmE2ggqrvsOu04A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gUv2H9gIhMCOl9kXrNHbM5oEkKzSb7rhns4GKs9YIbY=; b=EwhE83ej2gtsq66yn/fnWHqbX423a0k/v8hwgVxJ2CQGNVfzVOeAKROKW+xwAIyGhzYxKqHoCwmo/bJKBbNUrJeE9Gb1NZyBYDzfsRHMn2+8te836PDzOpYZ89NFZ6efI5W/NHoma36CGuKvkRrPHgIhpSo0Ve9Tp4guIxuiy6Y=
Received: from SN6PR15MB2382.namprd15.prod.outlook.com (52.135.65.142) by SN6PR15MB2224.namprd15.prod.outlook.com (52.135.64.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 15 Jan 2020 12:15:19 +0000
Received: from SN6PR15MB2382.namprd15.prod.outlook.com ([fe80::a4aa:2664:390f:8ecd]) by SN6PR15MB2382.namprd15.prod.outlook.com ([fe80::a4aa:2664:390f:8ecd%4]) with mapi id 15.20.2644.015; Wed, 15 Jan 2020 12:15:19 +0000
From: Scott Mansfield <scott.mansfield@ericsson.com>
To: "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Thread-Topic: Style question from individuals working on IEEE YANG
Thread-Index: AdXLnSlUWHhFHNStQciOhysBaa3xVg==
Date: Wed, 15 Jan 2020 12:15:19 +0000
Message-ID: <SN6PR15MB23827FBAD5C61D8868ECECEE8B370@SN6PR15MB2382.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=scott.mansfield@ericsson.com;
x-originating-ip: [24.154.234.238]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4200ee4b-226c-4f24-b097-08d799b49692
x-ms-traffictypediagnostic: SN6PR15MB2224:
x-microsoft-antispam-prvs: <SN6PR15MB2224078C244D37F4A940E6C88B370@SN6PR15MB2224.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:541;
x-forefront-prvs: 02830F0362
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(189003)(199004)(66616009)(316002)(66446008)(76116006)(8936002)(66946007)(81166006)(64756008)(66556008)(86362001)(66476007)(8676002)(6916009)(52536014)(81156014)(2906002)(5660300002)(71200400001)(7696005)(9686003)(478600001)(33656002)(26005)(6506007)(186003)(44832011)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR15MB2224; H:SN6PR15MB2382.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TzxNVsJooeTmjEUj4Kxvyvid4Vj5E/HZu306UXfeQAz9QH753GQ9HZ9VRsEa1tpDdYIoKeZ5CMOe98gAJbgNfpi3un2vAH4uIZDi24UH4kd9pOlAmQZS2sWcXErzolvDoFpzdwXtbY/4CQ0A+oOHIMyQoU6Skz9QLBKs8n9VEGyEoQZYq+02pHyyHzXC6c+RPED+TQ1ef8kJdDzuZpyBnOqdoswHuOpqNXDij4PzAbCtXnoizRpkDQ98Xc18ndBmvzibqJn/B2B+9zxD33t4N812wE2LblhHsW9XuPRXb/Y8xtXVnGlnN1k3/SXFt9TlJqurcaqJdezVOWTI142sLn4SwTBXuaYl7iooutzGUaikno995sbI/g77zQFkqGP9OgoMcelTnSM5W69EBs6E8wU3xc4x8IYNi73aNIM9v6yZIPQOwuONpxwWE+gutzP1
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0075_01D5CB73.8A0923B0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4200ee4b-226c-4f24-b097-08d799b49692
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 12:15:19.4454 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Fnl1awpSPBIZAfFYiRmvB6uZU7o6tHPpHpgGLV9/3zEJ0mrFscyqzCK6wy4YKkualUaiT8Xru+b265CM18kJqZfN2RxGz05EgJb4gwZ5tes=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2224
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/usdfFP6EbgBcH-YdSOsG4It3U7Q>
Subject: [yang-doctors] Style question from individuals working on IEEE YANG
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 12:15:28 -0000

This is an informal request to poll the YANG Doctors on a topic under
discussion

in the IEEE 802.1 working group.

 

The YANG people from IEEE 802.1 discovered a symmetric modelling issue
related

to YANG lists, and kindly request for feedback about the common practices in

YANG modules beyond those from IEEE 802.1.

 

Consider the following YANG code example:

01: leaf my-list-size {

02:   type uint32;

03:   config false;

04:   description "The number of elements in 'my-list'";

06: }

07: leaf-list my-list {

08:   type my-list-element-type;

09: }

 

The state value of leaf my-list-size (L01) needs to be consistent with the

number of elements in leaf-list my-list (L07). Therefore, IEEE 802.1 

identified the following options:

A)           Delete the size leaf (i.e., my-list-size).

B)            Formulate consistency requirements in IEEE standards documents

C)            Formulate consistency requirements in YANG description nodes
(e.g., L04).

D)           Formulate consistency requirements in YANG must statement(s)

E)            ???

 

The rationale of option A) is that a leaf-list implicitly provides the
number of

contained elements. NETCONF <get-config> or <get> operations can be used to

retrieve all list elements content from a server, and thus the number of

elements is also known to the client. A redundant size leaf is entirely
avoided. 

The main concern in this approach is the associated amount of data to be

transferred from server to client. As a practical example, a client
requiring

the number of entries in a Filtering Database (FDB) entries would read

potentially thousands of entries (IEEE 802.1Q does not specify a limit
here).

One might argue that clients don't have to know the number of elements in
the

FDB. However, the question whether there is a need or not is not the point,
it's

just an example, and there are several other, less commonly known, lists

specified by IEEE 802.1 standards for which monitoring the size information
is

inevitable in practical use. Coexisting size leafs like leaf my-list-size

appears more efficient for this purpose. 

 

As soon as a size leafs for list elements (or specific subsets, such as FDB

entries of a particular type) exist, it is required to ensure consistency

amongst a size leaf and the associated list in an unambiguous manner.
Network

equipment specified by IEEE 802(.1) standards is often configured by
machines.

For example, a centralized controller device might compute and upload

network-consistent configurations to all devices in the network. As a
result,

configuration of such networks is lacking human intelligence - unambiguous
and

deterministic behavior is required, and thus it is also required that the

relationship between lists and associated list size nodes is specified
cleanly.

 

Considering option B), such specification can (and is in many cases) be
located

in IEEE standards documents for the associated managed objects. However,
there

are concerns from IEEE 802.1 that implementers might accidentally oversee
such

statements (e.g., IEEE 802.1Q-2018 is a document with more than 2000 pages).
It

is better to locate such information in YANG.

 

Option C) sketches such a specification in the YANG code in a human readable

manner,  but it has some drawbacks. First, unambiguous normative verbal

formulation can become long, YANG files become large, such strong normative

specification is not helpful for client-side users and thus make the

descriptions more heavy-weight. Second, machines (e.g., YANG compilers)
cannot

interpret this specification.

 

Option D) appears to address these drawbacks: must statements allow machine

readable XPath expressions (and also readable by humans). Moreover, must

statements are separated from information in description nodes relevant for

client-side users. However, IEEE 802.1 is not fully aware of the
feasibility,

limitations, and implications of this option. IEEE 802.1 could not discover
such

a use of must statements in IETF's published YANG files, such that feedback
from

other SDOs on this option would be highly appreciated.

 

Opinions desired and appreciated!

 

Regards,

-scott.

Scott Mansfield

Ericsson