On Mon, May 23, 2022 at 6:57 AM Kent Watsen <[email protected]> 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 > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
