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

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 08 March 2021 13:35 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 218D03A2A2F for <rats@ietfa.amsl.com>; Mon, 8 Mar 2021 05:35:18 -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, 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=NIdBKZ0I; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=GA2V7HDD
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 2kP-EZALjrri for <rats@ietfa.amsl.com>; Mon, 8 Mar 2021 05:35:15 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A713A2A2A for <rats@ietf.org>; Mon, 8 Mar 2021 05:35:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13686; q=dns/txt; s=iport; t=1615210515; x=1616420115; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0JwW1dRpbb5St6lQt+NjLxc04FbbmsTD8gBTxD47rm8=; b=NIdBKZ0IQHlGAoSK4vjOpPn08nKAQt9moAx7a4++pF7czSGmB1pp81w3 Rkyg0uWFGPPSIEvZX8C93EXC6b/nZs/zvLZRb3Dq8g3p4kcrUMfeLPBby QRk0Lm3/w+Vs9tHroBdv7vIxKQ2uE3meNndeUuwKlnwFkzOwmNMiI0AVy 4=;
X-Files: smime.p7s : 3975
X-IPAS-Result: =?us-ascii?q?A0B2BADaJUZgkJtdJa1fA4EJgU+BU1F9LC42MQqHfwOFO?= =?us-ascii?q?YhYA5kjglMDVAQHAQEBCgMBAR0LCgIEAQGETQKBegIlNwYOAgMBAQEDAgMBA?= =?us-ascii?q?QEBBQEBAQIBBgQUAQEBAQEBhjgNhkQBAQEDAQEBJRkBASwLAQQJAgIBCA4CB?= =?us-ascii?q?QMuAhkMCyUCBA4FCAaCYgGBflcDDhEQAQ6iAAKKJXSBATODBAEBBoUSGIIMB?= =?us-ascii?q?wMGBYE0gVOBI4pMJhyBSUKBEUOCKS4+glwBAYE4EBoVChcCDYMDgiuBWRAuL?= =?us-ascii?q?QcBPCcQBxMsF0QgXigCFTORAYsAgR+BdZplCoJ+gRuDUIJsiHKLf6NsskENF?= =?us-ascii?q?YQmAgICAgQFAg4BAQaBaiKBWXAVO4JpUBcCDY4qDgmDTTOEYYVFczgCBgoBA?= =?us-ascii?q?QMJfItngTQBgQ4BAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3Ahut+QB972LcuJf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZxyN5/xmi1XSGJjd6uxJkfHXr7GmVWFTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBoHS56jQJXw?= =?us-ascii?q?j5NBR4PP/0Bp+Ug8nkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRz48NiJ689xw?= =?us-ascii?q?GPrGFPfrFdxHhjIhSYmBOv6w=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,232,1610409600"; d="p7s'?scan'208";a="658163283"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Mar 2021 13:35:14 +0000
Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 128DZDJb025361 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2021 13:35:14 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 8 Mar 2021 07:35:13 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 8 Mar 2021 07:35:13 -0600
Received: from NAM10-BN7-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; Mon, 8 Mar 2021 08:35:13 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZCOUoKCRmHjgizR6DUhO/qPd+CWb7rR2yU0pTrgjKH3XPHClAdu+otPQTfvboRQnnkfEugyGFXEV5sKbpDwYImFvt3mja7wy6iNjvwA8sSsfvj4cHyEi7zh5ge61hwqq6YmTmzRgadXfLEbbhvztEPLt9sKksc6T7CRYZqWXAW9bFA7r3qUf7xfjtq6NM88pPw49AnY9QDLPYlCYasWUgG8CWKjp2s72MbC8Th5ifNMeNanMDg/wyUkpAo8uHuHUfoer+ZOAwc9/gik+94yb4poabf/E93q8W+8EAA15DTMrMdj1xze2KZU3cSR7x72v5lecPnaN8f0I37k3aLte+Q==
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=7opTsDVNNblZOjXvnI25wH4/DeTEwlvE8nRPjhEMceM=; b=F9Sx7+pHgzeLLf8iJlng+VurlunR9sR8si/KRqTgUdg+f8x6ptcUpmqtLM2qpEUVIOzI7bIhpEdk885o40h8DUkv4jPGRQtZpwaWdcu9VrcDOl2or1J+S28dGdX5lNDIccmV9KaVxqghGnj/qqhhTcXoesXPg6ylFdsCHx7tOc5bP2PrPTf3vlNHZ2SgSz7RazYzo0Dbda9eahiB6c6Zvx9Fp/qWROHTQXO+lCPEeDFv+bX0T/t1i3fmlqb3IPTzJC2M/VjWl4XfDUATT9W5YcKeZbfrGH4xlMKJGxVk3npoWDVp9ka9f3zeVFdlk2XbDo/6lamgNEqM/xZekRBuZA==
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=7opTsDVNNblZOjXvnI25wH4/DeTEwlvE8nRPjhEMceM=; b=GA2V7HDDJQbeGMdcELhrtNmP6gdO0AjfjtGtGkm4CKUpJGLuDV2Kn6pc9nUVkxqvAZhqcjKJBG4Rs/z8sxWKtgdnjUb4Ui2nn0Gfh8EL8ofnsNTQLFU5ht6MEuovHTtiIg2ti5aYWuaZBnvYbIcriWapl4wG9VNAV+/M6QDjn84=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4614.namprd11.prod.outlook.com (2603:10b6:208:268::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Mon, 8 Mar 2021 13:35:12 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::f571:5dd6:fe20:3ab0]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::f571:5dd6:fe20:3ab0%4]) with mapi id 15.20.3912.027; Mon, 8 Mar 2021 13:35:12 +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: AQHXBtiPzfKDgDt1JUWIk0bm075RU6pfpH2QgBWueACAAEVAsIAACUSAgAADmXCAAA7ogIAADdnggARS7YCAABhCoA==
Date: Mon, 8 Mar 2021 13:35:12 +0000
Message-ID: <BL0PR11MB3122F3EA8700FE8386361C59A1939@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> <BL0PR11MB31227B686A7EE19225F91EB7A1969@BL0PR11MB3122.namprd11.prod.outlook.com> <20210305165859.evgne3amtovj635u@anna.jacobs.jacobs-university.de> <BL0PR11MB31229018322B4AE74C48751FA1969@BL0PR11MB3122.namprd11.prod.outlook.com> <20210308115023.lhhbxxynjdcvltli@anna.jacobs.jacobs-university.de>
In-Reply-To: <20210308115023.lhhbxxynjdcvltli@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: 402e42eb-97c9-4283-b7a3-08d8e236fffe
x-ms-traffictypediagnostic: MN2PR11MB4614:
x-microsoft-antispam-prvs: <MN2PR11MB4614D2279F2F1FCE3FFAF491A1939@MN2PR11MB4614.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: T7XDOzt8RPBqbV2eigS9jIwtFEBLtcVU9o5h2w6xNL1YJ4q3SLs40/wiUkW8y6Zf6ZctmXUPgt5AdtoY2UkX9dCIxvAE+PMHva90QdQdFzWaTOsPk23LA35XJJ3H4lsXerpRpACOQuljgLXLUFYPnm6n4G8q2Egew+MC24lK6VeKj7Dj8LuXKUI/Xd9iaRbdK1lCfpG3B15ox1Y34cO6cQo66PZ0X2+7Mn8ibiVWt3MT39CPNcjfV8I0y0jDDLnmX01t1N7IoRNBTGySTBosfmo8oAONpuq96LPKaa6WvnQiJMeXhPoMiexLqjE8+OVKNeWMoBWHGJThtbDXTVdsnJZHYyeSBnKU4ylKwVCfKh/grgXXm2WzLmWXDALBtDSNL2RTup6Z2ppmjlt4koPm/jMaRRGFJMj5kUm1giBjdkGI6F99wGjIrMmsYJ9NP+Ii5rzKtJzMCu70rrbIhQqppoEC8/Az4CfS7dV+5F542qifX9f+3jlU8a03ZvJsgp1ta9WuBPVvdW8q/nCmDX2rGfNiwjwQuHWJ/WmD7cjXEiF9sUmUZgjmP6HjRVWIYKQGzcB3ssHfbaGUFWROOj6C83UmGdweiuJYk+vDr7UC2Rg=
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:(366004)(39860400002)(396003)(346002)(136003)(376002)(52536014)(6506007)(316002)(5660300002)(54906003)(71200400001)(6916009)(7696005)(99936003)(33656002)(186003)(86362001)(55016002)(83380400001)(2906002)(4326008)(26005)(66946007)(66556008)(66446008)(66616009)(8936002)(76116006)(9686003)(8676002)(66476007)(64756008)(478600001)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?lAku77nEKLov8E0uP/2fBMawPFFIiRh5zUxIPmbFohLpM9onpxBjiSU6ji7H?= =?us-ascii?Q?ejOZk/kMyrJkw50piRjlkwO+J5+IbkCepUQo2GSCX7/PzDYktCYOXDZ99fc0?= =?us-ascii?Q?NelUY4y/QErpzALMzz9jvjEGC1qfWtXYSdUCmCV1KqJEMUteb+r0hS1FV+l1?= =?us-ascii?Q?Gn0YD3B6szdrJEhdo5W+hcOm0C3+xL98v1WeYoemgzbuSSf0wbIJD4p6EDZZ?= =?us-ascii?Q?anETsp/Fu3h4oNp21WCLeQycs1u5pfuC27yMkGKDqNMUXtfcv26EczBegOQO?= =?us-ascii?Q?CfM23TKQDxaDGo1l+wC853J6KSOJSMSe9jnLTiF2960Gsn5va7PPkd4WQyCm?= =?us-ascii?Q?jcRdBU14CZ3tKvcOHRfDRmSnuNcx+0IzpRVPlQwUfv+zODjfddljKSaj3qpX?= =?us-ascii?Q?ABQ0Bo2TXE8hOX0GJnDz/82srERD7TPVaoK6/wbJf6VyU3CHXVPiJeHS6yZ6?= =?us-ascii?Q?+MRu7wCLtmlWDjXPIMSGij9q4YOmnaO0V/6irPh7xO3toFpu9458m5dA6IgM?= =?us-ascii?Q?tyxPgf09hhG5N0ttgMnhC+qhMsO20IJYV5x3DP1ZFXtuW1F4MiqQOgwSvlVs?= =?us-ascii?Q?szcjENNGMpglFcfA/MM07fTP0oS9mcHI4o3fCbKWqrMKrzGvkMcoQswwD+GK?= =?us-ascii?Q?pNshNpdeOux96ICzdrdZ1SohxEsAiuT4R1tRsfvcdwsJHpGsDs+HffpsKm0m?= =?us-ascii?Q?nZQfj8nFhvyT/mTWh+jCgsyojBM6LVYya1nSKflSSqfr9hFBRhw8Dsv9QXry?= =?us-ascii?Q?BHpERhmsNskj7NxFDZYqBdkxfqL9Ld8G2rTDzmOvpPkJW8DQhb3aUuutdNsn?= =?us-ascii?Q?Ceg6WudgjB8AdA/C0tgCGyoSLSJf++fsXk2JJ67ohpzBXb1TqvpHFc+qj0O3?= =?us-ascii?Q?BkYkAGV4jipA2qoIjtxT5bEoHClT89srHpwlKiOIYB7dHSwwzyJ1E6qntt9Y?= =?us-ascii?Q?nVAbtH1As9AE87Yn1QK9pZgdDMyOwjEMvXl2XJO8q76nTJIzYS8oYqJvVPqq?= =?us-ascii?Q?GeWX+1EQq3XcEws1+qglS/sY4FUTgtzF/HfdDXWLIdoXDSG/Qs/eqsZOvVkj?= =?us-ascii?Q?eTfkQu1U4nTpWwZ23cAU7sMbB71X/Z01Xgo5H3IVlxXnf78oqX0dbD5jocus?= =?us-ascii?Q?eZN+Kbqnur0TQQYIbD23cuIfNXh2LjvG1v3+Bkxy4s2MpiAipDSjr36Fw8ZP?= =?us-ascii?Q?xu4pWMBJP1fBi851un28Mq2b8D6jYxn9jUHeWQeMiAUd2T80cGlGxtcNIMAM?= =?us-ascii?Q?9apyFpVPCzTw8wprt2qc316tdkyOor9m76+t2cF90c4j8P0+GOcgrNVQy/5A?= =?us-ascii?Q?j+f1a33pLbR9TC4krXuj4vrD?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_066C_01D713F5.F47EE0B0"
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: 402e42eb-97c9-4283-b7a3-08d8e236fffe
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2021 13:35:12.2510 (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: 8FFBL275K2jMBrc+gAqG3d4hhEdu3tBwlceAAeL3te+sx10guQYtmpLQNEBesLxX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4614
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/5A8_bcKK0VddPKRCVOGczvAuoB4>
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: Mon, 08 Mar 2021 13:35:18 -0000

> From: Juergen Schoenwaelder, March 8, 2021 6:50 AM
> 
> On Fri, Mar 05, 2021 at 06:30:10PM +0000, Eric Voit (evoit) wrote:
> > > From: Juergen Schoenwaelder, March 5, 2021 11:59 AM
> > >
> > > On Fri, Mar 05, 2021 at 04:23:27PM +0000, Eric Voit (evoit) wrote:
> > > > 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.
> > > >
> > >
> > > But then the config needs to say to which TPM and TPM type (version)
> > > it
> > applies.
> > > And in case there is a mismatch, the config does not get applied or
> > > even rejected.
> >
> > I believe the current model accomplishes this, without the need for
> > placing the constraining information in the description.  More below.
> >
> > > From the interfaces YANG model:
> > >
> > >          leaf type {
> > >            type identityref {
> > >              base interface-type;
> > >            }
> > >            mandatory true;
> > >            description
> > >              "The type of the interface.
> > >
> > > 	      [...]
> > >
> > >               If a client tries to set the type of an interface to a
> > >               value that can never be used by the system, e.g., if the
> > >               type is not supported or if the type does not match the
> > >               name of the interface, the server MUST reject the
request.
> > >               A NETCONF server MUST reply with an rpc-error with the
> > >               error-tag 'invalid-value' in this case.";
> > >            reference
> > >              "RFC 2863: The Interfaces Group MIB - ifType";
> > >          }
> > >
> > > The point here is that the config explicitly says what is
> > required/expected and
> > > the server reacts to it. I configure
> > >
> > > <tpms>
> > >   <tpm-name>tpm42</tpm-name>
> > >   <tpm-firmware-version>taa:tpm12</tpm-firmware-version>
> > >   <TPM12-hash-algo>taa:TPM_ALG_SHA1</TPM12-hash-algo>
> > >   <!-- -->
> > > </tpms>
> > >
> > > and this gets applied if there is a tpm42 which supports taa:tpm12.
> >
> > I agree there are lots of similarities to the interface model.  In the
> > interface model, you have:
> >
> >      +--rw interfaces
> >         +--rw interface* [name]
> >            +--rw name                        string
> >            +--rw type                        identityref
> >
> > And in this model we have:
> >
> >    +--rw tpms
> >       +--rw tpm* [tpm-name]
> >          +--rw tpm-name                        string
> >          +--rw tpm-firmware-version    identityref
> >
> > In both cases above the device itself should recognize the hardware
> > instances and configure those objects appropriately.
> 
> I do not think the interfaces model has a config true leaf saying:
> 
>             "Identifies the cryptoprocessor API set supported.  This
>             cannot be configured.  However it is referenced via XPATH
>             as part of configuration, so is shown as 'rw'
>             to eliminate YANG warnings related NMDA.";
> 
> This is what got this discussion started.
>
> > Now looking at the
> > other object in the tree above "TPM12-hash-algo", i.e.,
> >
> >    +--rw tpms
> >       +--rw tpm* [tpm-name]
> >         +--rw TPM12-hash-algo?        identityref
> >
> > This object can only be provisioned if that identityref also exists in
> > container "attester-supported-algos".  This container identifies which
> > TCG algorithms are available for use the platform.  This allows
> > container also has the benefit of allowing an operator to limit
> > algorithms available for use by RPCs to just a  desired set from the
> > universe of all allowed by the firmware.  To see more, check the
descriptions
> of:
> >
> >    +--rw attester-supported-algos
> >       +--rw tpm12-hash*                 identityref {taa:TPM12}?
> 
> My point is that TPM12-hash-algo is having
> 
>           when "tpm-firmware-version = 'taa:tpm12'";
> 
> and hence tpm-firmware-version needs to be configured for this to be
> meaningful.

Agree that it has to be configured.  This should be done by the server as it
recognizes the firmware during boot.  I have changed the description to:

"Identifies the cryptoprocessor API set supported.  This is automatically
configured by the device and should not be changed."   


> /js
> 
> PS: I find the mixed capitalization and hyphen/underscore style
>     confusing
> 
>     leaf TPM_QUOTE2 {
>       type binary;
>       description
> 	"Result of a TPM1.2 Quote2 operation. This includes PCRs,
>         signatures, locality, the provided nonce and other data which
> 	can be further parsed to appraise the Attester.";
>       reference
>         "TPM1.2 commands rev116 July 2007, Section 16.5";
>     }
> 
>     As far as I understand, TPM_QUOTE2 is the name of an operation
>     and not the name of its result. So is this meant to be the
>     serialization (network byte order?, alignment?) of the Outgoing
>     Operands? Is the exact format of the binary blobs well defined?
> 
>     When I search for binary in the I-D, I hit quite a few leafs where
>     the description does not tell me much what the binary format will
>     be.

The binary format is described in the reference of many of those leaves.
For quotes coming from the TPM binary format is actually quite complex,
which is why it is best to refer to the TCG standards organization's
documents for this.  In several cases within the YANG file, this reference
is missing (e.g., the signature), I will put the references in now.

Eric

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