Kent Watsen <[email protected]> wrote:
>
>
> > On May 18, 2022, at 2:05 AM, Martin Björklund <[email protected]>
> > 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
