Re: [Rats] do not address yang warnings by making nodes writable

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 05 March 2021 16:23 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659673A27A1 for <rats@ietfa.amsl.com>; Fri, 5 Mar 2021 08:23:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.621
X-Spam-Level:
X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lofpFJx1; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=BacKlSU4
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 UUai7jyUdjrM for <rats@ietfa.amsl.com>; Fri, 5 Mar 2021 08:23:31 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8433A279E for <rats@ietf.org>; Fri, 5 Mar 2021 08:23:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13834; q=dns/txt; s=iport; t=1614961410; x=1616171010; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RK0tk134sridssSSdNIj5OukjeRQ9aC2yKSEeXEDfyM=; b=lofpFJx1YziUDvjpXH+a9YvtFb9blU1y9TeN1RbA7jjtA/I0PemNHi6z FVA0bRKBvmS1RqY33Cct45Yn/jT0+xW0kgFJ3oRlTRiq2w640WTn27S4z 8IJp38euLWRS4qNyRjnSAdZphoz+bG/I6Zrg8M2v1qmK2DXskDLXBOjLx c=;
X-Files: smime.p7s : 3975
X-IPAS-Result: =?us-ascii?q?A0D5EACJWUJg/4wNJK1fA4EJgyIjLgd2LC42MQqHfwOFO?= =?us-ascii?q?YhXA5kjglMDVAQHAQEBCgMBAR0LCgIEAQGBWIJ1AoF6AiU4EwIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEcYVhDYZEAQEBAwEBAT4BASwEBwEEBwICAgEIDgIBBAEBA?= =?us-ascii?q?S4CGQwLHQgCBA4FCAYNglaBflcDDhEQAQ6iYgKKJXSBNIMEAQEGhSQYggwHA?= =?us-ascii?q?wYFgTSBU4EjikwmHIFJQoERQ4IpLj6CXAEBgWIVCiaDA4IrgVk+LQYBAWIRI?= =?us-ascii?q?iQXRCAdQSkCFDMpA5BVjB6BdpplCoJ+gRuDUIJslHGDOZBPj2SWaJt7hCYCB?= =?us-ascii?q?AIEBQIOAQEGgWsjgVdwFTuCaVAXAg2OKgEWg00zhGGFRXM4AgYBCQEBAwl8i?= =?us-ascii?q?2gtgQYBgQ4BAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3AVoJnYBWGQBgJpa3p+AfcjLp78M/V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN6LufBNgO3cqOX9X20e7IyasWwTNpBBBF?= =?us-ascii?q?cJisQTygonBsPNSUj2N+XjYCFyGsNeHERk8He2PQkweo7+alTer2f04WsUHR?= =?us-ascii?q?PyZgh8LeP/AcvPicWp2vqp+oHCJQlF13KxZLpoJ0CwqgPc/sAdnYplLPM3zR?= =?us-ascii?q?3ExxkAe+lfyW5yY1yJmBOp7car95kl+CNV6P8=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,225,1610409600"; d="p7s'?scan'208";a="656616354"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 16:23:29 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 125GNT5x020575 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 5 Mar 2021 16:23:29 GMT
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 10:23:29 -0600
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 10:23:28 -0600
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 5 Mar 2021 10:23:28 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HlTDqmgwwIqx3ICp2dySizqJ3zLYSOVnSVU4GOfJDn47WYpFgAlaMaO3yqNj6/bW8UMv4ioDgTlDeWJ0fWBM7NnSfcqFh/6UQYjpEgAjdzjvbfj8VUDCTO1/jPOmcFkXtUmQ/UiorNLER+8Xyxqucbu76Q4+JbpjwYEeEVs12AAFyYKJcTPrxsZzPnT0mLkpYTSPGk4llfFc/6NhsAKmPcj/R79qxaYq1REwQThlPWOhZuoPmNLLrfCjy+A3rsElK1X/aV3+5zK+dq+ytyVZEvqppCOktuykzGhX6kH5/0oU1EsFy2wZsULl7saJM4x7MqWuY0B9Pbr1ZWshWuvRuQ==
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=WvK+mbGwKCa5MIuhw5MkG95F78/yGL/zcs7rcF425os=; b=gVl1GtRGraQQWuimMgTac4Nx/RPPQV6TUEipCIkXdZWZ3wZP1putTpOjXrnIUcXUPiiLS3vIXzk5TXwJyUuFtKKMEl+8MFGIvAS2xnFLjmrPlIsdMBbAeOLdi7DRKrXKWzhXGwlsAO0O0gBq+m4xdb7+JVv/7agOw7xhJwWi4nRoJwzC52KuCmKac9RabEXcaRrNtwvDslZIosLEo/3fdmr5HxxPwKz7NjWp4sOvt3SjY0LrINI7SIqvDtH8O7AsWYf3iEICqEm/0vwIiba9D4Rv4CqjLS+mD0623zwjc7Pf3okUEdNmlpmB9wtm1zJWgtgU1lbbGnOe4bVA3YpHVQ==
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=WvK+mbGwKCa5MIuhw5MkG95F78/yGL/zcs7rcF425os=; b=BacKlSU4BHa3o2uLChABlT4mH9G615aYEvjG9cS2WcPi71MUFqz5u58UidWHyHuh8K87pk2gwLpQb6UHHdpflYtLWk7noEOwy4rsYFYY2UwswCv6eEFz2BXeuUp/B4BfcORD7MtHH5GL2P25nrBKBgraFh9XwSRy7TCDYWdq/nw=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4552.namprd11.prod.outlook.com (2603:10b6:208:263::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.23; Fri, 5 Mar 2021 16:23:27 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf%3]) with mapi id 15.20.3890.032; Fri, 5 Mar 2021 16:23:27 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] do not address yang warnings by making nodes writable
Thread-Index: AQHXBtiPzfKDgDt1JUWIk0bm075RU6pfpH2QgBWueACAAEVAsIAACUSAgAADmXA=
Date: Fri, 5 Mar 2021 16:23:27 +0000
Message-ID: <BL0PR11MB31227B686A7EE19225F91EB7A1969@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <20210219131122.4b3qt7kgapmgv3ax@anna.jacobs.jacobs-university.de> <17694.1613745400@localhost> <20210219160103.26mds5wtenqtfbct@anna.jacobs.jacobs-university.de> <BL0PR11MB312290AB0F53053548E1D43DA1849@BL0PR11MB3122.namprd11.prod.outlook.com> <20210305111144.ptkqpler3rjmgx6i@anna.jacobs.jacobs-university.de> <BL0PR11MB3122D8926C5143368F4C77C5A1969@BL0PR11MB3122.namprd11.prod.outlook.com> <20210305155245.p23ab4isvpn2vxdo@anna.jacobs.jacobs-university.de>
In-Reply-To: <20210305155245.p23ab4isvpn2vxdo@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [108.18.141.61]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 81554b69-8df8-4273-6ab2-08d8dff301de
x-ms-traffictypediagnostic: MN2PR11MB4552:
x-microsoft-antispam-prvs: <MN2PR11MB4552B77094BC4F61158C53E4A1969@MN2PR11MB4552.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UKKlQP2ApijYMF/6XguoRAtSuG8Fg79fvrIGQ8+stgTcba2rq9DikqkHefKPtlIUD6kWPPWsw2eViMFN5D3BIhvWgOe/ol9f1bmgWpvdaEKNrnNW+On3+hZDSTP3YqwaajGa8WyQTufbqgZCHWesVrwZ2+OAUr1rWTq9RCEgYpBbyf8KnfevXeyLdg4Mfz7QasShbsHOOt7KCOBS+hMer1K9M9gPvnP/8dToJJcizzNNCHvsEg+nm7G319vnHeHMEI5rdXAAqRHyQg8KqeJqBilKtjBmOhlUr60YGOZKHq0g+MyBkHhrqD/+mIf9T1EUXPE16V/0SpC0MGO2tojTqfB87uBZ4JzhAwfsZZIt1VMb1YOfwIvTxCPcezUmuSyHTIuESjFXRLM8CubiH4/WqgDCIrrQNMnte64fdiGCUTF+HFEaGp/bxlQyJmcKjyE67L+ElmprvndhkwR6ATk+AQYwznWRhVSgsiIj8YVlyL2ClLkI3G3DHZ+a1Hz0/n8TIiI6p6eSxTK/m05T6ToQn0YSbcOR4DoKY2tPwWLY9fYQqjCE1XW7HhpLihEIoW5h8P6Vx77MewhVKQtlrTRE35djv78QgSb4M90yF1kILwc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(366004)(376002)(396003)(136003)(83380400001)(86362001)(71200400001)(6506007)(52536014)(8676002)(4326008)(6916009)(53546011)(7696005)(66574015)(99936003)(316002)(66476007)(26005)(2906002)(9686003)(54906003)(186003)(66946007)(66616009)(8936002)(66446008)(64756008)(66556008)(55016002)(5660300002)(478600001)(76116006)(966005)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?DR4YRokaF888GBO3wrgmcpY16HbgstJAn96HpdmtrjHiN28Y+e4qLOgnoH?= =?iso-8859-1?Q?rX+bucV07rr2UABUxzF4pAOQviNq+pem3XBtYcnOCRX4lYMIzj7OlVAJSw?= =?iso-8859-1?Q?rMxZcHgNGamj/jI4RhAW9B15ThyAFXu2ykqNJm8Z6OMxLTjl72mBhz5Gjx?= =?iso-8859-1?Q?635ysSMwHj9A5asxvhEW3SAhRjwyoCq4UDCHblmuU6MV3BF+Am4hrkd+Bo?= =?iso-8859-1?Q?595NC6W57r7lmwlg6yjrXvuVKwclQ2k84ImNqsYxpNMutYIsfx4zzgktfq?= =?iso-8859-1?Q?HYFjTNePd52ScCcLWQbn/GwJrAAYGOsp9S4uyFYcTtL9BJbIn81PUPCXNH?= =?iso-8859-1?Q?4ET8W4Q5jvzxiBJkoKvERyzWTGgrs+2L3QSfCJN/hsdkjOyi/2DWgfwqrB?= =?iso-8859-1?Q?hjy6GojUWxo6bg6e4M9DUafOep0sgsRGHtqaKTRqV65U+hDuMGA8MZiOXI?= =?iso-8859-1?Q?DhKsirxTkGl7GOSEZsWM1+MAr3mjHZjkIVQn0+QaKGu/NsXpR+Z+cpSN+1?= =?iso-8859-1?Q?iy1S/Th5mYGdhfHBQd87rbnX4lawYB4Ru2XouyW5hT2HDrzInDf6COHKdS?= =?iso-8859-1?Q?cxIOd0phs1Sk2B3hbGA5ZkB1mgnpqd9pgFDSbDptHwGqMazEwMHRa8cZl5?= =?iso-8859-1?Q?ybyyKLqijdHd1hcM+hPTP1mY2V6gymfu+wgTumMSaIpp9SDxtMEfQAJ/kD?= =?iso-8859-1?Q?E6O/5RNRIaXGsP8PrRtqhNY0slrJLeJhCWEvIPXRqe6JewzM50GFbd8rK8?= =?iso-8859-1?Q?HlJRiario9a4F3+bHo1+W8UyDKkPKQt4OlYzHLWHxdxPxldmqzClAivIsj?= =?iso-8859-1?Q?LoTXlKLdj9CKXG+jSONUu1aXTI4Sfs11+rZ0rxASF3ADL3FJJkATLWaEfk?= =?iso-8859-1?Q?5/Ve0t7aK6pTQyOI6o13leCu+4kDv7gO5ZTxRCkvq1JRiG8y6PiyfLMzNA?= =?iso-8859-1?Q?R5+dj+23+C1CbSnfZqPPmIp8FuVh9xWLi5f8z6MqtEUHEF2IoXPAFV6fNU?= =?iso-8859-1?Q?b+EZ2owJyLtsmumFj5hOrj3FEODVMZ/kUz/7cyv6p4bi721BQvMKiw7JtC?= =?iso-8859-1?Q?YDyHfFU+YIa5CsDhnN6LGdEfCt+Y2sSzcclHjpTPDNsK7Z2ZX3WizyJ1uO?= =?iso-8859-1?Q?HHx92SFnRVbeC0IugWC01Mq1BbXdQRjKafcC7+XzRGFb+Tbh8zbUyKObWb?= =?iso-8859-1?Q?nUPJexVGcry7xle/nbwWVzKTnViDqS9uvVdRczPLFERestJRcmhX0NKuyT?= =?iso-8859-1?Q?O6Q0BFU2OhhktbZ/pLO/olM8KCq9hH1BKO8h3AeCkf6oSSH/nKgYB2pNb7?= =?iso-8859-1?Q?nB0WG1qNQKrCT0OO2zlroEW2W72+JDf/yS2i37Y65oE7uauiZ5Y/gOae42?= =?iso-8859-1?Q?B0iGeI+EUL?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03F1_01D711B1.F51E0D70"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 81554b69-8df8-4273-6ab2-08d8dff301de
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 16:23:27.3036 (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: rFXxYnt7YKMJ4m7bsg3UEBaLdrhe5BoXAuhLjHgSadSHUJFxG4l6v3MJsRmnfNK4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4552
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/JgNtYx0LPWlL8E0yEXkK9ZW_0CU>
Subject: Re: [Rats] do not address yang warnings by making nodes writable
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2021 16:23:33 -0000

Hi Juergen,

> On Fri, Mar 05, 2021 at 03:42:54PM +0000, Eric Voit (evoit) wrote:
> > Hi Juergen,
> >
> > Where you say "this config applies to TPMs version X", we are
> > accomplishing a similar function via when statements,  E.g.:
> >
> >         uses TPM12-hash-algo {
> >           when "tpm-firmware-version = 'taa:tpm12'";
> >
> > It is possible to place what is currently within these 'when'
> > statement to instead be within the descriptions.  But using 'when'
> > statements seemed a more robust approach.
> 
> Except you had a broken config true node.
> 
> > Based on our discussion, I can adjust that description of "leaf
> > tpm-firmware-version" to:     "Identifies the cryptoprocessor API set
> > supported.  This is automatically configured by the device and should
not be
> > changed."   This will eliminate the earlier text about a YANG warning
and
> > NMDA.  Is this a reasonable approach?
> 
> Overwriting YANG semantics is not what you want. Perhaps you actually want
to
> use a YANG feature to make parts of the model conditional to a feature
> indicating different TPM versions. Of, you already have an if-feature. It
might
> well be that I do not understand what you are trying to achieve.

Unfortunately using an if-feature does not provide sufficient granularity.
A device can concurrently support multiple TPMs, each potentially having
either TPM1.2 or TPM2 firmware.  The model is trying to ensure that a
specific instance of a TPM can only be configured to use a valid subset of
the allowable algorithms permitted by the type of firmware available.   

Eric

> /js
> 
> > Thanks,
> > Eric
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > > Sent: Friday, March 5, 2021 6:12 AM
> > > To: Eric Voit (evoit) <evoit@cisco.com>
> > > Cc: Michael Richardson <mcr+ietf@sandelman.ca>ca>; rats@ietf.org
> > > Subject: Re: [Rats] do not address yang warnings by making nodes
> > > writable
> > >
> > > Eric,
> > >
> > > I think you want to configure that "this config applies to TPMs
> > > version
> > X", i.e.,
> > > you configure the version that needs to match the TPMs version so
> > > that
> > your
> > > config can apply, you are of course not configuring the TPM's
> > > version
> > (that
> > > would require a TPM configuration model but as you write, for many
> > > TPMs
> > this
> > > will be by design not configurable).
> > >
> > > For network interfaces, we do the same: You write down the
> > > configuration
> > of a
> > > network interface and we expect that the configuration only gets
> > > applied
> > if a
> > > matching network interface is actually present. (This is basically
> > > where
> > the
> > > difference between intended configuration and applied configuration
> > > comes into play.)
> > >
> > > /js
> > >
> > > On Fri, Feb 19, 2021 at 04:35:32PM +0000, Eric Voit (evoit) wrote:
> > > > Hi Juergen,
> > > >
> > > > > From: Juergen Schoenwaelder, February 19, 2021 11:01 AM
> > > > >
> > > > > I do not know what the purpose of the MUST statements is since I
> > > > > did not
> > > > dig
> > > > > deeper but it could be that config is only applied to TPMs where
> > > > > the
> > > > configured
> > > > > version matches the version of the TPM. This would then require
> > > > > to
> > > > configure
> > > > > the version, much like we allow to provision interface configs
> > > > > even if
> > > > there is
> > > > > (currently) no matching interfaces.
> > > > >
> > > > > It could also be that the WG does not want to allow something to
> > > > > be
> > > > configured
> > > > > for a TPM version that does (currently) not exist. Even in that
> > > > > case, you
> > > > would
> > > > > have to convey the TPM version as part of the config and then
> > > > > have logic defined in description statements that such config
> > > > > snippets are to be
> > > > rejected
> > > > > (instead of being not applied).
> > > >
> > > > This is closer to the purpose.
> > > >
> > > > The TPM is a hardware device* which will follow an API defined in
> > another
> > > > standards body.   The TPM has firmware which will not be configured
> > through
> > > > YANG model.  It is conceivable that new TPM firmware versions will
be
> > > > exposed, so ENUMs cannot be used.   It is this firmware version
which
> > will
> > > > allow other relevant configuration operations to be applied.
> > > >
> > > > So you cannot change the configuration datastore for this object
> > > > (as it
> > is
> > > > read internally).   But you also can't make the object as "config
> > false", as
> > > > other configurable items depend on it.  If there is a proper way
> > > > to document such a relationship, it would be great to update the
> > > > model so
> > that
> > > the
> > > > relationship does not require the text currently in the description.
> > Any
> > > > suggestions?
> > > >
> > > > * There are also such things as Virtual TPMs.  This model is
> > > > intending to frame YANG structures which can be reused should
> > > > others want to build
> > for
> > > > these as well.   But that is out-of-scope here.
> > > >
> > > > Thanks,
> > > > Eric
> > > >
> > > > > My point is that saying a leaf is rw config, it is expected to
> > > > > be used for validation, but it is not expected to be there is
> > > > > not
> > working.
> > > > >
> > > > > Personally, I prefer config that can be provisioned but may not
> > > > > be applied
> > > > if it
> > > > > does not match the resources (currently) available.
> > > > > Yes, this requires to check for possible differences between
> > > > > applied and provisioned (aka running) config but the opposite
> > > > > gets you into situation
> > > > where a
> > > > > hardware component failures leads to an invalid config and you
> > > > > are either bricked or in a mode hard to understand.
> > > > >
> > > > > /js
> > > > >
> > > > > On Fri, Feb 19, 2021 at 09:36:40AM -0500, Michael Richardson
wrote:
> > > > > >
> > > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> wrote:
> > > > > >     > I doubt that this is a proper solution as you now have
> > > > > > to
> > > > configure the
> > > > > >     > tpm-firmware-version. If you cannot configure this (as
> > > > > > the
> > > > description
> > > > > >     > says), then the MUST may always be false, i.e, once you
> > > > > > implement
> > > > this,
> > > > > >     > you will see that this does not work.
> > > > > >
> > > > > > I am not clueful about XPATH forcing "rw"... is there another
> > solution?
> > > > > >
> > > > > > --
> > > > > > Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> > consulting
> > > > )
> > > > > >            Sandelman Software Works Inc, Ottawa and Worldwide
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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/>
> > > > >
> > > > > _______________________________________________
> > > > > RATS mailing list
> > > > > RATS@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/rats
> > >
> > >
> > >
> > > --
> > > 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/>
> 
> 
> 
> --
> 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/>