True, the current YANG Library structure allows features to be declared only for implemented modules, but I'm unsure how intentional that was.
We always talk about how a module needs to be "implemented" in order for its Identities to be defined, but we don't ever talk about the same being true for Features. It seems that, if this is the case, there should be a note somewhere about features used in "grouping" statements and hence the exporting-module must be "implemented" for the grouping to be used as intended. These sections from RFC 8407 don't say anything about it: 4.13. Reusable Groupings <https://datatracker.ietf.org/doc/html/rfc8407#section-4.13> 4.17. Feature Definitions <https://datatracker.ietf.org/doc/html/rfc8407#section-4.17> Kent > On May 10, 2022, at 2:01 AM, Michal Vasko <[email protected]> wrote: > > Hi, > > I would just like to explicitly mention that the current YANG library does > not allow to report features for non-implemented modules and the feature list > is in a grouping called `module-implementation-parameters`[1] so it would > seem the authors of that RFC thought one must implement a module to enable > its features. > > Regards, > Michal > > [1] https://www.rfc-editor.org/rfc/rfc8525#page-11 > > On 9. 5. 2022 19:43, Kent Watsen wrote: >> YANG Doctors, >> >> >> Does "foo" need to be "implemented", in order for its feature to be define? >> >> module foo { >> yang-version 1.1; >> namespace "https://example.net/foo";; >> prefix "f"; >> >> feature foo-feature; >> >> ... >> } >> >> >> Specifically, using the previous YANG Library (RFC 7895), would this be >> possible: >> >> { >> "name": "foo", >> "feature": [ >> "foo-feature" >> ], >> "namespace": "https://example.net/foo";, >> "conformance-type": "import" >> }, >> >> >> Or does "foo" also need to be "implemented", in order for its feature to be >> defined? >> >> >> 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. >> >> Thanks, >> Kent >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
