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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 16 January 2020 10:39 UTC

Return-Path: <rwilton@cisco.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 00E7C120048 for <yang-doctors@ietfa.amsl.com>; Thu, 16 Jan 2020 02:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Z3EKGsXz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hK0UaAE6
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 CFIm8geZ7DPk for <yang-doctors@ietfa.amsl.com>; Thu, 16 Jan 2020 02:39:14 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8C8120019 for <yang-doctors@ietf.org>; Thu, 16 Jan 2020 02:39:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3366; q=dns/txt; s=iport; t=1579171154; x=1580380754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B1IjvY5zWHuCoFQPVvxopcprUsXz83/z2J7Hbi50Yfs=; b=Z3EKGsXzT8uX4yg4E4BrnQGzM4r+og5tPdkhA8939nA3A4BOnWHb/Nk9 Jiaa/aOyc/4VbNKDmm3V0pqaPJpbPayuAJrRWJ+fL9f4eCXxPUWLa3rR3 z+k3QwYbWCv4OQ5i/czfMf7CuzLIuz9E11IYI3TCrRGK9+SqU/yCRBR2Y g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AGqiPhxPKkJzl+DLHIM4l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByBgC6PCBe/40NJK1bBwMcAQEBAQE?= =?us-ascii?q?HAQERAQQEAQGBe4FUUAVsWCAECyoKh0wDiniCX4EBlw2CUgNUCQEBAQwBAR8?= =?us-ascii?q?OAgEBgUyCdAKCAiQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEDARIuAQE3AQs?= =?us-ascii?q?CAgIBCBABBAEBAS4bFx0IAQEEDgUIGoMFgkoDDiABAp9LAoE5iGGCJ4J/AQE?= =?us-ascii?q?FhSoYgg0DBgWBMYwYGoFBP4ERR4IXBy4+gmQEgTYtBRomgnuCCiKXM5gdCoI?= =?us-ascii?q?5lkuacKlgAgQCBAUCDgEBBYFpIoFYcBU7gmxQGA2IAYNzM4ogdAIBgSaLQwG?= =?us-ascii?q?BDwEB?=
X-IronPort-AV: E=Sophos;i="5.70,325,1574121600"; d="scan'208";a="413726504"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jan 2020 10:39:13 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 00GAdCB9010380 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jan 2020 10:39:13 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 04:39:12 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 04:39:11 -0600
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 16 Jan 2020 04:39:11 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HwIGSYebmRgsQcGzjl/tvBItn8c3jhBgJTNNoRCLDP8E4R4QFqq72GXYDECvaO2pi03/F8JnbMqQfPCfKCumC0LWN3HaXfRqif972HXURJcnWQCxAxlERJoYjX8cn0s8wpZWei5TaR2dFFAbETzBH84m8FakCILCi2kKhpToXtF8XhUyv/PxL5PeKYK8/AX4+LqN0dXrRAl8tELjsWdxFiKFxkhPLtP02dhxtSDAWhhAh/q/DZs2UWD1wwnQBO9wAf+vpOoPMsQXAUqfmxciQJKWQIuJEWRlTy2iaLZEEDi0GC9ffitOxhk030AFdt6J4URNAdG4tsneOXT2VGD2tg==
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=T652X/GxAFDadGpYps7/m3hAevnd43YvzPT/FA5xjpI=; b=eMsT8n0cNEEsCcPN/fw753UVdC61bT8UXJq2jQEr0w8V3OeC2FhjNo1FPA2ZMZekAzM6gJ+I9QHUe/VKq3WxD9kHoJMfXcDF8xLMRDty7KaEOLe2eFbOCjOHKGSvNOfiCA9hIUJ66JVgf7/ub/+/iuRblrUGg1+IL3Zw71xt5KtulHtwvyalm6BmeV9vVaMsyCCWgGxi0r9qe+94WSuEYoC1cE27SqRNYVVFy4LYPQXnnmX6gmO6CtW3IfohG3wYbA5pQZ7uvKLqtf+X7MLn4QA4EUrGqC4OansUrqN/xKUEcbdeVQWaDLo4QsyPCyyRoxQU9b4kMQDVqEjmU0qrsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T652X/GxAFDadGpYps7/m3hAevnd43YvzPT/FA5xjpI=; b=hK0UaAE6sH3ndIvSkuvM9ulSLrldqPW+TTFhIjcFiz/4rR5NOMHtk7hWT0IbbFCivtLbS7LRBUZiNTGxaR637XgSmAQ3HgPXxwVOgP3SWe+ras9vY3vmfkTAiipcCYIClZLwgbaGOYSbtIbTVEAerKOs4vD5j3UGM1tWQ/tHxOA=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4480.namprd11.prod.outlook.com (52.135.39.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 16 Jan 2020 10:39:11 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2623.018; Thu, 16 Jan 2020 10:39:11 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>
CC: Martin Bjorklund <mbj@tail-f.com>, "scott.mansfield=40ericsson.com@dmarc.ietf.org" <scott.mansfield=40ericsson.com@dmarc.ietf.org>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Thread-Topic: [yang-doctors] Style question from individuals working on IEEE YANG
Thread-Index: AdXLnSlUWHhFHNStQciOhysBaa3xVgABmjaAAAK3poAADrsggAAa57xA
Date: Thu, 16 Jan 2020 10:39:10 +0000
Message-ID: <MN2PR11MB436649C1835D1A98216FA153B5360@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <SN6PR15MB23827FBAD5C61D8868ECECEE8B370@SN6PR15MB2382.namprd15.prod.outlook.com> <20200115.135907.604098548525922549.mbj@tail-f.com> <MN2PR11MB4366BE4459F74059C2B246C2B5370@MN2PR11MB4366.namprd11.prod.outlook.com> <20200115211843.kr5ocofl4s7jggus@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200115211843.kr5ocofl4s7jggus@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.36]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b41d6403-7160-47bc-83fe-08d79a7052b4
x-ms-traffictypediagnostic: MN2PR11MB4480:
x-microsoft-antispam-prvs: <MN2PR11MB44809AC9320ED147CB0101A9B5360@MN2PR11MB4480.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02843AA9E0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(376002)(39860400002)(189003)(199004)(478600001)(54906003)(76116006)(53546011)(186003)(6506007)(4326008)(66574012)(316002)(7696005)(71200400001)(6916009)(55016002)(33656002)(9686003)(81156014)(5660300002)(86362001)(81166006)(8936002)(8676002)(26005)(66946007)(66556008)(66446008)(64756008)(66476007)(52536014)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4480; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: isRhhSQRXVvsVEaIpLecRBfHCjCkq7w4w06t4AGO6jE1lb9lxu2d4ak3w1gWamKlebbIjx5NZ01bkfKsjfSewqJ2sfiYOC4VMp8HFrSqby6mYPzTMWYYyT9nZp6RREglKtbg60asUqj9EDm0tiJ51I4xKalsXL/ddEWTJjylW57ARMb0h96BFMzoFClCOPwAeHULh+COkYZ/46V/Cl76AOOeJtV0C2WJVZvUKviRHAIUa/ocLBb6Sp1jGc6eb9mEBSDLGANuPmc33qUr5I2VV09XEpVhFuVL/vXXeCTz+FePsAu6NvH9dPjH7BQGsfHLPRwuRAsVurCaDHQHtqyuVcCMK6N2Q91GNIS726hMgmp3x5H4XCRow6vQ1HUNhFbk4AQcZ46PoSBFayv2DkZK3kxqS7aY+iOec6s4cTJeQYiJ173Lf6R13skoYFppP1B5XzJ26lkXaOuv/HBFDXXVxyWqiVAaoa2uZpDCdzGn1yw=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b41d6403-7160-47bc-83fe-08d79a7052b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 10:39:10.9301 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Z8V0cupDnYxo3jyfQ/pVGWxDyzWpwDBxq4jOE+OZZEu0Ukd3X7mMHQh6coN/RIjFSvwjVYeysIjIKhqx6RlQjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4480
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/usz8K6z9QavkizVkPaQE6YDpE0o>
Subject: Re: [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: Thu, 16 Jan 2020 10:39:19 -0000


> -----Original Message-----
> From: Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de>
> Sent: 15 January 2020 21:19
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: Martin Bjorklund <mbj@tail-f.com>om>;
> scott.mansfield=40ericsson.com@dmarc.ietf.org; yang-doctors@ietf.org
> Subject: Re: [yang-doctors] Style question from individuals working on
> IEEE YANG
> 
> On Wed, Jan 15, 2020 at 02:24:28PM +0000, Rob Wilton (rwilton) wrote:
> > Hi Martin, Juergen,
> >
> > For clarification, are you saying that you think that all operational
> lists should have a corresponding size leaf?
> 
> No. That was never my intention. If the size of a list is something that
> is needed frequently, then we should create a generic query mechanism,
> e.g., a get-leaf-count operation that returns the number of leafs in a
> subtree or something like that. (Note that there is also a subtle but
> important difference between leafs that exist and leafs that are
> accessible; it should actually be the number of leafs accessible; not sure
> this is what IEEE used to define).

The access control is an interesting consideration.

Another theoretical option would be a query parameter to add list size annotations.  This could seemingly work well for a CBOR or JSON encoding, but wouldn't necessarily work well for the XML encoding of YANG - in hindsight I wish that the XML encoding of YANG had included a tag to identify the entire list, rather than just tags for each element in the list.


> 
> > Note - I agree that they are unneeded and unhelpful in configuration.
> 
> It could also be helpful in configuration. I just wanted to make sure that
> configuration sizes and operationally used sizes can differ.

For configuration, I didn't want the problem of clients potentially providing conflicting values for the list size vs the number of entries configured.  E.g. configuring that the list has 10 entries, but then only providing 9.  I.e. I think that the number of list entries is implicit by counting the configured entries.


> 
> > Or for operational lists that are likely to be small (e.g. perhaps less
> than a dozen entries) then omitting a size leaf may be appropriate, i.e.
> forcing the client to request and count the list entries if a count is
> required.
> 
> Yes, it is a decision the modeler has to take. And this is why the size
> leaf really gets into conflict with fine grained access control since the
> result of retrieving foo-size and counting all of foo may not be the
> same...
> 
> If such sizes are needed frequently, then having something like a get-
> leaf-count operation is likely much less pain.

My hunch is that that they are potentially useful for:
 - lists that could potentially hold a large number of entries
 - Potentially fast changing data structures (e.g. counts of entries in various routing/forwarding tables, interface counts, etc).
 - resource usage (hardware or software)

I.e. I think that they are probably the exception rather than the rule.

Thanks,
Rob


> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>