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

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 05 March 2021 15:43 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 B4E9B3A26E8 for <rats@ietfa.amsl.com>; Fri, 5 Mar 2021 07:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=hXw9n3Hv; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=VIuiwtGW
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 4b8AmlS-paj2 for <rats@ietfa.amsl.com>; Fri, 5 Mar 2021 07:42:59 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AFF3A26E7 for <rats@ietf.org>; Fri, 5 Mar 2021 07:42:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11959; q=dns/txt; s=iport; t=1614958979; x=1616168579; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZFWs7Yy61uhsuqGezhpwN1a/PswDA5acUGxDubeSxCk=; b=hXw9n3HvKqhua/HfVzfGxiL3foZhAhjA8LyRtbXJ5gi0f0hzwAaH3zLR KfYz/lYOCxIGfZO5sEda0O0paP9z6j/I20b2uWcWxaW5ctfBbGoDdca6R Qa0jldX5TX6ErBfY1BuC5nHdyzbmarcNGP/YlPgYCE24YpjxEtD8IBX3i I=;
X-Files: smime.p7s : 3975
X-IPAS-Result: =?us-ascii?q?A0ACHAChUEJgkJtdJa1fAxwBAQE8AQEEBAEBAgEBBwEBF?= =?us-ascii?q?YFRgTwCAQERUX0sLjYxCod/A4U5iFcDmSOCUwNUBAcBAQEKAwEBBQIWCwoCB?= =?us-ascii?q?AEBgViCdQKBegIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQGGOA2GR?= =?us-ascii?q?AEBAQMBAQE+AQEsBAcBCwICAgEIDgIBBAEBAS4CGQwLHQgCBA4FCAYNglUBg?= =?us-ascii?q?X5XAw4REAEOomYCiiV0gTSDBAEBBoUkGIIMBwMGBYEyAgEBAQGBT4EjikwmH?= =?us-ascii?q?IFJQoERQ4IpLj6CXAEBgWIVCiaDA4IrgVk+LQYBAWIzJBdEPWoCFFwDkFWMH?= =?us-ascii?q?oF2mmUKgn6BG4NQgmyUcYM5kE+PZJZom3uEJgICAgIEBQIOAQEGgWshgVlwF?= =?us-ascii?q?TuCaVAXAg2OKgENCYNNM4RhhUVzOAIGAQkBAQMJfItoLYEGAYEOAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3ADXfqNxJg4u1lc0vIFdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvqU/jlbCWo/Aru9CivTbqbvhRX1G7ZvS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh7zcZHR?= =?us-ascii?q?/kcBdzJ/r4AJXTk9Xx2+3hs5HWah9D0Ty6Z746JR6qrALX488Rh4YHSO4xxx?= =?us-ascii?q?LFr2EOdf5RwDZjJEmYmFD34cLj8Q=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,225,1610409600"; d="p7s'?scan'208";a="679594786"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 15:42:58 +0000
Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 125FgvST007732 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 5 Mar 2021 15:42:58 GMT
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-rcd-007.cisco.com (173.37.102.22) 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 09:42:57 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 09:42:57 -0600
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 5 Mar 2021 10:42:57 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n6QMYQcefi5qj0+i7Y+j3CUoS0sn11IHx7z5z3Oe+C2JI1tteS7YnqU/kJPRMrr/MLjx4rwEdLUw7iA9G6KZGEHGpjDQKnmFll9pG013jfmSKpf8oOuEqnTZF10anY7G+IQcNKEP2e0F4xlMMEczEM9AmJlzTU0LryPxc2QEmBeFmYaLKk9JkETvOB0Zbing0LvmscEQk6uiECEglQehTzUDVRxRNAiwIKQOCTLpFNNaTAqYq6Lu/hDvVbVdINdb3EujR6L6J8kKmlVzffQyqomBBSbXUxIX0NlJQuh6hR09qta1FURFeau2ENr8B27/A8BTAY1gk3P9gJJ5nYAZow==
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=hcX7MeSr05vpB5G+p50JYs7532jAEZbM7msUGcaPgAM=; b=COVbOoOd+MWcHWR1qXGPsQrc08Vg0AXbLl41jIzFVFiN5eBknpKibLGaNMKD8BFY/82IVl/4ZURakNKXMFmJUbyRSmgRP9AZHAc/tJVB24M0oM2BOzTpT0g8bAPnxQVfAoax3T15iowdQQjLuQyWaNPYm4G0WVDrDMQ4D/OIKTthpe1L6EuxOQWG/NWHixp5Jk5SYL4bXgKVcvtnvUqDGdEYrGLFb3WtcEmy/EjJqJXKjiYthcVZRBHsuWrPncATC6fdXdCtUtV5gXBhz+BPCu5pQ1vxwsVOvxoOB8zJH0bTvggWBrl+E02AEFmo9mxHFtl/PzvG/LKcoqZQcg2cuw==
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=hcX7MeSr05vpB5G+p50JYs7532jAEZbM7msUGcaPgAM=; b=VIuiwtGW6kAsnoxY8IYwhuTePy/F3m7vOkZMHG6x/vke9LolDQ0PuPYBrhYqiqkQAWn7jooA+mXCaJci+0ntIXxAM5yie4qncV1rn8wYmUVC5X86C+yGTWTdWE9z0qF5J4xp9lYxqGN0nuzL27QXxTbn0nLQPLg6x60l60UzTBM=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3458.namprd11.prod.outlook.com (2603:10b6:208:6a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.26; Fri, 5 Mar 2021 15:42:56 +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 15:42:56 +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: AQHXBtiPzfKDgDt1JUWIk0bm075RU6pfpH2QgBWueACAAEVAsA==
Date: Fri, 5 Mar 2021 15:42:54 +0000
Message-ID: <BL0PR11MB3122D8926C5143368F4C77C5A1969@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>
In-Reply-To: <20210305111144.ptkqpler3rjmgx6i@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: 930e339b-0595-4b90-52e0-08d8dfed58c0
x-ms-traffictypediagnostic: BL0PR11MB3458:
x-microsoft-antispam-prvs: <BL0PR11MB345824C3CD46577A77061B0BA1969@BL0PR11MB3458.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: Az2yiWNzkA1aE/fziiRKMyP86OCopXCK+DWgpYJ10uwO3zHkDauegyoTtbyJA7kEi0vWWYNgwqlt0FUQfu6TXKfyrTOf4xx6L3U7Cff6G+OEGCrdwzzwHWFZfrWr5RYDR9gVqjszgEo9OwqSp4MgUeC3uIzhkIfADfEzK+JsZXR4+QumRNlJH6nYZIPoapDcSFijSUnai1pRJaLDwhjSCQjd6aKFODoRQo7mD8kWDTStYjFjn/8G80yeWDTPZz8w/XrUGGC++RydN6wQ6yqhyoBYsQd5pYF2CO4ijg0LR7pj/0c6Mo8UazGZdDpclsjm72+4dyQBffUwJ/nIKrG4O+vhvBBbhvVmCcUPgK3bZ7RmP+Y8UVaybnYvRMZyN9bV/roYrugMI0iKW5WT2ca6I78GZsncLzskkbPE84sQ3wfzJWWKzvuSMh+7/xwJv/eggBh02LX9NUhl/V673eJPDkTtVNm6gASkLDvyjbZd9CgzZ2bvFro74RYyGwDh276mdm+6Q3L6wbHrmPIVjL8LFQ+fiQQ7wQDXU8+KxVGCVWwAECDALH9dX+7Yy1MxOTa2kxN9RpYx3xGnD3PKbJ25jfDV7RDZl9vuECb0rFqlXlc=
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)(376002)(396003)(366004)(136003)(7696005)(9686003)(4326008)(66476007)(53546011)(76116006)(66616009)(33656002)(26005)(71200400001)(6916009)(86362001)(186003)(55016002)(66556008)(6506007)(66446008)(2906002)(8936002)(64756008)(478600001)(83380400001)(5660300002)(8676002)(66946007)(316002)(99936003)(52536014)(66574015)(966005)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?mzXnvpF3uEUD0y6iACeiUGYgoKDbzOblVOXiBNMjwwaZKR/5MNyPitJZ9F?= =?iso-8859-1?Q?4CwRHw/BADs5jWeBmomnsKl1FFA5ILnsrXUim3ybJFqxYUtKIImpbaEyMO?= =?iso-8859-1?Q?Zd1nvuv/Dqz505QJ2HpTpx8sp6ceKCkYBQQepGVBNlITzCcMiWJf5gCYyl?= =?iso-8859-1?Q?m1fB2joX88FUYH/o3xiPoThVGicKqx5Pa2xuqGt9fqbRYHuBfvL3p7avT/?= =?iso-8859-1?Q?Vda87aHHeVVVBZPl1CYTv7gS/081PSXGZc/kcm/OSuIqnbd8/BiRoefIH4?= =?iso-8859-1?Q?LqeWBYJdsOnLfH8AuUFqaIE8KBgFL6veuNQ9O8MPgfhrqePc6fUgNM/tz7?= =?iso-8859-1?Q?kATzWOtaSESwq+bIbNF+8d0grd/s5dmuG/jqElmFIYZB8EV4IBIyYxPCiF?= =?iso-8859-1?Q?HsUsNhiYTcAfkeQu/jjWRxwAOmKynwkzQwQ2Dwrye2pNl117KrWxPsJMMO?= =?iso-8859-1?Q?J8rOcyRhMORc14WIYKY+J6z7cK/Vq4I88DjhAz9E8A8dvvTwhN7SIf3SM5?= =?iso-8859-1?Q?7EkJWh1ck70wGizHzXXwId4muPxfAISyF2CaXvApAazAFNobG50Ya6jknj?= =?iso-8859-1?Q?3mPWrEODEO1o43F3cd3ByhffS0aecI35BCk7HV+dxuqeyYPLjY//xKGO2h?= =?iso-8859-1?Q?ZfpTisvycVuBk2zOtOc4zeWZ3SuR/N+bk2U0JqWErIqTzosn3tjcwh/hEZ?= =?iso-8859-1?Q?bPK25KNHIflJCCUSpCiC1L04A7LuU0xLfDjsASEc34qnBE9uJHA5ypscXz?= =?iso-8859-1?Q?kS48bgAZag5dWJz+eyIFaOLBtYE/dy2GlUCVtfYLSERLKE+ZekdK2m3CBH?= =?iso-8859-1?Q?mf892OsfD9iOU0E/ADWq8ubrjh6cXEkYNGcUEcxEHGOJukRR6K010buZP/?= =?iso-8859-1?Q?WpDVucBBGu4rlG1t/y4w68W/frZ++iixiunX79UWq2u+qK58rh5H5FmzMg?= =?iso-8859-1?Q?mMLc34hNrAM2uUaOyZeeDR9Taxd40x4sUQQMppVPg0otNJxBBI6aKZoGDe?= =?iso-8859-1?Q?+9PLLxmmEq4awwhPtjyIEcCJaUa7EoaoU71XVxAUpwu+KsNX/NnPppU948?= =?iso-8859-1?Q?tGAdkkUnUEBBuFOnXCFEFrhBIAhL64CW5a4Fj8XelCuRu1htxHkbTOSb8P?= =?iso-8859-1?Q?axJhqLX5cmz87/HHzkHuVlYRKtQdHKuOKjfkjb8ZKAGbg8oydsCKlsCWmQ?= =?iso-8859-1?Q?mP8Vr0mGtTksUCn0RLg+w1Q+FUInmz98Q5oETShC58yOxJT6ywFLr8/Co9?= =?iso-8859-1?Q?mD0SYSyqgAu34PZpROv4blZNKtPlYMi0qpFwJdCkDdGMoFRYczHrLC10dM?= =?iso-8859-1?Q?soPub8d0t/pgbpOSPHoJz3mnlmE/RtXwW0ng1fffx2CYABjuJIgRVG1pFp?= =?iso-8859-1?Q?7bJaE0Wj9P?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03C1_01D711AC.4B4B4470"
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: 930e339b-0595-4b90-52e0-08d8dfed58c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 15:42:55.7020 (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: OBpTzUFV2j1jj+9jM4+KpavLSE0Mp0V1lKaf43cNwNASVpuFSZuhQ0HJZIpcZg3G
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3458
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Kz4NWHcnv6vVfySg-cpUTEclr2U>
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 15:43:02 -0000

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.

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?

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/>