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

[Andy Bierman <[e-mail]>]

On Thu, May 19, 2022 at 12:05 AM Martin Björklund <[e-mail]> wrote:

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

But RFC 7950 also says:

            Any set of data definition nodes may be replaced with another
set

      of syntactically and semantically equivalent nodes.  For example,
      a set of leafs may be replaced by a "uses" statement of a grouping
      with the same leafs.


If a module is re-factored such that previously inline definitions are now
imported,
then the data model does not change. Therefore the conformance for the
model does not change.

Yet another demonstration that YANG conformance really only applies to a
conceptual data model,
(use-cases) and not independently to each module in the data model.


Andy


 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
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>