Change:
2.2. <del> This YANG module imports modules from RFC6991, RFC8348, and I-D.ietf- netconf-crypto-types. </del> <ins> 2.2.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf- netconf-crypto-types, ietf-asymmetric-algs.yang. 2.3. Cryptographic algorithm types were initially included within -v14 NETCONF's iana-crypto-types.yang.  Unfortunately all this content including the algorithms needed here failed to make the -v15 used WGLC.  Therefore a modified version of this draft is included here. Perhaps someone will steward this list as a separate draft. </ins> 3.

Discussion:
Allows the YANG model changes I have suggested to be merged into the overall document
There are several issues with the current YANG model. I am grouping them as one as I have a single YANG model pull request to cover all of these. The issues I believe need to be addressed include: (1) PCR numbers should be their own type, not a UINT8. PCRs should be limited to [0..31] (2) We should use ENUMs instead of strings for TCG and IETF crypto algorithm types. Strings allow lots of errors to be introduced which we can protect using a larger, more detailed ENUM construct. (3) Most devices do not have multiple line cards. Because of that, we should not have nested keys of [node id] [tpm name]. This adds unnecessary complexity for the vast majority of users. Instead the tpm should have a mandatory leafref back to node-id when compute-nodes is not null. (4) The YANG doctors will not let us have a TPM-Name of "ALL". Instead of "ALL" we should be able to assume that an RPC means all hardware based TPMs if a specific TPM is not named in the RPC. Note that this means that we should not use TPM-name as a KEY in any RPC. (5) We should add leaf for a unique TPM-Path. It might be claimed this is irrelevant with the existing key structure, but likely the YANG model itself will learn the TPM this way after boot. You could add/remove/migrate new virtual TPMs, more easily only re-allocating an existing path when the new vTPM is activated. (6) We should have optional YANG features for TPM1.2 and TPM2.0 so that RPCs are not exposed when there are no such TPMs of that type are supported. (7) We should great new grouping for the log algorithm types. These groupings can be reused for a Telemetry/Subscription feed of individual log entries. Other log types like those proposed for "netequip boot" by Bin Cao can then be merged.
I placed this as a separate issue from the Pull Request as almost all issues are addressed in the pull request. For (2), I only added some of the relevant ENUMs. Others will be added should people agree with the direction of the pull request.

Based on some feedback, made the following changes: (8) Removed 'TPM-path' as a unique identifier for RPCs. Instead 'certificate-name' is used. This allows for a cleaner certificate migration path, and won't have issues with reboots. (9) Extracted into a group TPM2ALGID
Other issues included in latest proposal: (10) Separate out crypto-algorithm types into a separate draft (11) Not much reason in building choices for IETF algorithm types when the TPMs need to follow TCG types. (12) Leafrefs for certificate datastores should simplify the storage of this information should people not want to create separate structures.
We should separate 10 into its own issue. The current model doesn't break it out into its own draft. Let's publish the next charra version as including both within this draft. Doing so will allow us to ask the WG the question at the next IETF.
Because these TCG-defined algorithm types are only used by CHARRA now, so I think this strong relationship makes it OK that leaving the crypto-algorithm types in CHARRA.
Especially for the upcoming review phase this is fine. Long term, we have to understand how maintenance of the alg document will work. When the TCG registry changes, only the alg module in this doc has to be updated. Do we have to update the whole doc? Do we split out only the alg module? Maybe that is a reason to split it out now. I am not sure that we know today (at least I don't) and we should find out. Let's drive a thorough review cycle before the upcoming meeting and then bring this topic up in a discussion at the virtual meeting itself.
Thanks!