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

[Martin Björklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> 
> > 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.

Hmm, I don't remember why this was changed in RFC 8525.  Perhaps this
was by accident?  The only text I can find is this in RFC 7950:

  5.6.5.  Implementing a Module

     A server implements a module if it implements the module's data
     nodes, RPCs, actions, notifications, and deviations.

Which seems to indicate that "implementing a module" is NOT required
for a feature to be supported.

> 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.

Since RFC 8525 doesn't allow a feature to be supported w/o also
implementing the module, I think this is the solution for now.  And it
is not wrong even if RFC 8525 was updated to support features from
imported modules.


> 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.

This is a classic problem w/ any model... And you can extend it to
other things as well, not only top-level nodes; whenever you define a
leaf, perhaps someone could support multiple instances and wished it
was a leaf-list instead?  And in a leaf-list, perhaps someone wanted
to add additional properites to each item, and wished it was a list
instead?  And so on...


/martin