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.
2) feature-defintion and module-implementation are orthogonal.
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
> 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] <mailto:[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
> > <https://datatracker.ietf.org/doc/html/rfc8407#section-4.13>>
> > * 4.17. Feature Definitions
> > <https://datatracker.ietf.org/doc/html/rfc8407#section-4.17
> > <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] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
