Original text:
Abstract <del> This document defines a YANG RPC and a small number of configuration node required to retrieve attestation evidence about integrity measurements from a device following the operational context defined </del>  in TPM-based Network Device Remote Integrity Verification. <del> Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device </del>  components of the composite device the YANG server is running on. 1. I-D.ietf-rats-tpm-based-network-device-attest as well as the interaction model and information elements defined in I-D.ietf-rats- reference-interaction-models.  The currently supported hardware <del> security modules are the Trusted Platform Module (TPM) TPM1.2 and TPM2.0 specified by the Trusted Computing Group (TCG).  One or more TPMs embedded in the components of a Composite Device are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting in order to retrieve attestation Evidence from a composite device (quote primitive operation). Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (extend primitive operation). </del>  Specific terms imported from I-D.ietf-rats-architecture and used in this document include: Attester, Composite Device, Evidence. Specific terms imported from TPM2.0-Key and used in this document <del> include: Endorsement Key (EK), Initial Attestation key (IAK), Local </del>  Attestation Key (LAK). 1.1. 2. <del> One or more TPMs MUST be embedded in the composite device that is providing attestation evidence via the YANG module defined in this document.  The ietf-basic-remote-attestation YANG module enables a composite device to take on the role of Claimant and Attester in accordance with the Remote Attestation Procedures (RATS) architecture I-D.ietf-rats-architecture and the corresponding challenge-response interaction model defined in the I-D.ietf-rats-reference-interaction- models document.  A fresh nonce with an appropriate amount of entropy MUST be supplied by the YANG client in order to enable a proof-of- freshness with respect to the attestation evidence provided by the attester running the YANG datastore.  The functions of this YANG module are restricted to 0-1 TPMs per hardware component. </del>  2.1.  2.1.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf- <del> netconf-keystore, ietf-tcg-algs.yang ref-ietf-tcg-algs. </del>  2.1.1.1. This module supports the following features: <del> 'TPMs' - Indicates that multiple TPMs on the device can support remote attestation, This feature is applicable in cases where multiple line cards, each with its own TPM. </del>  <del> 'bios' - Indicates the device supports the retrieval of bios event logs. </del>  <del> 'ima' - Indicates the device supports the retrieval of Integrity Measurement Architecture event logs. </del>  <del> 'netequip_boot' - Indicates the device supports the retrieval of netequip boot event logs. </del>  2.1.1.2. This module supports the following types of attestation event logs: <del> 'ima', 'bios', and 'netequip_boot'. </del>  2.1.1.3.  2.1.1.3.1. <del> This RPC allows a Verifier to request a quote of PCRs from a TPM2.0 compliant cryptoprocessor.  Where the feature 'TPMs' is active, and one or more 'certificate-name' is not provided, all TPM2.0 compliant cryptoprocessors will respond.  A YANG tree diagram of this RPC is as follows: </del>  <del> An example of an RPC challenge requesting PCRs 0-7 from a SHA256 bank could look like the following: </del>  <del> and a successful response might be formated as follows: </del>  <del> 2.1.1.4. </del>  <del> This RPC allows a Verifier to request a quote of PCRs from a TPM1.2 compliant cryptoprocessor.  Where the feature 'TPMs' is active, and one or more 'certificate-name' is not provided, all TPM1.2 compliant cryptoprocessors will respond.  A YANG tree diagram of this RPC is as follows: </del>  <del> 2.1.1.5. </del>  This RPC allows a Verifier to acquire the evidence which was extended <del> into specific PCRs.  A YANG tree diagram of this RPC is as follows: </del>  <del> 2.1.1.6. </del>  This section provides a high level description of the data nodes containing the configuration and operational objects with the YANG model.  For more details, please see the YANG model itself in ref- ietf-tpm-remote-attestation. <del> container 'rats-support-structures' - This houses the set of information relating to a device's TPM(s). </del>  <del> container 'tpms' - Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status.  Of note is the certificates which are associated with that TPM.  As a certificate is associated with a single Attestation key, knowledge of the certificate allows a specific TPM to be identified. </del>  <del> container 'attester-supported-algos' - Identifies which TCG algorithms are available for use the Attesting platform.  This allows an operator to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed by TCG. </del>  container 'compute-nodes' - When there is more than one TPM supported, this container maintains the set of information related to <del> the compute associated with a specific TPM.  This allows each specific TPM to identify on which 'compute-node' it belongs. </del>  <del> 2.1.1.7. </del>  2.1.2. Cryptographic algorithm types were initially included within -v14 <del> NETCONF's iana-crypto-types.yang.  Unfortunately all this content </del>  including the algorithms needed here failed to make the -v15 used <del> WGLC.  As a result this document has encoded the TCG Algorithm </del>  definitions of TCG-Algos, revision 1.32.  By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model. 2.1.2.1. <del> There are two types of features supported 'TPM12' and 'TPM20'. </del>  Support for either of these features indicates that a cryptoprocessor <del> supporting the corresponding type of TCG API is present on an </del>  Attester.  Most commonly, only one type of cryptoprocessor will be available on an Attester. 2.1.2.2. <del> There are three types of identities in this model. </del>  <del> The first are the cryptographic functions supportable by a TPM algorithm, these include: 'asymmetric', 'symmetric', 'hash', 'signing', 'anonymous_signing', 'encryption_mode', 'method', and 'object_type'.  The definitions of each of these are in Table 2 of TCG-Algos. </del>  <del> The second are API specifications for tpms: 'tpm12' and 'tpm2'. </del>  <del> The third are specific algorithm types.  Each algorithm type defines what cryptographic functions may be supported, and on which type of API specification.  It is not required that an implementation of a specific TPM will support all algorithm types.  The contents of each specific algorithm mirrors what is in Table 3 of TCG-Algos. </del>  2.1.2.3. Note that not all cryptographic functions are required for use by <del> ietf-tpm-remote-attestation.yang.  However the full definition of </del>  Table 3 of TCG-Algos will allow use by additional YANG specifications. This document will include requests to IANA: <del> To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang will be necessary. </del>  4. RFC8446. There are a number of data nodes defined in this YANG module that are <del> writable/creatable/deletable (i.e., config true, which is the </del>  default).  These data nodes may be considered sensitive or vulnerable <del> in some network environments.  Write operations (e.g., edit-config) </del>  to these data nodes without proper protection can have a negative effect on network operations.  These are the subtrees and data nodes <del> and their sensitivity/vulnerability: Container: '/rats-support-structures/attester-supported-algos' </del>  'tpm12-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric- <del> signing', and 'tpm20-hash' all could be populated with algorithms which are not supported by the underlying physical TPM installed by the equipment vendor. Container: '/rats-support-structures/tpms' </del>  <del> 'name' - Although shown as 'rw', it is system generated. Therefore it should not be possible for an operator to add or remove a TPM from the configuration. </del>  <del> 'tpm20-pcr-bank' - It is possible to configure PCRs for extraction </del>  which are not being extended by system software.  This could unnecessarily use TPM resources. <del> 'certificates' - It is possible to provision a certificate which does not correspond to a Attestation Identity Key (AIK) within the TPM. </del>  <del> RPC: 'tpm12-challenge-response-attestation' - Need to verify that the certificate is provided is able to support Attestation on the targeted TPM. </del>  <del> RPC: 'tpm20-challenge-response-attestation' - Need to verify that the certificate is provided is able to support Attestation on the targeted TPM. </del>  <del> RPC: 'log-retrieval' - Pulling lots of logs can chew up system resources. </del>  5.

