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

[Andy Bierman <[e-mail]>]

On Mon, May 23, 2022 at 6:57 AM Kent Watsen <[e-mail]> wrote:

> Hi Andy,
>
> 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.
>
>
> My intention for using the "hold for document update" Errata (I wrote "document
> only" before) is only to better document the behavior that exists
> currently, so it doesn't have to be rediscovered again later.  Martin
> pointed to an RFC section that didn't list features explicitly, leaving it
> open for interpretation.  Patching such sections would be good.  As for RFC 8407,
> maybe Section 4.17 (Feature Definitions) could say something?
>
> Following are a couple excerpts from
> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata:
>
> Hold for Document Update - The erratum is not a necessary update to the
> RFC. However, any future update of the document might consider this
> erratum, and determine whether it is correct and merits including in the
> update.
>
>
> And (I added the underline):
>
> Changes which are simply stylistic issues or *simply make things read
> better* should be Hold for Document Update.
>
>
> Would you be willing to offer some text for an RFC 8407 "hold for
> document update" errata?   If Martin does the same for the section he
> found, I think we would be covered.  It seems is worthy effort, yes?
>
>
I will have to look at the text that is there now.

It is not likely that any YANG features defined in a module are completely
decoupled from the content in that module, such that it makes any sense
to support a YANG feature but not use anything else from the module.
(Certainly not the case in iana-crypt-hash).

I meant hold for yang-library-next, not yang-next.
There are no changes really needed to YANG 1.1.

It is not a priority to change the YANG library (yet again!) since
there is a workaround using the current revision.



> Kent // contributor
>
>
Andy


>
>
> 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
>
>
>
>