On Tue, May 17, 2022 at 11:03 AM Kent Watsen <[email protected]> wrote:
> Hi Andy, > > Thanks for your response, but I'm having trouble parsing it. At first I > thought it was just me, but I asked someone else and they said the same. > Can you state either: > > 1) a module MUST be implemented in order for its features to be defined. > This is true because the design of the /yang-library subtree [RFC8525] does not allow features to be listed in the import-only-module list. 2) feature-defintion and module-implementation are orthogonal. > > The term "protocol-accessible" does not cover modules like iana-crypt-hash, [RFC7317] which has 1 typedef and 3 features defined in it. Is there a normative definition you can point to, or are we working > backwards from YANG Library (but note that the two versions of YANG Library > enabled it differently). > > Thanks, > Kent > > > Andy > > On May 13, 2022, at 12:04 PM, Andy Bierman <[email protected]> wrote: > > > > On Fri, May 13, 2022 at 8:49 AM Robert Varga <[email protected]> wrote: > >> On 13/05/2022 17:03, Kent Watsen wrote: >> > 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> >> >> Right, I think we need to first clarify what RFC8525's: >> >> > "An entry in this list indicates that the server imports >> > reusable definitions from the specified revision of the >> > module but does not implement any protocol-accessible >> > objects from this revision. >> >> "reusable definition" seems to be an under-defined term. I think the >> intent is to cover not only groupings, but also typedefs and extensions. >> >> > > I thought this issue was obvious and already settled with the > iana-crypt-hash module. > There are features related to the server implementation of data nodes > that use the crypt-hash typedef. > > We list iana-crypt-hash (or any module that has features) in the > implemented modules. > The client needs to know this info and that is the only way to do it. > > I think these should also include identities and features -- but that >> opens up quite a can of worms in terms of what a 'supported feature' is: >> - is it tied to a particular revision or does it apply to all revisions? >> - is it a property of imported or (ultimante) importing module? >> >> Regards, >> Robert >> > > Andy > > >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
