Re: [netmod] Does defining a feature require the module be implemented?

On Tue, May 17, 2022 at 11:03 AM Kent Watsen <kent+ietf@watsen.net> 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 <andy@yumaworks.com> wrote:
>
>
>
> On Fri, May 13, 2022 at 8:49 AM Robert Varga <nite@hq.sk> 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
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>