Re: [netmod] yang-instance-file include-defaults leaf

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 23 August 2021 10:27 UTC

Return-Path: <rwilton@cisco.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 41BEC3A0D2F for <netmod@ietfa.amsl.com>; Mon, 23 Aug 2021 03:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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=FjhZaN7i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NxwBPCP3
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 AyCO_tUb1xSP for <netmod@ietfa.amsl.com>; Mon, 23 Aug 2021 03:27:31 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C85E3A0D29 for <netmod@ietf.org>; Mon, 23 Aug 2021 03:27:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74532; q=dns/txt; s=iport; t=1629714450; x=1630924050; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7uNrDCJ3egLgWizpwTaaKbSl/RMTgYtp2Cs8yGvJPAw=; b=FjhZaN7iHCDgtl4YEHzBsKlXOm1KbqJKmMq1RW6q4xO7egmv2exJGv4B XWe188SFWJUTLGJBrVFF1cjHGc5yP+730HQquiN7j/GUFB0+/CQbb8gkc iHKOF58QiTkLKjLYo2p6Z+SW17z/HvVDIAB/vLyHr8nfaSZN26fm1QuTD s=;
IronPort-PHdr: A9a23:oC1bxR3IXhT0+5/fsmDPS1BlVkEcU/3cMxQU4YE8jLQIeaOmrNzuP03asPNqilKBHYDW8OlNhOeetaf8EXcB7pCMvDFnEtRMWhYJhN9Qk1kmB8iIWkDhLfXxdCs8Ws9FUQwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=
IronPort-HdrOrdr: A9a23:Qhjk5qqDs7FNBiaLH9NjmyUaV5uAL9V00zEX/kB9WHVpm5Oj9vxGzc506farslkssSkb6Ky90dq7MAzhHP9OkMcs1NKZPDUO11HYVL2KgbGSpgEIXheOi9K1tp0QMpSWaueAdmSS5PySiGLTfrpQo6jkzEnrv5al854Hd3AMV0gU1XYBNu/tKDwReOApP+tcKLOsou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23PCiRbF6qKqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAWMR4ZzxStEbTp1OAj3qDzmISFDWqnfdOX4Vmg7fIBmj8CDeSQiTfkNmNyKH7rgpKCcxonBQzO1UweZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjxUC3fLFuIIO5l7Zvt3+90a1waB7S+cQiCq1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm0ExR3g8d3ogSj30A/JUyR91N4PnFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWZ0vKjbIsdr68b817OaldNgBy4Yzgo3IVBdCuWs7ayvVeISzNV1wg2bwqUCGLHvQI+1llupEU4zHNc3W2He4OSMTeuOb0oAiPvE=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AACudyNh/5hdJa1QCh0BAQEBCQESAQUFAYIHBgELAYEiMCMuB3daNzGER4NIA4U5iAQDmj+BLhSBEQNUCwEBAQ0BAUEEAQGEagIXgiICJTYHDgECBAEBARIBAQUBAQECAQYEgREThWgNhkIBAQEBAxIRChMBATgPAgEIEQQBASEBBgMCAgIwFAkIAgQBEggTB4JQgX5XAy8BnFcBgToCih96gTGBAYIHAQEGBASFChiCNAmBOgGCfYJzU0gBAYJtg3onHIFJRIFYgmI+hBcTAho0gmE2ggwihEs+LWoEJzCBehFokTIIg0aIWoNriViSHQqDKp5wEqZ4lhWgGROEdAIEAgQFAg4BAQaBaA0nK4EucBWDJFAZD44gDBaDUIpeczgCBgEKAQEDCY5qAQE
X-IronPort-AV: E=Sophos;i="5.84,344,1620691200"; d="scan'208,217";a="914525961"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Aug 2021 10:27:23 +0000
Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 17NARNoc021287 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 23 Aug 2021 10:27:23 GMT
Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 23 Aug 2021 05:27:23 -0500
Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 23 Aug 2021 05:27:23 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 23 Aug 2021 06:27:23 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QlGX3hTH5MmURk13s3dC+1cs64gIpu8Uc9Z6ZyLsEd/ETIWKpcm/D3uM/bJQ8I1bd6vYuBSqw0+8s3e174NSMzM6DV22I+Z7hwUGWCE+3+xNhYIh7lvtRy+C3w6Sashr5BzBbkm8icMrz9my4Ax1F8qZHOGbs8ZfGc0g9oRAcvZGFaPCVbyDq4CsvA8G3oE9qGIdST58Fvv72Ov1gKanqMV7hISqwJgQ1TyP89sscmqg7gAehRZgVN1DLjD02NLlLniU/VlESTRkDcv/9sdPhWGok79tq9prviF3vydK2HIBOaxXEkM0GAAkhy5NXhu9iBc32kap9o1HgQg4AnWx9Q==
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=7uNrDCJ3egLgWizpwTaaKbSl/RMTgYtp2Cs8yGvJPAw=; b=GUBpDOZgxCmS+v9I46DvXCQQ+gHJsxp+jEjCi4kDJQD0j5o9YM4g6DmRup1xUxSZJD2C38BTSJ/EqBPdhb9irt+97idqkePqTF/ZSn2IPKfmkBaoxVgagT/WCYLcZRzdjWsnH0UxvIBXrmwr/5TlWNHX/0b8i8HU5eEcAkOAiuvpAz792riRA3OtQrb2uUYpj6hUsFpi0TFGXNc3ITmbKSE/iU1zW8Rh2DV/Siy5qKGVEWxsbGuGSExSKp2Ec1frUqTY2t7KlMofme8rkrxi5SZ6rvFMlzNKccB0j3qfH5+NwiLKwKnYhw+xI2tKZwrLFZ8wZlPRZDII7nSyJpixFg==
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=7uNrDCJ3egLgWizpwTaaKbSl/RMTgYtp2Cs8yGvJPAw=; b=NxwBPCP3gK92uNOVCTMppUiH4GHfHHhYxKFzXZsi6t8MtYSmEjr8B41RYf9/A0+tQZI9Ttot+Catj3KCbVtDytLgTFhvJHWZ3la0uJ8cET9ncKfBLVcMZ5+YxUI854hJx0CxqZLmNK3OEoq4YaqrKjDLErXtj/shcmmRnXU6SiI=
Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB3628.namprd11.prod.outlook.com (2603:10b6:5:144::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Mon, 23 Aug 2021 10:27:21 +0000
Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::5839:4fe5:abd7:35ad]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::5839:4fe5:abd7:35ad%9]) with mapi id 15.20.4436.024; Mon, 23 Aug 2021 10:27:21 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Balázs Lengyel <balazs.lengyel@ericsson.com>, Andy Bierman <andy@yumaworks.com>, NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] yang-instance-file include-defaults leaf
Thread-Index: AQHXdB0ZnZibUXpuT0+6mfsyEmKi+6s6kMRwgAHbvACAGptLcIACCfoAgCgIS2A=
Date: Mon, 23 Aug 2021 10:27:20 +0000
Message-ID: <DM4PR11MB543824EB074422075681CA9AB5C49@DM4PR11MB5438.namprd11.prod.outlook.com>
References: <CABCOCHQB8=kAXRejif=04ThzbSn87oqvDLB5=oJ2FVcAKrSg4Q@mail.gmail.com> <DM4PR11MB5438F5874CDEB4D78C9A5695B5189@DM4PR11MB5438.namprd11.prod.outlook.com> <CABCOCHRwzRajMmSd2mArLeLr8OOxTdLEid3bEDdVH0vgNysTfg@mail.gmail.com> <DM4PR11MB5438FBF7837C1147D786964CB5E99@DM4PR11MB5438.namprd11.prod.outlook.com> <AM8PR07MB8230BEFDC5A967AB6293C794F0EA9@AM8PR07MB8230.eurprd07.prod.outlook.com>
In-Reply-To: <AM8PR07MB8230BEFDC5A967AB6293C794F0EA9@AM8PR07MB8230.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ea2fe82-a189-49d7-ad48-08d966209726
x-ms-traffictypediagnostic: DM6PR11MB3628:
x-microsoft-antispam-prvs: <DM6PR11MB3628351F23E4BFB565AF88E8B5C49@DM6PR11MB3628.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XG6tmqDAQB7C1owOhTnIOYfdpmq2XLpQGpDTw5BQMijrJirrOL27sdb4ZT1JkG4yrcZZxJfql4Y5B25sOZZ0L68cdTJJufPpis+k9UIsyQpm27iOiz9vf2r0KfhznebcH+gHIhQWMA19wS4REdRhJHJjF+7Sgddw5Z6OsRvL1/9ZrwunQAd3lptZgi/DW7XiRAIbKRG9j57SGn7gNf6mYoP6cA1/6Q8T3LpNdVVI4H+MMootXwHl/NE9OdyWSp3EhYO1yKDLFxCZzlXilHRIFLymJ49usWjomUJHRa/6cjmP7DOK5/gMN6UP3RhZxy3cmUHi7pws6K6DJbUq6ASO49n5nP20lE04SOuduTG1NM8wMd5pDFkM1IvSXWtLJIxoZk6NQMyNsZOqI1GeatpzmZD7kU/dDAm+olVIFLwf9PY20s/dT+fTvt9JA/7lDq2broQUZJxT8ylqbV8Gog6ruXnGGC49gvCwYFKq36PpVWTgTLu3oWsBZbik6UrapRPg7j5YhXJPKMr9j+4KPNHcHLN9m8LLwABn24jJRwDzuzv8Sp2Q8ozbeGVhrounl1sOnh0LbWCGycda3OSM8YyPUP4UyG+Juu66TUzySkZGgA3g9XBgYyv+ns/2WVmRQ5Ta4rZ5alkvz4+jpqF7YWaGWxQ6nrAJkG2feFYMGBTrYQnPVJTBe4sEVn5EiDiJZoDkrsHOEFAIPi8mz29LyDt/XA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(64756008)(76116006)(186003)(2906002)(66946007)(86362001)(83380400001)(66476007)(66556008)(6506007)(53546011)(9686003)(66446008)(7696005)(26005)(8936002)(508600001)(8676002)(52536014)(71200400001)(122000001)(316002)(5660300002)(110136005)(38100700002)(38070700005)(33656002)(55016002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: A6OgzuHltH1DRcA1JWrbi/9TFLARD4hM2J3b9SsT3rMJrgbm1LrV6Ut0dBcbShUICxaFgJNc2QAsAlNjNCcPNt8whswt+XOXOj6sSysEykpg+8k01VgcRHWcpP7jstgqAE1rRtePQo2cLRqvdSCahZ+AyihLYrEHGj5vi2TIVa6Z8aLYMR083WtEB1JZOKckbDHfOsvEwRbI1mQfthO4o5poOhW8jSS0bopph4R5S16hmRoWJkvluOwYCl4ZyaRUyNwgGeu9KDMFhtXcRJZ1BFU0qIKV+JGHb+4J7tOqd5FSccxde2FGluBg9JAGyDE6cuIAi0sTgnXNo4LlfoGiZQp97XEhIV5rkfR98IZB5yt9az10S0cFV2jDYDWivoJnC0xr3x03CWapMAOcE8hAu+qgj88FrYc49TZ2WDnK8ZoCh/HzevryxA2/suXrVc3QRiyCZMrEDaXaG8V1M9KLxlrAsZxDSZepRwP5TpFltqnyO0Ni/hjWHmq9cwFKoSPkPQVu7V+GQobvjcRxLZzojV4z1NCHKbz1B5BfWv8BxVREggUCB2WCqZsh/3kjXRAcBptTF6oGgAvFShw96B//6Pto7F3RnvBCM2bkD1lvxiWx/GOm2xzSYDAzt+xmZCO5JH6xFbrczq8ZtidTEY4lLVN2B6HH8yfUfTZuVGBxVQ+v5fuBgLKSmGLP2AQa7WXiUK230RlxuC5cIVZeeNDIy6s1MXP5z2ZYLND7NW3u7bSFS0Irzpb1f362nnqY4eQ3AVG+3LzhaZXEXzCCeZzI2EdBCJfffLlaQI0z3jEdTqzVNGYpuaj6k0gOqTKfsAMxnNDdPxANbnlv86RISlCwdJWSQdIZ/OKVOeKoyKW54n1ASsUPINn8nrOucC9wPTJsRW1llvFfhc3ghhHX1OCaGkC+uQg8M+kUiBf4msVdKM4IojTx+Ugyonn6TX1sSMGa56lXfoen0JL16PBzyp2HmP8ALWfAmP27kGIatz49enl7DQR/Ke7jzB1El+b6IKFO66FKTDqxEJbMf4x+itRZ6YaMN0IMFF5mKk/Fm74DERFZJ0ei5rtCCeJyVp1KEQV4VroXxWlNLVyEA3qjPGwIeyeHU2qDR1tF9frr/Y4o1lKYVXg6Mn9efq04SVpILEdQf2ZkHEM1jC0djBen5kt5s8SnRKmgsqy0bucdAyNrDH4ykXMY6ZVdfWHRENzS3Jj71THcQ15Sc+iPZrM4bOINC0LjgeTHwXrzJrWwx5ielwKjrA50UqrTE81BeLRBYM1t6wWXcq81wyPlfT9C65wtbTkobtaxZPoes+N5u5qK9Bg30hGgFvhFo6/1R4kq+OYt
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM4PR11MB543824EB074422075681CA9AB5C49DM4PR11MB5438namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ea2fe82-a189-49d7-ad48-08d966209726
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2021 10:27:20.9312 (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: QMaZg3v83FFbh1v/a+X5eMSVYPqqGJT9uNk1T8obPi8m2EAE2nIMECVnfEE7r+9PlNg1BnvwGfYnprEN5WBPwQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3628
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/c86aIsR0ojLYQ6OiblTrfNc2LHM>
Subject: Re: [netmod] yang-instance-file include-defaults leaf
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, 23 Aug 2021 10:27:37 -0000

Hi Balazs, Andy, Netmod,

Sorry for the delayed response.  I would still like to strength the description of the defaults.  E.g., RFC 6243 uses MUSTs rather than SHOULDs.

Hence, I have generated some proposed alternative descriptions, that are somewhat stricter, but also more generically focussed only on the default values.

With these definitions, I think that we could define the “include-defaults” default value to be “explicit”, since if the leaf if not included, then I think that this effectively what the meaning would be anyway.


In particular, I would propose changing the descriptions as follows:

       leaf includes-defaults {
         type enumeration {
           enum report-all {
             value 1;
             description
               "All data nodes SHOULD be included independent of
                 any default values.";
           }
           enum trim {
             value 2;
             description
               "Data nodes that have a default defined and where
                 the actual value is the default value SHOULD
                 NOT be included.";
           }
           enum explicit {
             value 3;
             description
               "Data nodes that have a default defined and where
                 the actual value is the default value SHOULD NOT be
                 included. However, if the actual value was set by
                 a NETCONF client or other management application
                 by the way of an explicit management operation the
                 data node SHOULD be included.";
           }
         }

Proposed:

       leaf includes-defaults {
         type enumeration {
           enum report-all {
             value 1;
             description
               "The instance data set includes all data nodes,
                including those that contain the schema default.”;
           }
           enum trim {
             value 2;
             description
               "The instance data set excludes all data nodes
                that contain the schema default.";
           }
           enum explicit {
             value 3;
             description
               "The instance data set may include some data nodes
                that match the schema default and may exclude some
                data nodes that match the schema default.”;
           }
         }
         description
           "This leaf provides an indication of how default data
            is presented within an instance data set, modelled on
            RFC 6243.

            Interpretation of the use of defaults depends on the
            context of what the instance data set represents.

            E.g., if the instance data set represents configuration,
            Then include-defaults aligns to the meaning of the
            default-handling basic modes in RFC 6243.  If the
            instance data set represents operational data from the
            operational state datastore [RFC 8342], then
            include-defaults aligns to the definition of that
            datastore in RFC 8342.”;

Would text along these lines work?

Thanks,
Rob


From: Balázs Lengyel <balazs.lengyel@ericsson.com>
Sent: 28 July 2021 23:08
To: Rob Wilton (rwilton) <rwilton@cisco.com>; Andy Bierman <andy@yumaworks.com>
Cc: NetMod WG <netmod@ietf.org>
Subject: RE: [netmod] yang-instance-file include-defaults leaf

Hello Rob,
Removing the “default trim;” will address Andy’s comment.

Your in-use-values is very specific to one of the use-cases: reading/documenting operational values. It is not useful for the other use-cases. I think the “documenting operational datastore” use-case could be handled by indicating the includes-defaults=report-all. Case (i) would contain the value case (ii) will not.
Regards Balazs

From: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Sent: 2021. július 27., kedd 17:38
To: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>; Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>>
Cc: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: RE: [netmod] yang-instance-file include-defaults leaf

Hi Andy, Balazs,

So, the reason that I want a flag to indicate whether default values are in use is because of this definition of operational in RFC 8342:

   Requests to retrieve nodes from <operational> always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

It was written this way because otherwise a consumer of operational data cannot differentiate between:

(i)                  This value is not present because it matches the default value specified in the YANG module, and

(ii)                This value is not present because the server has failed to return it for some reason (e.g., perhaps the daemon that would have provided this value is down or not available, or perhaps it is a bug, or perhaps it is not implemented and is a missing deviation).

So, I think that in some cases, the absence of a data node does not necessarily mean that the default value is in effect, and I wanted the instance-data document to be able to contain and correctly report this data.

I think that this behaviour could be captured by a single leaf.  Another way of articulating this would be:

leaf in-use-values {
  type boolean;
  default false;
  description
    “Only if set to true, the absence of a value in the
     instance data for a given data node implies that the
    node is not used rather than implicitly taking the
     default value specified by any corresponding
    ‘default’ statement specified in the YANG schema.”;
}

With this, I’m not sure whether we need the “includes-default” leaf currently specified in the draft, but if we do, then I would think that leaf should be entirely optional, i.e., without the default “trim”.

Regards,
Rob


From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>; Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>>
Subject: Re: [netmod] yang-instance-file include-defaults leaf



On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>> wrote:
Andy,

Yes, when I suggested this, I was thinking that a boolean flag might be sufficient.  My point being that automatically filtering out default values isn’t always the right thing to do.



The solution is simple.
Get rid of the inappropriate "default trim" statement.

If the leaf is present then it identifies the basic-mode that was used to include defaults.
If not then the information is either not known, not applicable, or defaults were not added.

The "default" statement is a bug because there is no default basic-mode.
All of the basic-modes are in use in deployments and no camp has ever
been able to convince the others that theirs is right.


Andy

E.g., something along these lines:

leaf exclude-defaults {
  type boolean;
  default true;
  description
    “Can be used to reduce the size of the content data file.

      When unset or set to true, data nodes that have a default defined and
      where the actual value is the default value are excluded from the content
      data.

      When set to false, data nodes with default value are not filtered, and
      may appear in the content data.”
}

Would this satisfy your concern?

Regards,
Rob


From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: [netmod] yang-instance-file include-defaults leaf

Hi,

The module has this object:


    leaf includes-defaults {

       type enumeration {

         enum report-all {

           value 1;

           description

             "All data nodes SHOULD be included independent of

               any default values.";

         }

         enum trim {

           value 2;

           description

             "Data nodes that have a default defined and where

               the actual value is the default value SHOULD

               NOT be included.";

         }

         enum explicit {

           value 3;

           description

             "Data nodes that have a default defined and where

               the actual value is the default value SHOULD NOT be

               included. However, if the actual value was set by

               a NETCONF client or other management application

               by the way of an explicit management operation the

               data node SHOULD be included.";

         }

       }

       default trim;


The draft is extremely server-centric, like most IETF standards, but this
leaf is too server-centric to ignore.

Consider the possibility that the source of the file is NOT a NETCONF server.
This data may not be known so the default of "trim" may not be correct.

IMO this leaf is noise because any tool that knows the schema will also
know the YANG defaults.  The solution is incomplete anyway because
the presence of a leaf that has a YANG default is not enough.
The  "report-all-tagged" mode must be used to identify defaults.
IMO this leaf should be removed, but at least add an enum called "unknown".


Andy