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

On Wed, May 18, 2022 at 7:30 AM Kent Watsen <kent+ietf@watsen.net> wrote:

>
>
> On May 18, 2022, at 2:05 AM, Martin Björklund <mbj+ietf@4668.se> 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.
>
>

IMO the focus on "protocol-accessible" is clearly wrong.
The larger issue is simply "what is the point of defining a YANG feature if
there is no way
for the server to tell the client it is supported?".

The YANG module itself will say what it means to support the feature.
The YANG library does not override any of its conformance requirements.

It is legal in YANG to define features for any reason.
They apply to many more schema items than data nodes.

A server can support a module without any protocol-accessible objects in 3
ways
   - implement the module with no features supported
   - implement the module with features supported
   - import the module without implementing it

To Martin's point, it is not clear that a client is harmed because a server
lists a module in
the 'module' list instead of the 'import-only-module' list.

Andy

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