Reviewer comments:
Basically, this fixes typos, grammar, and consistency. And, all above, the TPM 2.0 quote information, which was set to TPMSQUOTEINFO. Actually it is TPM2B_ATTEST. Further Issues to be created.
TPM 2.0 quote information (attestation data) is of type TPM2BATTEST, not TPMSQUOTEINFO. TPMSQUOTEINFO is a sub element of the TPM2BATTEST. In a TPM2Quote operation, the TPM signs a hash of the TPM2BATTEST structure. The signature is of type TPMT_SIGNATURE (just FYI).

Revised text:
Abstract  <ins> This document defines YANG RPCs and a small number of configuration nodes required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined </ins> in TPM-based Network Device Remote Integrity Verification.  <ins> Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots of trust for measurement (RTMs). The module defined requires at least one TPM 1.2 or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), included in the device </ins> components of the composite device the YANG server is running on. 1. I-D.ietf-rats-tpm-based-network-device-attest as well as the interaction model and information elements defined in I-D.ietf-rats- reference-interaction-models.  The currently supported hardware  <ins> security modules (HSMs) are the Trusted Platform Modules (TPMs) TPM1.2 and TPM2.0 as specified by the Trusted Computing Group (TCG). One or more TPMs embedded in the components of a Composite Device are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence from a composite device (_TPM Quote_ primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (_TPM PCR Extend_ primitive operation). </ins> Specific terms imported from I-D.ietf-rats-architecture and used in this document include: Attester, Composite Device, Evidence. Specific terms imported from TPM2.0-Key and used in this document  <ins> include: Endorsement Key (EK), Initial Attestation Key (IAK), Local </ins> Attestation Key (LAK). 1.1. 2.  <ins> One or more TPMs MUST be embedded in a Composite Device that provides attestation evidence via the YANG module defined in this document. The ietf-basic-remote-attestation YANG module enables a composite device to take on the role of an Attester, in accordance with the Remote Attestation Procedures (RATS) architecture I-D.ietf-rats- architecture, and the corresponding challenge-response interaction model defined in the I-D.ietf-rats-reference-interaction-models document.  A fresh nonce with an appropriate amount of entropy MUST be supplied by the YANG client in order to enable a proof-of- freshness with respect to the attestation Evidence provided by the Attester running the YANG datastore.  Further, this nonce is used to prevent replay attacks.  The functions of this YANG module are restricted to 0-1 TPMs per hardware component. </ins> 2.1. <ins> In this section the several YANG modules are defined. </ins> 2.1.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf-  <ins> netconf-keystore, and "ietf-tcg-algs.yang" ref-ietf-tcg-algs. </ins> 2.1.1.1. This module supports the following features:  <ins> 'TPMs': Indicates that multiple TPMs on the device can support remote attestation.  This feature is applicable in cases where multiple line cards are present, each with its own TPM. </ins>  <ins> 'bios': Indicates that the device supports the retrieval of BIOS/ UEFI event logs. </ins>  <ins> 'ima': Indicates that the device supports the retrieval of event logs from the Linux Integrity Measurement Architecture (IMA). </ins>  <ins> 'netequip_boot': Indicates that the device supports the retrieval of netequip boot event logs. </ins> 2.1.1.2. This module supports the following types of attestation event logs:  <ins> 'bios', 'ima', and 'netequip_boot'. </ins> 2.1.1.3. <ins> In the following, RPCs for both TPM 1.2 and TPM 2.0 attestation procedures are defined. </ins> 2.1.1.3.1.  <ins> This RPC allows a Verifier to request signed TPM PCRs (_TPM Quote_ operation) from a TPM 1.2 compliant cryptoprocessor.  Where the feature 'TPMs' is active, and one or more 'certificate-name' is not provided, all TPM 1.2 compliant cryptoprocessors will respond.  A YANG tree diagram of this RPC is as follows: </ins>  <ins> 2.1.1.3.2. </ins>  <ins> This RPC allows a Verifier to request signed TPM PCRs (_TPM Quote_ operation) from a TPM 2.0 compliant cryptoprocessor.  Where the feature 'TPMs' is active, and one or more 'certificate-name' is not provided, all TPM 2.0 compliant cryptoprocessors will respond.  A YANG tree diagram of this RPC is as follows: </ins>  <ins> An example of an RPC challenge requesting PCRs 0-7 from a SHA-256 bank could look like the following: </ins>  <ins> A successful response could be formatted as follows: </ins>  <ins> 2.1.1.4. </ins> This RPC allows a Verifier to acquire the evidence which was extended  <ins> into specific TPM PCRs.  A YANG tree diagram of this RPC is as follows: </ins>  <ins> 2.1.1.5. </ins> This section provides a high level description of the data nodes containing the configuration and operational objects with the YANG model.  For more details, please see the YANG model itself in ref- ietf-tpm-remote-attestation.  <ins> This houses the set of information relating to a device's TPM(s). </ins>  <ins> Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status.  Of note are the certificates which are associated with that TPM.  As a certificate is associated with a particular TPM attestation key, knowledge of the certificate allows a specific TPM to be identified. </ins>  <ins> container 'attester-supported-algos' - Identifies which TCG hash algorithms are available for use on the Attesting platform.  This allows an operator to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed hash algorithms by the TCG. </ins> container 'compute-nodes' - When there is more than one TPM supported, this container maintains the set of information related to  <ins> the compute node associated with a specific TPM.  This allows each specific TPM to identify to which 'compute-node' it belongs. </ins>  <ins> 2.1.1.6. </ins> 2.1.2. Cryptographic algorithm types were initially included within -v14  <ins> NETCONF's iana-crypto-types.yang.  Unfortunately, all this content </ins> including the algorithms needed here failed to make the -v15 used  <ins> WGLC.  As a result, this document has encoded the TCG Algorithm </ins> definitions of TCG-Algos, revision 1.32.  By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model. 2.1.2.1.  <ins> There are two types of features supported: 'TPM12' and 'TPM20'. </ins> Support for either of these features indicates that a cryptoprocessor  <ins> supporting the corresponding type of TCG TPM API is present on an </ins> Attester.  Most commonly, only one type of cryptoprocessor will be available on an Attester. 2.1.2.2.  <ins> There are three types of identities in this model: </ins>  <ins> *Cryptographic functions* supported by a TPM algorithm; these include: 'asymmetric', 'symmetric', 'hash', 'signing', 'anonymous_signing', 'encryption_mode', 'method', and 'object_type'.  The definitions of each of these are in Table 2 of TCG-Algos. </ins>  <ins> *API specifications* for TPMs: 'tpm12' and 'tpm20' </ins>  <ins> *Specific algorithm types*: Each algorithm type defines what cryptographic functions may be supported, and on which type of API specification.  It is not required that an implementation of a specific TPM will support all algorithm types.  The contents of each specific algorithm mirrors what is in Table 3 of TCG-Algos. </ins> 2.1.2.3. Note that not all cryptographic functions are required for use by  <ins> "ietf-tpm-remote-attestation.yang".  However the full definition of </ins> Table 3 of TCG-Algos will allow use by additional YANG specifications. This document will include requests to IANA:  <ins> To be defined yet.  But keeping up with changes to "ietf-tcg- algs.yang" will be necessary. </ins> 4. RFC8446. There are a number of data nodes defined in this YANG module that are  <ins> writable/creatable/deletable (i.e., _config true_, which is the </ins> default).  These data nodes may be considered sensitive or vulnerable  <ins> in some network environments.  Write operations (e.g., _edit-config_) </ins> to these data nodes without proper protection can have a negative effect on network operations.  These are the subtrees and data nodes  <ins> as well as their sensitivity/vulnerability: </ins> 'tpm12-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric-  <ins> signing', and 'tpm20-hash'.  All could be populated with algorithms that are not supported by the underlying physical TPM installed by the equipment vendor. </ins>  <ins> 'name': Although shown as 'rw', it is system generated.  Therefore it should not be possible for an operator to add or remove a TPM from the configuration. </ins>  <ins> 'tpm20-pcr-bank': It is possible to configure PCRs for extraction </ins> which are not being extended by system software.  This could unnecessarily use TPM resources.  <ins> 'certificates': It is possible to provision a certificate which does not correspond to an Attestation Identity Key (AIK) within the TPM 1.2, or an Attestation Key (AK) within the TPM 2.0 respectively. </ins>  <ins> It must be verified that the certificate is for an active AIK, i. e. the certificate provided is able to support Attestation on the targeted TPM 1.2. </ins>  <ins> It must be verified that the certificate is for an active AK, i. e. the certificate provided is able to support Attestation on the targeted TPM 2.0. </ins>  <ins> Pulling lots of logs can chew up system resources. </ins> 5.