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

[Andy Bierman <[e-mail]>]

On Fri, May 20, 2022 at 6:15 AM Kent Watsen <[e-mail]> wrote:

> Martin, Andy,
>
> > 2) If it is the case that the module must be implemented to use its
>> > features, then I need to update some of my modules (e.g., crypto-types
>> > and friends) to explicitly disable the protocol-accessible tree when
>> > the module is implemented *only* to use its features.
>>
>> Since RFC 8525 doesn't allow a feature to be supported w/o also
>> implementing the module, I think this is the solution for now.  And it
>> is not wrong even if RFC 8525 was updated to support features from
>> imported modules.
>>
>
> Deviation-stmts would be required to "undo" the base module implementation
> requirement.
>
> Looks like RFC 7895 got this part right.
> The 'feature' leaf-list may apply to imported modules.
> The same feature can only appear once, no matter how many revisions
> of a module are imported.
>
>
> I feel vindicated, but also feel that Martin is right about this being the
> solution for now.  I don't even feel that it is necessarily bad.  But I do
> think we should act on this in some way.  Here are some options:
>
> 1) put a "document only" errata on RFC 8525.
> 2) put a "document only" errata on RFC 7950.
> 3) put a "document only" errata on RFC 8407.
> 4) file a YANG Next issue.
> 5) some combination of the above.
> 6) anything else?
>
>
I do not think an Errata can fix this issue because the split
between 'module' and 'import-only-module' was intentional.

Going back to iana-crypt-hash (again).

 - the features are not intended for use in any if-feature-stmts
 - each feature is related to one variant for values of the crypt-hash type

Features are like identities.
They are completely decoupled from the schema tree and simply
use the parent module to create a unique QName for reference in other
statements.

Perhaps we should work on some proposed edits for yang-next.




> Kent
>

Andy