Re: [yang-doctors] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13

[Kent Watsen <[e-mail]>]

Hi Juergen,

Whittling out things resolved.

K.

>>> Reviewer: Jürgen Schönwälder
>>> Review result: Ready with Issues
>>> 
>>> 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, ...).
>> 
>> Ugh (me, whenever a naming-discussion comes up ;)
>> 
>> <rant>I don’t know why prefixes are registered, as the prefix is defined at the top of each module.  The only value I see is not syntactic but rather for consistency, to aid human readability across disconnected sets of modules.</rant>
>> 
>> Prefixing the prefix with “sec-“ may work for the trio of drafts you just reviewed, but it seems undesirable when getting to the client-server drafts, as they're more *protocol* oriented.  If “ks” and “ts” aren’t taken, then maybe we claim “first mover” advantage?  If not, then maybe “kstore” and “tstore” might be meaningful fallbacks?  Assuming we claim “first mover” advantage for “ks” and “ts”, then we just need to handle “ct”, which maybe could be “ctypes” or “cryptypes” or “ct2”?  So, 1) prefix the trio or 2) claim first-mover advantage on two and figure out something for “ct”?  …or maybe 3) keep “ct” also noting that a) “SHOULD NOT” is not a “MUST NOT” (in the text below), b) my “rant” might have some merit, and c) short and terse is nice (per your next comment).
>> 
> 
> I suggest you think over it and pick whatever you think seems to be a
> good solution. ;-)

I prefer to do nothing and push conflict resolution to the front.  I understand that this is against the SHOULD NOT at the end of RFC 8407 Section 4.2.  In this case, I feel that continuing to use “ct”, “ts” and “ts” is best.  If there were a convenient *good* alternative, I’d do it, but I don’t think there is, and it’s not worth trying to avoid a conflict with an “experimental” RFC from a decade ago that I’ve never heard of.


>>> - Is the feature truststore-supported really needed? Does the YANG
>>> library not already provide the information whether a module has
>>> been implemented or just imported to access type and grouping
>>> definitions?
>> 
>> This was discussed before.  The bottom of Section 2.1.4 says: "The reason for why the "truststore-grouping" exists separate from the protocol-accessible nodes definition is to enable instances of the truststore to be instantiated in other locations, as may be needed or desired by some modules.”.  Case in point, the MacOS “Keychain Access” utility maintains both system-level and user-level trust anchors.  [UPDATE: you had a similar comment in the keystore draft, which you self-resolved there and then said to ignore this comment.  Just the same, let’s ensure the drafts are clear.]
> 
> This explanation gives a reason why there are groupings. My question
> concerned the feature truststore-supported. Is the YANG library not
> already providing the information whether a module has been
> implemented or only used for getting access to definitions? In RFC
> 8525, you have a list of modules implemented and a list of modules
> used for import only. My question is does feature truststore-supported
> mean the same as the module shows up in the implemented module set in the YANG library?

Okay, I see.  Yes, the two things mean the same thing, but there is a need still, which is that “if-feature” statement expression cannot reference the conformance of a module in YL, which is compounded by the fact that how it is expressed differs from RFC 7895 and RFC 8525.


> I have looked through the diffs, looked all good to me.

Thanks.

K.