Re: [netmod] Does defining a feature require the module be implemented?

[Kent Watsen <[e-mail]>]

> On May 18, 2022, at 2:05 AM, Martin Björklund <[e-mail]> wrote:
> 
>> PS: the answer to this impacts the "crypto-types and friends" drafts
>> in the NETCONF WG, where it is assumed (and various tools agreed, sans
>> a recent change in `yanglint`) that the implementation-status of a
>> module is orthogonal to what features supported.
> 
> Can you show a specific example where this is a problem?


Background:

The genesis of this issue arises from a change (I think!) in instance-document validation behavior from yanglint 1.x and 2.x, which I've been switching to, whereby validation is now failing due to an assumption that a module is *implemented* when the module is targeted by the "--features" parameter, even if only to explicitly indicate the *no* features are defined (i.e., "--featues=foo:", note that there are no feature-names listed after the colon).  As an aside, this seems a bit like "the tail wagging the dog", but the reasoning was/is that features can only be defined if a module is implemented and therefore it makes sense to auto-implement a module even though it wasn't explicitly listed as such on the command line.

Issue:

An issue arises when a module (like ietf-keystore) defines a grouping (like "keystore-grouping") that is used both to allow instances in other data models as well as a "global" instance when the module is implemented.  i.e., container keystore { uses keystore-grouping; }

In ietf-keystore, a feature (central-keystore-supported) is used to enable leafrefs to the global instance for cases when the module is implemented (e.g., see local-or-keystore-symmetric-key-grouping).   However, because it was not anticipated that a module had to be implemented in order for a feature to be defined (as was allowed by RFC 7895 YANG Library), the "central-keystore-supported" feature statement was NOT placed on the root node of the protocol-accessible tree.

So, in the case of NOT wanting the global keystore instance and yet there IS a desire to define another keystore feature (e.g., asymmetric-keys), it seems that 1) the module MUST be implemented *and* the root node of the protocol-accessible tree MUST have an "if-feature central-keystore-supported" statement.

Closing thoughts:

1) I'm not saying it is wrong that a module must be implemented in order to define features defined in it.  But I am noting that I can't find where this behavior is defined (e.g., in RFC 7950).   Also I note that RFC 7895 enabled features to be defined independent of implementation-status while RFC 8525 doesn't.   As a co-author of RFC 8525, I don't recall this being discussed and wonder what justification was used, as folks are pointing to and working backwards from RFC 8525 to indicate that it must be so.

2) If it is the case that the module must be implemented to use its features, then I need to update some of my modules (e.g., crypto-types and friends) to explicitly disable the protocol-accessible tree when the module is implemented *only* to use its features.

3) I wish more modules would following the pattern of having the global protocol accessible tree be defined via a "uses" of a grouping defined in the module.   In another recent project, I had to hack the topology modules defined in RFC 8345 (to convert the containers to groupings) to enable a multiplicity of "abstract network topologies" to be configured.  The assumption that only a single global instance is ever needed is proving to be invalid in my work time and again.


K.