> Kent Watsen <[email protected]> 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. > > Can you show a specific example where this is a problem?
The issue is that the modules need to be implemented, and thus any protocol-accessible nodes contained therein are enabled. The issue was detected by an "imported" module containing a protocol-accessible leaf with "mandatory true". Validation failed. The fix was/is to define a special feature (e.g., protocol-accessible-nodes-supported) to put on the top-level nodes contained in the module. This way the nodes aren't enabled simply because the module is implemented, as the feature must be defined as well. > /martin K. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
