Change:
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> <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- <del> netconf-keystore, ietf-tcg-algs.yang ref-ietf-tcg-algs. </del> <ins> netconf-keystore, and "ietf-tcg-algs.yang" ref-ietf-tcg-algs. </ins> 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> <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> <del> 'bios' - Indicates the device supports the retrieval of bios event logs. </del> <ins> 'bios': Indicates that the device supports the retrieval of BIOS/ UEFI event logs. </ins> <del> 'ima' - Indicates the device supports the retrieval of Integrity Measurement Architecture event logs. </del> <ins> 'ima': Indicates that the device supports the retrieval of event logs from the Linux Integrity Measurement Architecture (IMA). </ins> <del> 'netequip_boot' - Indicates the device supports the retrieval of netequip boot event logs. </del> <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: <del> 'ima', 'bios', and 'netequip_boot'. </del> <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. <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> <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> <del> An example of an RPC challenge requesting PCRs 0-7 from a SHA256 bank could look like the following: </del> <ins> 2.1.1.3.2. </ins> <del> and a successful response might be formated as follows: </del> <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> <del> 2.1.1.4. </del> <ins> An example of an RPC challenge requesting PCRs 0-7 from a SHA-256 bank could look like the following: </ins> <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> <ins> A successful response could be formatted as follows: </ins> <del> 2.1.1.5. </del> <ins> 2.1.1.4. </ins> 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> <ins> into specific TPM PCRs.  A YANG tree diagram of this RPC is as follows: </ins> <del> 2.1.1.6. </del> <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. <del> container 'rats-support-structures' - This houses the set of information relating to a device's TPM(s). </del> <ins> This houses the set of information relating to a device's TPM(s). </ins> <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> <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> <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> <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 <del> the compute associated with a specific TPM.  This allows each specific TPM to identify on which 'compute-node' it belongs. </del> <ins> the compute node associated with a specific TPM.  This allows each specific TPM to identify to which 'compute-node' it belongs. </ins> <del> 2.1.1.7. </del> <ins> 2.1.1.6. </ins> 2.1.2. Cryptographic algorithm types were initially included within -v14 <del> NETCONF's iana-crypto-types.yang.  Unfortunately all this content </del> <ins> NETCONF's iana-crypto-types.yang.  Unfortunately, all this content </ins> including the algorithms needed here failed to make the -v15 used <del> WGLC.  As a result this document has encoded the TCG Algorithm </del> <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. <del> There are two types of features supported 'TPM12' and 'TPM20'. </del> <ins> There are two types of features supported: 'TPM12' and 'TPM20'. </ins> Support for either of these features indicates that a cryptoprocessor <del> supporting the corresponding type of TCG API is present on an </del> <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. <del> There are three types of identities in this model. </del> <ins> There are three types of identities in this model: </ins> <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> <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> <del> The second are API specifications for tpms: 'tpm12' and 'tpm2'. </del> <ins> *API specifications* for TPMs: 'tpm12' and 'tpm20' </ins> <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> <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 <del> ietf-tpm-remote-attestation.yang.  However the full definition of </del> <ins> "ietf-tpm-remote-attestation.yang".  However the full definition of </ins> Table 3 of TCG-Algos will allow use by additional YANG specifications.

Discussion:
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).