The crypto modules aim at providing a flexible reusable infrastructure of groupings for modeling cryptographic keys and related concepts. The flexibility of the definitions provided of course comes with a certain amount of complexity. From a YANG perspective, draft-ietf-netconf-trust-anchors-13.txt is in a good and close to publish state (a couple of minor issues left). I also tried to understand what is being modeled here and hence I also have some questions concerning the concepts modeled and I hope these are easy to answer/resolve as well. - I have compiled the YANG modules using yanglint 0.16.105. - The prefix 'ts' is rather short, the set of two letter prefixes is rather small limited. This comment also applies to the other documents, crypto-types uses 'ct. Perhaps this is not a problem since collisions can be handled but if we go for rather short prefixes, we will have to exercise the collision resolution. (I see that 'ct' has already been used by ietf-complex-types, RFC 6095.) A possible alternative could be to use sec-ct, sec-ts, sec-ks, ...). RFC 8407 provides the following guidelines (Section 4.2): Prefix values SHOULD be short but are also likely to be unique. Prefix values SHOULD NOT conflict with known modules that have been previously published. Well, having short and terse prefixes is actually nice and enhancing programmer readability. - s/is defines a truststore/defines a truststore/ - s/to be grouped references/to be grouped and referenced/ - In 2.2.1, I was not sure what CA certificates are and what EE certificates are. I then tried to guess EE = end entity cert, but this does not explain CA since the term used in crypto types is trust anchor cert. The description in the XML clarified that my guess was kind of correct. Perhaps explain upfront what these acronyms mean? Or perhaps the acronyms can be avoided by simply spelling things out? They do not appear to be used frequently. - s/